Kerberos and the Disjoint Namespace

Recently, I was working with a client that was having a number of Kerberos problems. While reviewing their environment to troubleshoot their Kerberos issues I noticed something that is called a Disjoint Namespace. A Disjoint Namespace is when an Active Directory domain name is different than the DNS namespace that is used by machines in that domain. For example: Active Directory Domain Name mydomain.com DNS Namespace xyz.mydomain.com Having a Disjoint Namespace would cause Kerberos to fail in certain scenarios. To understand why, you need to first understand how Kerberos works. When a Kerberos client requests access to services in a domain (file server, web site, sql server, etc.) that client sends a service ticket request to a KDC (domain controller). The steps for this process are as follows:

  1. The client constructs a Kerberos KRB_TGS_REQ message. This message contains the user’s TGT and the SPN (Service Principal Name) of the service that is being accessed. This request is then sent to the KDC.
  2. The KDC will then query Active Directory and find the account object with the matching SPN that was submitted from the client. If more than one object with a matching SPN is found or if no matching object are found authentication will fail.
  3. If an object is found with a matching SPN then the KDC will construct the requested service ticket and send it back to the client as a KRB_TGS_REP message.
  4. Using the reply from the KDC the client then finishes setting up a secure communications session with the requested service. During the request process, a Kerberos client will self construct the SPN that is included in the Kerberos KRB_TGS_REQ message based on what service it is trying to access. For example, when requesting a web service through Internet Explorer the client will use the URL to construct the SPN. If the URL is http://xyz.mydomain.com then the SPN might look like HTTP/xyz.mydomain.com.

In Active Directory an SPN is a multivalue attribute that is always in the following format: [service class]/[host]:[port]/[service name] When a service in Active Directory registers an SPN the values for the host portion of the record can be in the form of a fully-qualified DNS name or a NetBIOS name of the host where the service is running. The DNS name for a host is called a full computer name and is a DNS fully qualified domain name (FQDN). A full computer name is constructed from the computer name (the first 15 bytes of the sAMAccountName of the computer account minus the $ character) and the DNS name of the domain in which the computer account exists. Ok, at this point you are probably wondering why Kerberos was failing. Well, Kerberos was failing because clients were trying to access services using FQDNs that did not relate to valid SPNs in Active Directory. For example:

  1. Client A wants to use services from server1.xyz.mydomain.com.
  2. Before connecting to the service Client A requests a TGS from the KDC with a SPN of HTTP/server1.xyz.mydomain.com.
  3. The KDC cannot find an object with an SPN of HTTP/server1.xyz.mydomain.com and denies the TGS request.
  4. Client A has to then request services from HTTP/server1.xyz.mydomain.com using another authentication method.

Remember by default, a Web server would (by default) have registered an SPN of HTTP/xyz.mydomain.com. If the client wanted access the SPN in the request should have been HTTP/xyx.mydomain.com. How to correct this issue? Believe it or not there are several options for correcting this problem. These options are as follows:

  1. Manually create the needed SPNs.
  2. Remove the Disjoint Namespace.
  3. Update the msDS-AllowedDNSSuffixes attribute.

In my humble opinion, options 1 and 2 don’t really correct the problem but are instead just work arounds. Microsoft makes it very clear (in documentation) that they don’t want Disjoint Namespaces used. Options 2 is the only valid solution to correcting the issue and it is the option that I suggested to the client I was working with. BTW - For all of today's Microsoft news, visit Microsoft Subnet

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.
Related:

Copyright © 2007 IDG Communications, Inc.

IT Salary Survey: The results are in