PS remoting with Kerberos authenticated sites

Article
2010-07-06

Question

_{Tuesday, July 6, 2010 1:15 PM}

Hi everyone,

I was looking at the fabulous PowerShell Remoting feature and had it functional on a Windows 2003 server. Really cool !

Then I tried to activated it on a Windows 2008 R2 with Sharepoint 2010 configured with Kerberos authenticated sites. Fail.
It seems that WinRM needs an SPN HTTP for the machine name itself whereas If I do that, I'll get stuck with duplicate SPNs (Application pool service account already has a HTTP SPN). I tried removing the service account SPN and create the machine SPN and then it works.

So my question is in the title :
How are you supposed to configure PS Remoting with an already Kerberos-authentication website configured without having SPN duplicate issues ?

Thanks!
Wes

All replies (17)

_{Friday, December 9, 2011 9:18 PM ✅Answered}

Quick update on this as I have more infos.

The DNS workaround you mention fsocas is in the case that WinRM (or enable-PSRemote) is actually working and running.

In my case, it's not the case because WinRM isn't able to "activate" the listener, it will trigger a security error before doing it.

For your case fsocas, I suppose you could just use this method to make it work :

On your machine (from which you ps-remote):

Set-Item WSMAN:\localhost\Client\TrustedHosts -value 'ip address of the server'

So here's the complete scenario I have.

SharePoint 2010 server with Central admin running on it using this url : http://name-of-the-server:8080
This url uses an application pool running under a domain account (let's call him domain\mycentraladmin)

To setup Kerberos, I added the corresponding SPNs to the domain account of the application pool (domain\mycentraladmin) :
- HTTP\name-of-the-server
- HTTP\name-of-the-server.domain.org
- HTTP\name-of-the-server:8080
- HTTP\name-of-the-server.domain.org:8080

So the Central admin site uses Kerberos for authentication. Everything works.

Running "Enable-PSRemoting -force" wll fail with this error :

Set-WSManQuickConfig : WinRM cannot process the request. The following error occured while using Negotiate authenticati
on: An unknown security error occurred.

or more specifically (using winrm command directly)

Error number:  -2144108387 0x8033809D
An unknown security error occurred.

So, since WinRM seems to check for a HTTP SPN set on the computer object (HTTP\name-of-the-server), it will always fail because it will find the HTTP SPN but not set on the computer object. Thus, it cannot authenticate using Kerberos and just fails.

To have a proper configuration, I found out an interesting fact : http://blogs.dirteam.com/blogs/tomek/archive/2009/12/20/kerberos-a-sprawa-portu.aspx
Internet Explorer only checks for a HTTP SPN on the default HTTP port (80). To force him to check the HTTP SPN with the port, you need to add a specific registry key.
Here's my simple Powershell script for this:

$Reg_Key = "HKLM:\SOFTWARE\WOW6432Node\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_INCLUDE_PORT_IN_SPN_KB908209"
New-item -type Directory $Reg_Key
New-ItemProperty -Path $Reg_Key -Name "iexplore.exe" -value "1" -propertytype dword

Note that this needs to be done on the client side (your machine).

Now, I modified the SPN configuration. It now looks like :

HTTP\name-of-the-server:8080
HTTP\name-of-the-server.domain.org:8080
I remove the default HTTP SPNs (which were necessary before applying the registry key to connect by Kerberos on the Central admin). But with the registry key in place, I'm able to log on to the Central admin with Kerberos.

With this working, I went on the server and triggered the cmdlet "Enable-PSRemoting -force". Success :)

Et voilà ! A nice setup without any dirty workaround.

_{Tuesday, July 6, 2010 1:34 PM | 1 vote}

OK, I don't know how to help you right now, but does this provide any insight on creating SPNs manually as to avoid dups?

http://markiwaszko.blogspot.com/2010/06/viewing-sharepoint-2010-sites-on.html

_{Tuesday, July 6, 2010 2:10 PM}

Thanks for the reply but I don't have any issues to create the SPN.

Actually, I have one SPN for my Sharepoint 2010 App pool. This is working, the webste authenticates with Kerberos.
The App pool runs under DomainNane\svc_farm_admin. My SPNs are configured this way :

SetSPN -L DomainNane\svc_farm_admin
HTTP\MachineName
HTTP\MachineName.DomainName

SetSPN -L MachineName
*Default SPNs ; no HTTP SPN*

So my SPN configuration is OK as for Sharepoint 2010. No issues there.
But when I try to activate PS Remoting, WinRM uses http to communicate and seems to need a machine SPN in order to authenticate remote users. That's where it block because if I create a HTTP SPN for the machine, I'll have SPN duplicate and nothing works.
IE I would have :

SetSPN -L DomainNane\svc_farm_admin
HTTP\MachineName
HTTP\MachineName.DomainName

SetSPN -L MachineName
HTTP\MachineName
HTTP\MachineName.DomainNae
* Plus default SPNs*

Do you see the issue ?
It seems you can't have Kerberos authentication in IIS and WinRM. It's either one or the other.

