active directory kerberos extras

Various versions of Microsoft Active Directory extend the Kerberos protocol or some of the behind-the-scenes implementation. This section points out some of the common hidden extras relevant to those interacting with Active Directory over the wire.

service principal mappings

As mentioned earlier, the servicePrincipalName class on each service's corresponding Active Directory object is used by the Active Directory KDC to find the key based on which to issue service tickets for clients. These SPNs are string representations of Kerberos principals, for example: cifs/ The realm is generally left off, as it's implied by the domain the account exists in.

Active Directory supports a HOST service type, which is a catch-all SPN if an explicit one is not found. Many Microsoft Windows clients will register a single HOST principal instead of an SPN for each service it wishes to provide.

This catch-all doesn't quite catch all. Active Directory will treat the HOST service type as a valid substitution for any service named in the sPNMappings Active Directory attribute, which by default lives on an nTDSService object called Directory Service under the CN=Configuration tree.

This is typically forest-wide and applies to all domains within the forest.

LDIF output of this object and attributes relevant to this particular topic might look like the following:

dn: CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=incompl
objectClass: top
objectClass: nTDSService
cn: Directory Service
sPNMappings: host=alerter,appmgmt,cisvc,clipsrv,browser,dhcp,dnscache,replicat

In this example, a service ticket request for dns/ may also be satisfied using the key attached to the Active Directory object that contains the SPN HOST/ if no explicit SPN match is made.

Other custom mappings may be made by adding additional sPNMappings attributes to that same object.

cross-realm service principal resolution

If a client is unsure of the realm that a service exists in, it may just append its default realm (very common). The KDC for that realm will not have any inherent knowledge in its own database of this service principal, which would normally be expected to fail.

In this case, the KDC may perform a lookup against something called the Global Catalogue, or GC, (see the active directory ldap extras section for more detail) for that principal. The GC contains the SPNs for the whole forest, amongst other things.

In the case of non-forest (external) domain trusts, this isn't possible by default. There are ways to provide relevant hints.

Twitter: @IncompleteIO