Active Directory Authentication – Part 2

In part 1, we talked about authentication via NTLM and how the domain controllers that are used to authenticate you are the ones near the service that is being consumed. Now let us move onto Kerberos.

Just like last time I need to point at a TechNet Article, How DNS Support for Active Directory Works. The article goes into great detail about which DNS records are registered, how automatic site coverage works, as well as the often confused Weight and Priority attributes of the DNS records.

Kerberos Authentication

Kerberos authentication has it roots in the 1980s, and the currently used v5 standard come out in 1993. Kerberos is a ticket based authentication system. It uses symmetric keys and realm trusts to create a trusted ticket to access a service.

The key to Kerberos is Service Principal Names (SPN). All Kerberos authentication starts with the client asking for a ticket for a particular service, e.g. HOST\server1.contoso.com or HTTP\www.contoso.com. You can see the list of SPNs registered against an Active Directory object by using SetSPN -L. If a service specific SPN doesn’t exist but for the same name there is a HOST SPN then the HOST SPN is used instead. SPNs must be unique within a forest, if the are not then you are likely to see the dreaded KRB_AP_ERR_MODIFIED. This is why for any load balanced service that wants to use Kerberos there must be a service account with the correct SPNs registered against it, and that service account then needs to be used on all Load Balance Members.

So unlike NTLM where the server does all the work to validate the client, in Kerberos it is the client that does all the work to get a suitable ticket for the service it wants to access. Again in a single site, single domain, single forest network this is of no consequence whatsoever, but if we scale this out to multiple AD sites, multiple domains and perhaps even multiple forests and the picture gets more and more complicated. To help visualise the more complex scenario I have drawn up the following picture. Here there are two forests, a multi-domain user forest (contoso.com) and the single-domain resource forest (msg.contoso.com). We are using an Outlook client with an Exchange server (since that is what we know best) but the same applies for any client/server interaction.

1. A UK domain based user opens Outlook
2. Outlook runs autodiscover and connects to the Exchange server
3. The Exchange server responds and asks for authentication
4. Outlook contacts a UK Global Catalog asking for a service ticket for a specific SPN
5. The UK Global Catalog has a parent-child trust to EUROPE so hands back a referral
6. Outlook contacts a EUROPE Global Catalog asking for a service ticket for the SPN
7. The EUROPE Global Catalog has a parent-child trust to CONTOSO.COM so hands back a referral
8. Outlook contacts a CONTOSO.COM Global Catalog asking for a service ticket for the SPN
9. The CONTOSO.COM Global Catalog has a forest trust to MSG so hands back a referral
10. Outlook contacts a MSG Global Catalog asking for a service ticket for the SPN
11. The MSG Global Catalog hands back a service ticket for the SPN
12. Outlook presents the service ticket to the Exchange Server

The user is now either granted access or denied access, authorisation is performed on the Exchange server with consultation of the MSG Global Catalog

NOTE: for simplicity it is assumed that the Global Catalog selected is also the closest Domain Controller, and acts as the KDC. Furthermore the service ticket is valid for 10 hours, so until the ticket expires the client does not need to get another ticket to access the same service.

As you can see again there is a lot going on under the covers, but this time the client has done all the work plus the ticket itself is cached by the client so that it doesn’t need to repeat this for every authentication (as opposed to NTLM for which the server does need to validate the response for every authentication). The server can validate the ticket quite quickly and without consulting a DC, as it knows the symmetric key from the application’s account.

Kerberos and IIS

One thing to be aware of is that by default an IIS server will validate the Kerberos ticket every single time. Luckily there is a applicationHost.Config attribute to reduce this to once per session. This is called authPersistNonNTLM and is explained in more detail in IIS Configuration Reference

When is Kerberos not used

There are cases where Kerberos is not able to be used

• When you access a service by IP address
• When you access a service in a non trusted forest
• When you access a servers in a forest trusted via a legacy NTLM trust
• When the firewall ports (typically port 88 udp/tcp) are bloacked
• When the SPNs for a service are not registered on an AD object
• When the same SPN is registered on more than one AD object
• When the time between the server and client has skewed beyond the threshold (generally 15 mins)

In most of the above cases if the application is set to Negotiate then it will fail back to using NTLM instead. Now there is an exception here which is if Outlook is set to Negotiate, the user account is in a multi-domain forest, Exchange is in a resource forest, there is a forest trust but the SPN is not registered within the resource forest. In this case we’ve seen Outlook ask for credentials continuously and is unable to connect at all. That only took about a week or so to figure out… :o)

I hope you have enjoyed these two parts on Active Directory Authentication. There is more to authentication of course, and we may add to this series with oAuth and Claims Based Authentication (as study time allows :o))