Kerberos is one of the more secure options that you have when deploying a network. It is also one of the more complex and intimidating options (maybe that contributes to it’s security 😉 ). But it is worthwhile to deploy in a network to increase security when accessing resources, and since a major component of Microsoft Active Directory is Kerberos, most networks already have the basic building blocks. First of all, I ran across Ken Schaefer’s blog, which gave a really good foundation in Kerberos and delegation in an IIS setting. They are very much worth a read to get yourself in gear for this topic:
IIS and Kerberos Part 1 – What is Kerberos and how does it work?
IIS and Kerberos Part 2 – What are Service Principal Names?
IIS and Kerberos Part 3 – A simple scenario
IIS and Kerberos Part 4 – A simple delegation scenario
IIS and Kerberos Part 5 – Constrained Delegation
Most guides I read offer a good rule of thumb: when accessing resources from internal/intranet clients, use Kerberos; when accessing resources from outside, use some other form of authentication. Overall you would follow that guideline. Kerberos depends on a lot of internal resources… for example, the kerberos ticket granting centre is traditionally the Domain Controller, which is secure on the internal network. Only valid, authenticated domain users are allowed to request tickets, so usually they should be signed in on an internal domain PC.
All the above, and other reasons, is that usually when outside clients need to access resources (say an internet user checking their webmail, or a proxy, etc) they usually use BASIC authentication. NTLM is another option, but some non-windows clients have difficulty implementing this. BASIC authentication is a bit of a problem, the credentials are simply obfuscated using Base64, so not exactly secure. Most of the time this is not a problem, because basic authentication is only used on the inside (supposedly trusted) network. Even when outside clients log in, they usually login to the network via an intermediate system, such as an ssl vpn system or a proxy. The communication between the client and the intermediate node is usually secured with SSL or similar, and then the communication between the intermediate node and the internal server is sent in BASIC.
While typically secure enough, some situations demand more security (think banks, governments, etc). This means eliminating sending out BASIC credentials altogether. This is where constrained kerberos delegation steps in. Kerberos delegation allows the intermediate node (SSL VPN or PROXY) to request permission to access an internal domain server on behalf of another user, all by using secure kerberos.
The BlueCoat proxySG has such a capability, by integrating with the BCAAA (BlueCoat Authentication and Authorization Agent). To make it clearer, what we are trying to achieve is:
The client needs only login once to the proxy, and the proxy automatically authenticates them to the server in a secure way using the credentials provided, resulting in a secure Single Sign On. There are more technical details in the proxySG administration guide. However, here are some notes taken when I had to setup the above system… (keep your eyes open for a BlueCoat KB article on this)
——————————————————————————
Configuring constrained Kerberos Delegation.
On the proxy side of things:
1. Setup IWA realm as per normal
2. Enable the proxy to use SSL, ensure allow Kerberos creds is allowed
3. Import the domain CA and the client certificate into the proxy.
4. Define a new ssl device profile and include the domain CA, client certificate
5. Make sure the proxy is using a DNS server that can resolve the OCS names (kerb delegation only works with FQDNs)
6. Define web auth layer that for OCS, require constrained kerb delegation.
On the BCAAA side of things:
1. Setup BCAAA as normal. During install ensure that you allow SSL connections (no need to require them)
2. Open the bcaaa.ini and ensure : VerifySG=1
3. Change the BCAAA service to make sure it is running as a domain user (eg domain admin)
4. Start > run > gpedit.msc. Under security settings > local policies > user rights assignment, make sure the BCAAA user is allowed to run as part of operating system. Note, if the BCAAA agent == domain controller, modify the Default Domain Controller policy instead
At this point, test if normal IWA authentication works, by defining some policy which only allows authenticated IWA users out to the internet. It should work
On the domain controller side of things:
1. Open AD “Users and Computers”. Select the PC where the bcaaa agent is installed on, RC and click on the delegation tab. Similar to below:
Where “appserver.davidv.local” is the OCS you want the end user to authenticate to. In this case it’s an HTTP server. NOTE: you need to have the HOST service type (and probably the HTTP) defined as allowed
2. Select the BCAAA user account and do the same as above for delegation
Note : if you do not see the correct service or computer in the above list, you will need to run the setspn command, eg: setspn –a http/appserver.davidv.local DAVIDV\administrator. DO NOT define the same service / spn twice or the KRB will break (setspn –l [user] is useful here…)
On the OCS side of things (in my case appserver.davidv.local)
Just setup a webserver, make sure IWA authentication is enabled, and define the correct perms on the files/folders
——————————————————————————
Just a note… during troubleshooting there are two things I found invaluable:
- Enabling failure auditing on the Domain Controller, IIS server. This is done via local security policy (gpedit.msc > Compter Configuration > Windows Settings > Secuirty Settings > Local Policies > Audit Policy). This helps a lot when assessing why exactly the server(s) are not accepting your login attempts. It’s not on by default
- Run a packet capture on every node you can…Wireshark is amazing and gives you details why something is failing. For example, In my case I had an issue where the IIS server just did not want to accept my credentials. A packet capture showed that I had configured the Proxy to ask for the http/server.local SPN, but the host/server.local SPN was replying. That gave me the reason to configure the proxy to ask for the HOST spn instead, and to configure the AD DC to allow delegation of the HOST spn rather than just the HTTP spn
Update: Here’s the link to the official bluecoat KB article I worte. Very similar to the above
David Vassallo's Blog 
Great blog post, very helpful!
setspn -s will first verify if there are duplicates which should eliminate the chance for dupes. You can also do an setspn -F -S which will search the whole forest if you have multiple domains.