0

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:

  1. Client browser makes a request to ServerA. Browser makes a Kerberos ticket request to AD for HTTP/ServerA, which is granted and then sent to ServerA.
  2. ServerA wants to make a delegated request to http://ServerB:15200.
  3. ServerA makes a request to AD for a Kerberos ticket for SPN HTTP/ServerB. It does not make a request for SPN HTTP/ServerB:15200. I want it to.

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?

stames
  • 1,250
  • 1
  • 10
  • 16

2 Answers2

1

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.

Sean Hall
  • 7,629
  • 2
  • 29
  • 44
  • Yes, the request from ServerA to ServerB is using 15200. If I set up SPNs for both HTTP/ServerB and HTTP/ServerB:15200 using the IIS app pool identity, powershell remoting fails. If I set up just HTTP/ServerB with the machine identity (NETWORK SERVICE), PS remoting works but the 2nd Kerberos hop fails because IIS doesn't make an SPN request for :15200. – stames Oct 21 '13 at 03:56
  • Sorry, I'm not familiar with how IIS constructs the target Kerberos identity, or the details of setting up PS remoting. I don't understand how you're serving HTTP requests and PS remoting on the same port. Regardless, they're looking for different SPNs, so you should be able to assign HTTP/ServerB to IIS's account and HTTP/ServerB:15200 to PS's account. – Sean Hall Oct 21 '13 at 12:35
  • The PS remoting and HTTP requests are not on the same port -- PS remoting uses 5985 and I'm using 15200, but as you said the details of how IIS and powershell.exe construct target SPNs for their requests to the domain controller is the issue :/ They both seem to ignore the target port and just request vanilla HTTP/ServerB as the SPN for the request. – stames Oct 21 '13 at 14:55
  • @stames I edited my answer, one of those options should work. – Sean Hall Oct 21 '13 at 17:00
  • The alias didn't work (behind the scenes the domain controller still looked up the ServerB SPN instead of ServerBAlias), but I managed to set it up successfully where PS remoting uses the NETBIOS name and my app uses FQDN. Thanks! – stames Oct 21 '13 at 23:52
0

Do you have ms-DS-Allowed-to-Delegate-to attribute for HTTP/ServerA set to the list of HTTP/ServerB and HTTP/ServerB:15200?

abbra
  • 852
  • 5
  • 6