FIM 2010 R2: Powershell remoting should be enabled on the remote server

This topic is intended to address a specific issue identified by a Best Practices Analyzer scan. You should apply the information in this topic only to computers that have had the Forefront Identity Manager 2010 R2 Best Practices Analyzer run against them and are experiencing the issue addressed by this topic. For more information about best practices and scans, see Best Practices Analyzer (https://go.microsoft.com/fwlink/?LinkId=122786).

Issue

Powershell remoting should be enabled on remote server.

Impact

Remote scans cannot be run on the target machine.

Resolution

Enable Powershell remoting on the remote machine before starting a scan.

In order to use the FIM 2010 R2 BPA you must ensure that Windows PowerShell Remoting is enabled on the server or servers that you wish to run the Best Practice Analyzer against. For more information on Windows PowerShell Remoting see Enable-PSRemoting.

Kerberos Issue with using the Best Practice Analyzer

The test environment used while writing the BPA documentation was that outlined in the Test Lab Guide: Installing Forefront Identity Manager 2010 R2. The following Kerberos failure was observed in the test environment when attempting to run Enable-PSRemoting.

Set-WSManQuickConfig : WinRM cannot process the request. The following error occured while using Negotiate authentication: An unknown security error occurred. 
Possible causes are: 
-The user name or password specified are invalid. 
-Kerberos is used when no authentication method and no user name are specified. 
-Kerberos accepts domain user names, but not local user names. 
-The Service Principal Name (SPN) for the remote computer name and port does not exist. 
-The client and remote computers are in different domains and there is no trust between the two domains. 
After checking for the above issues, try the following: 
-Check the Event Viewer for events related to authentication. 
-Change the authentication method; add the destination computer to the WinRM TrustedHosts configuration setting or use HTTPS transport. 
Note that computers in the TrustedHosts list might not be authenticated. 
-For more information about WinRM configuration, run the following command: winrm help config. 
At line:50 char:33 
+ Set-WSManQuickConfig <<<< -force 
+ CategoryInfo : InvalidOperation: (:) [Set-WSManQuickConfig], InvalidOperationException 
+ FullyQualifiedErrorId : WsManError,Microsoft.WSMan.Management.SetWSManQuickConfigCommand

This did not prevent the BPA from installing correctly, however, attempting to run it locally on the FIM server did not return any results and only the pre-requisite checks were completed.

Windows Remoting Windows Service uses the Network Service account. Windows Remoting also uses SOAP calls over HTTP and defaults to using Kerberos. The HTTP service class is one of the built-in services that act as an alias to the HOST SPN. The HOST SPN is mapped to the host computer account. Therefore, when you use the default HTTP service class, the Kerberos protocol uses the computer account as the service account to request a service ticket.

When we attempt to use Enable-PSRemoting we see that the Keberos request is to HTTP/FIM1.corp.contoso.com. So the Network Service account is looking for HTTP/FIM1.corp.contoso.com, but in reality it wants the host computer account and is using the HTTP as the alias. In any event this will fail because we have this SPN mapped to our SharePoint service account, which is a best practice.

Please be aware that this issue is with Windows Remoting and not with the Best Practice Analyzer itself. Once the issue with Windows Remoting has been corrected this should no longer be an issue. Until then, in order to work around this, the HTTP/FIM1 and HTTP/FIM1.corp.contoso.com SPNs had to be removed from our service account. Then the BPA was run successfully. After this, the SPNs were added back to the SharePoint Service account.

To locate the HTTP SPN

To locate the HTTP SPN on accounts in your domain, use the following procedure:

To locate the HTTP SPN

1. Log on to a domain controller with the appropriate credentials.

2. Click Start, select All Programs, click Accessories, and the click Command Prompt. This will bring up a command prompt.

3. In the command prompt type: Setspn.exe  –q HTTP/<server> . Where server is the netbios name of server you are attempting to run the BPA against. Hit Enter. This will return all of the accounts that have the HTTP SPN set on them.

   

To delete the HTTP SPN

In order to run the BPA, you may need to delete the HTTP SPN. To delete the HTTP SPN use the following procedure:

To delete the HTTP SPN

1. Log on to a domain controller with the appropriate credentials.

2. Click Start, select All Programs, click Accessories, and the click Command Prompt. This will bring up a command prompt.

3. In the command prompt type: Setspn.exe  –d HTTP/<server> . Where server is the netbios name of server you are attempting to run the BPA against. Hit Enter. This will remove the SPN.

   

4. In the command prompt type: Setspn.exe  –d HTTP/<server.fqdn> . Where server.fqdn is the fully qualified domain name of server you are attempting to run the BPA against. Hit Enter. This will remove the SPN.

To add the HTTP SPN

Once you have run the BPA, you may need to re-add the SPN back on to the accounts that you removed it from. To add the HTTP SPN use the following procedure:

To add the HTTP SPN

1. Log on to a domain controller with the appropriate credentials.

2. Click Start, select All Programs, click Accessories, and the click Command Prompt. This will bring up a command prompt.

3. In the command prompt type: Setspn.exe  –S HTTP/<server> . Where server is the netbios name of server you are attempting to run the BPA against. Hit Enter. This will remove the SPN.

   

4. In the command prompt type: Setspn.exe  –S HTTP/<server.fqdn> . Where server.fqdn is the fully qualified domain name of server you are attempting to run the BPA against. Hit Enter. This will remove the SPN.

   Note

   It is recommended to use –S as oppose to –A. Although –A is acceptable, -S will verify that the SPN does not exist on any other account before adding it.

Additional references

For more information, see the FIM 2010 R2 Deployment Guide (https://technet.microsoft.com/en-us/library/jj134310(v=ws.10))