Remote PowerShell with SharePoint 2010 Kerberos
Deploying SharePoint 2010 Solutions with Powershell
June 25, 2013Remove Drop Off Library and fix up the QuickLaunch in SharePoint 2010
September 17, 2013
I have a SharePoint 2010 environment set-up with Kerberos authentication, which works well, however I wanted to enable PowerShell Remoting to perform some tasks from another machine.
There are a lot of blog posts out there on how to accomplish this however I was encountering an issue I had trouble resolving.
To enable PowerShell Remoting type the following on the SharePoint server:
Enable-PSRemoting -Force
I was receiving the below Kerberos error:
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
Checking the System event logs:
According to TechNet the 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/SP2010.domain.com. So the Network Service account is looking for HTTP/SP2010.domain.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.
To locate/add the SPN:
On the SharePoint Server in your PowerShell window type:
Setspn.exe -s HTTP/<server> <server>
Using -S will verify that the SPN does not exist on any other account before adding it.
Using -q HTTP/<server> will locate the account where the SPN exists so is an acceptable alternative.
As you can see in my screen shot, my service account ‘FindIT Administrator’ has the SPN associated, in my case it is OK to remove the SPN as HTTP/Intranet is the main web application and an Alias to SP2010.
Note: If using -S and you don’t have a duplicate, you will not need to delete and add the SPN as in the following steps, as it will add it for you.
To delete the HTTP SPN
Setspn.exe -d HTTP/<server>
where server is the netbios name
Setspn.exe -d HTTP/<Server.fqdn>
where server.fqdn is the fully qualified domain name of the server.
Setspn.exe -s HTTP/<server> <server>
Once complete you could confirm running Setspn.exe -q HTTP/sp2010
Now we should be sweet to enable PowerShell Remoting.
Enable-PSRemoting -Force
Test PowerShell Remoting by jumping into local host:
Enter-PSSession -Computername localhost
To exit:
Exit-PSSession
On a remote computer you should now be able to create a remote PowerShell session to the SharePoint Server.
Note, in my testing initially I temporarily removed the SPN from Find Administrator and Re-added back after successfully enabling PSRemoting. On the SharePoint server I could successfully remote into localhost however on the remote computer I was receiving an error 0x8033809D. To resolve I completed the above.
