Unexpected consequences…

Having set-up a load balanced environment as per the previous post, I then discovered some knock on effects…

By changing the SPNs for HTTP to be account rather than machine specific, the remote Powershell calls were broken – so our automated deployments were broken. By default the WinRM service connection from the client to the target server is authenticated using kerberos. The communication channel is HTTP through a separate listener process and it expects a machine SPN to be registered. In our case it was expecting HTTP/LRSRV310.lr.aderant.com to be registered against the machine account LRSRV310. Instead this SPN was mapped to our application pool identity service.workflow.lr and so we were broken.

I added in the SPN mapping to the LRSRV310 machine account and remote Powershell sessions were available again however this meant duplicate SPNs in AD which is against the rules. After a little thought and some digging it turns out there are (at least) two options available to us:
1. use an HTTPS channel rather than HTTP for the WinRM service.
2. add the client machine names to the TrustedHosts list for WinRM.

I’ve tried option 2. and it works, though I think option 1 may be a more secure approach. To get option 2. to work, from a Powershell prompt:

PS> set-item WSMAN:\localhost\Client\TrustedHosts -value “*.aderant.com”

In the command above I’m using a wildcard but you can be more specific and list individual machines that you trust. Note that you need to enable the trusted hosts setting before you set up the SPNs against the application pool identity or else you won’t be able to use the WSMAN provider.

Update…
Turns out the TrustedHosts list option is not so great. It seems that this appears to work while the kerberos ticket is valid which makes it look like everything is good. The local access to WSMAN settings is available but remote access still has kerberos issues when the ticket expires. So next we will try setting up HTTPS for WinRM.

> winrm quickconfig -transport:https

However, this requires that a certificate is installed to validate the server identity. Tomorrow we will be using the certificate server for our domain to generate a certificate however not all environments will have this. I’ll also have a look at the other authentication options and try turning off kerberos support [WSMAN:\localhost\Service\Auth].

When we sort this out, I’ll post the solution.