When configuring AD FS for Office 365, one of the final steps is to link Azure AD with the on-premises AD FS deployment. This should occur only after AD FS and WAP servers have been fully deployed, verified and tested.
When linking the AD FS infrastructure with Office 365, we must use the Azure AD PowerShell module. We need to point the module at the primary AD FS server using the Set-MsolADFSContext cmdlet, if the module is not executed locally on the primary AD FS server.
If everything just works, then there would be no need for this blog post and life would be far less interesting. One of the requirements is that the AD FS server has PSRemoting enabled. If PSRemoting is not enabled, a firewall blocks it or the WinRM service is not running you will not be able to complete the required configuration.
The below screenshots illustrate the observed behaviour if we run into PSRemoting issues.
Note that the AD FS servers require Internet access on TCP 80 and 443 to connect to Azure AD and complete the configuration. TCP 80 is required for Certificate Revocation List checks and TCP 443 is for the actual service communication.
Lab Configuration
In this lab we have AD FS 2016 deployed. All of these machines are part of the same AD Domain in the same forest. We are logged on as a domain admin account so we do not have to worry about security assignment issues in this post. We can focus on the PSRemoting aspect.
On the primary AD FS server, the WinRM service was deliberately stopped. This is shown in the PowerShell window below.
To prove that the server is not listening on the regular PSRemoting ports, we check using netstat. Note that no services are listening on TCP 5985 or TCP 5986.
Authentication Prompt Due to PSRemoting Denied
What happens if we now go to a remote machine and try to point the Azure AD module to this AD FS server using the Set-MsolADFSContext cmdlet. In the below example note that the server name is the same hostname which was displayed above: ADFS-2016-1.wingtiptoys.ca.
Set-MsolADFSContext –Computer ADFS-2016-1.wingtiptoys.ca
Oh – that did not end well. We got an authentication prompt. How come? We are logged on as a domain administrator account, and you can see that the PowerShell instance is running as administrator.
Even if you correctly enter the credentials into the prompt, the command still fails. This is most likely due to PowerShell remoting NOT being enabled on the server that the –Computer parameter specifies. In our case the server: ADFS-2016-1.wingtiptoys.ca.
To troubleshoot the issue, we can review the Azure AD Module's log file. This is located in:
%USERPROFILE%\Documents\MicrosoftOnline
The below is an excerpt from the log file. The highlighted line indicates that we are unable to connect to the primary AD FS server on TCP 5985.
5/14/2017 4:05:26 PM Runspace Connection info: Scheme:http Port:5985, AuthenticationType:Default Uri:ADFS-2016-1.wingtiptoys.ca AppName:wsman, Shell:http://schemas.microsoft.com/powershell/Microsoft.PowerShell
5/14/2017 4:05:26 PM Connection Uri: http://ADFS-2016-1.wingtiptoys.ca:5985/wsman/
5/14/2017 4:05:26 PM Opening runspace to 'http://adfs-2016-1.wingtiptoys.ca:5985/wsman/'
5/14/2017 4:05:47 PM System.Management.Automation.Remoting.PSRemotingTransportException: Connecting to remote server adfs-2016-1.wingtiptoys.ca failed with the following error message : WinRM cannot complete the operation. Verify that the specified computer name is valid, that the computer is accessible over the network, and that a firewall exception for the WinRM service is enabled and allows access from this computer. By default, the WinRM firewall exception for public profiles limits access to remote computers within the same local subnet. For more information, see the about_Remote_Troubleshooting Help topic.
at System.Management.Automation.Runspaces.AsyncResult.EndInvoke()
at System.Management.Automation.Runspaces.Internal.RunspacePoolInternal.EndOpen(IAsyncResult asyncResult)
at Microsoft.Online.Identity.Federation.Powershell.PowerShellSession.VerifyAndReconnectRunSpacePool()
Authentication Prompt Due to Incorrect AD FS Server Name
Another cause for unexpected authentication prompts when using the Set-MsolADFSContext cmdlet is a typo in the specified AD FS server name.
Note that the WinRM service is running on the primary AD FS server. The server's FQDN is also displayed: ADFS-2016-1 - note though that in the below command an incorrect name will be used.
The "DF" in the server name was transposed. This is to demonstrate what will happen if the wrong name is used.
Set-MsolADFSContext –Computer AFDS-20161.wingtiptoys.ca
Note that the big red arrow indicates that the authentication request specifies the wrong server name AFDS-2016-1. The characters are transposed.
Enabling or Disabling PSRemoting Access Denied
In current versions of Windows we have the Disable-PSRemoting and Enable-PSRemoting cmdlets. On one AD FS 2016 lab system, I was not able to run these commands. They would both generate an access denied error.
For the search engines:
Disable-PSRemoting -Force
WARNING: Disabling the session configurations does not undo all the changes made by the Enable-PSRemoting or
Enable-PSSessionConfiguration cmdlet. You might have to manually undo the changes by following these steps:
1. Stop and disable the WinRM service.
2. Delete the listener that accepts requests on any IP address.
3. Disable the firewall exceptions for WS-Management communications.
4. Restore the value of the LocalAccountTokenFilterPolicy to 0, which restricts remote access to members of the
Administrators group on the computer.
remove-item : Access is denied.
At line:69 char:21
+ ... remove-item -path "$securityIDPath" -recurse -force
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Remove-Item], InvalidOperationException
+ FullyQualifiedErrorId : System.InvalidOperationException,Microsoft.PowerShell.Commands.RemoveItemCommand
new-item : Access is denied.
At line:74 char:21
+ new-item -path "$securityPath" -Sddl $sddl -force
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [New-Item], InvalidOperationException
+ FullyQualifiedErrorId : System.InvalidOperationException,Microsoft.PowerShell.Commands.NewItemCommand
PS C:>
PS C:> Enable-PSRemoting -Force
remove-item : Access is denied.
At line:69 char:21
+ ... remove-item -path "$securityIDPath" -recurse -force
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Remove-Item], InvalidOperationException
+ FullyQualifiedErrorId : System.InvalidOperationException,Microsoft.PowerShell.Commands.RemoveItemCommand
Looking at access denied errors in Sysinternal's Process Monitor we can see that there were issues writing to the registry.
Specifically this was under the key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WSMAN\Plugin\Microsoft.Windows.Internal.ADFS
PSRemoting should be enabled by default on current Windows builds. This should be verified prior to installing AD FS.
Cheers,
Rhoderick
If you take ownership and edit security, you can enable it.
I have exactly this problem with Enable-PSremoting, and the same registry access error, but how do you resolve that?
What user(s) or group(s) will should have write access to the registry ket?