_{Tuesday, July 6, 2010 2:24 PM}

Unfortunately, there's no solution here either:

http://social.technet.microsoft.com/Forums/en-US/windowsserver2008r2management/thread/bb623545-f68f-41a0-8f71-e6f4b9da7a3b

_{Tuesday, July 6, 2010 2:38 PM}

Glad to see I'm not the only one to have bumped in the problem.

Seems to be a major flaw in the WinRM implementation IMO. Hope that this gets fixed somehow.

Thanks for the "semi-answer" Marco !

_{Wednesday, July 7, 2010 12:50 AM}

I've managed to make contact with someone in the WinRM team to see if they have any feedback to provide.

_{Monday, July 19, 2010 11:24 PM}

Any update on this? We are having the same problem.

Now, I will say...it's a better idea to use a DNS alias to register a HTTP DSN (instead of HTTP/machinename)...but my team didn't set this stuff up, and I don't want to break anything.

We have some Sharepoint, SSRS and Unified Communications all setup like this.

I'm hoping there is some low impact elegant solution out there. Otherwise it is a major flaw. I've written a ton of system compliance checks to run across our enterprise using remoting. Would be a shame if I had to scrap it because of something like this.

_{Tuesday, July 20, 2010 1:00 PM}

Thanks for the feedback.

Just one question, I assume you added A records for your SPNs ? So this doubles the DNS entries for each server if I'm correct.
This is a good idea but with thousands of servers, the DNS management is a hard thing to maintain.

_{Tuesday, November 8, 2011 12:23 PM}

Hi,

What I've done and works great in cases where you have SPNs set for computername, is use an alias.

If you have SPN registered to a domain account (needed for Kerberos auth.) like these:

HTTP/computername

HTTP/computername.domain

You won’t be able to use PS Remoting, to connect to "computername"

In these cases, I create an alias for "compuername" such as "computername_credssp" and remote to this.

Hope it helps son late comers’ like me!

Regards,

Fernando

_{Wednesday, November 16, 2011 3:22 PM}

When you state that you create an alias for "computername", where are you creating the alias? The situation I have is trying to use PS Remoting on a server that also is a web server requiring Integrated Windows Security.

_{Tuesday, November 22, 2011 6:38 PM}

Michel,

I register the "alias" records in my "HOSTS"

I use it to connect to a SharePoint 2010 Server (IIS 7.5) with Windows Authentication (Kerberos enabled)

When I access the SharePoint Server via web I use the real name: http://computername

When I connect using PowerShell with CredSSP, I use: computername_credssp

Regards,

Fernando

P.S. Sorry for the delayed reply!

P.S.2. The answer sent to Wesley was my mistake!

_{Wednesday, November 23, 2011 8:39 PM}

Michel,

I register the "alias" records in my "HOSTS"

I use it to connect to a SharePoint 2010 Server (IIS 7.5) with Windows Authentication (Kerberos enabled)

When I access the SharePoint Server via web I use the real name: http://computername

When I connect using PowerShell with CredSSP, I use: computername_credssp

Regards,

Fernando

P.S. Sorry for the delayed reply!

P.S.2. The answer sent to Wesley was my mistake!

Thank you Fernando. We have been working with a 2003 server and it's been quite a pain. Going to start with a 2008 server and give it a try. I appreciate your help.

_{Friday, November 25, 2011 2:07 PM}

You're welcome, y you need any help, let me know.

Regards,

Fernando

_{Friday, November 25, 2011 3:40 PM}

Thanks for the workaround fsocas.

It's actually a very good idea althought I don't see this has a real fix.
This will add for sure extra management for each servers where it needs to be powershell remotely accessed along with a Kerberos-site but I must admit your solution does work.

Regards,
Wes.

_{Tuesday, February 11, 2014 9:26 PM}

it is not proper to use an http spn for the machine itself, since the host spn handles this. If you need to use the machine name - remove the http spn, and enable kernel mode auth in IIS.

_{Thursday, January 14, 2016 3:21 PM}

Hi wrecklesswun,

You cannot use kernel mode on SharePoint. Also, using manual HTTP SPN is still the way to go if you can't make use of kernel mode with the attribute "useAppPoolCredentials". Lastly, you would have issues in case of web farm if you rely only on machine name.

_{Saturday, May 27, 2017 7:06 PM}

I was getting an error just like this running TFS express on a server. I could connect with hostname, but not hostname.fqdn. I deleted http/hostname.fdqn from the TFSExpress account, and it works! This was also preventing me from using Server Manager to manage it, since it always uses the FQDN to connect over WinRM.

BTW, TFS _does_ still work over port 8080, which is the only port TFS listens on in my environment.

KeepMyIdentities, Your Key to Password Security. Available now on the Windows Store: http://apps.microsoft.com/webpdp/en-US/app/keepmyidentities/61a9f340-97ac-4666-beab-39f9246cb6fa

Share via

PS remoting with Kerberos authenticated sites

Question

All replies (17)

Additional resources