Just another quick note on something I stumbled across recently that hopefully someone finds it useful.

Assuming you use a HTTP/HTTPS web proxy and you want authentication so that you can log requests against specific users chances are you are using Kerberos authentication.

The alternative is basic (but then your users get prompted) or NTLM. The problem with NTLM is that it is comparitively heavy and if you require authentication for each connection is not feasable once you reach a certain size.

Kerberos uses a fraction of the resources of NTLM and allows for seamless high performance authentication. You can read more about how it actually works on technet here.

An important part of Kerberos is the server name. For a proxy server it's derived from the FQDN of the proxy. However something important to note is that Kerberos fully resolves the FQDN including CNAMES.

This means if you have proxy.redmond.com as a nice service DNS but you CNAME it to server50.redmond.com the Kerberos ticket will be issued against server50.redmond.com and NOT proxy.redmond.com.

So say you change the CNAME and suddenly SSO is no longer working and it's driving your users nuts. They get prompted and when you do a packet capture you can see that the users machine is waiting for credentials to ask for a Kerberos token. But why would it suddenly do this? It worked fine before?

Something I didn't know is that by default SSO only functions for sites in the "Intranet" IE security zone. Now the proxy isn't a site but it must still fall into the "Intranet" security zone for SSO to work. So how best to do that? We could use GPO to push a rule making server50.redmond.com sit in the "Intranet" zone.