Domanda
I have a system in which I use Kerberos with simple delegation to have an AD user's credentials forwarded from a website to a downstream HTTP REST service using integrated Windows authentication. All servers are Windows Server 2012 R2.
This works great.
The issue comes when I started doing Powershell remoting to the same servers that my backend HTTP service runs on. Enter-PSSession makes a Kerberos auth request for the WSMan service on the target machine. AD sees this request, and encrypts the requested ticket with the identity that my custom HTTP service runs as, which the WSMan service obviously cannot use, and remoting fails.
I know it's possible to force IE to do port-specific SPN requests (via KB908209), but I have not been able to have the 2nd hop (i.e. the IIS-brokered request) to do a port-specific request. Nor have I been able to get powershell to make a port-specific request on 5985 for WSMan.
To make things more concrete:
https://stackoverflow.com/questions/19437385
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russianhttp://ServerB:15200.If I have my SPN set up as HTTP/ServerB:15200, simple delegation in IIS fails, but powershell remoting works. If I have my SPN set up as HTTP/ServerB, simple delegation works but powershell remoting fails. If I have my SPN set up as HTTP/ServerB:5985, nothing works.
I am totally stumped at this point -- doesn't seem like delegation and per-port SPNs play nicely together?
Soluzione
You can workaround this by setting up an alias for ServerB, give the HTTP/ServerBAlias SPN to the IIS account and HTTP/ServerB to the PS account, and then make ServerA send its requests to ServerBAlias. Or use the FQDN (e.g. ServerB.domain.local) in one SPN and the NETBIOS in the other (e.g. ServerB).
Or, you can look at how this person hosted WinRM in IIS with a custom account.
Altri suggerimenti
Do you have ms-DS-Allowed-to-Delegate-to attribute for HTTP/ServerA set to the list of HTTP/ServerB and HTTP/ServerB:15200?
