Kerberos is a protocol that, prior to Windows 2000 Server, Windows NT admins could ignore. At that time, Microsoft used NTLM for authentication, which was fine for the Windows world -- but nowhere else.
With the inception of Windows 2000, Microsoft adopted Kerberos as an authentication protocol. Not only was it much more secure and efficient than NTLM, but it also played nicely with other operating systems such as Unix.
Kerberos authentication and authorization
Before learning how Kerberos works in the world of Windows, it's best to first understand normal Kerberos authentication and authorization.
Authentication is the process of presenting credentials (username/password) to a service and having that service validate you. The process works like this, as illustrated in Figure 1:
When a user enters his or her username/password in a Kerberos environment, that information is sent to a server running the Authentication Service.
The Authentication Service passes that information to a database called the Key Distribution Center (KDC).
If the username/password checks out, the Authentication Service sends a Ticket Granting Ticket (TGT) to the client, allowing the client to complete the logon process. The TGT contains a time stamp, the public key and a certificate.
Authorization is the process of granting access to resources on a server that is in the network. Continuing from the authentication discussion, once the client gets the TGT, the client can then request access to resources. The TGT is presented to the Ticket Granting Service and requests a session ticket to access a resource on, say, Server 1. If Server 1 is in the domain, the Ticket Granting Service sees that there is a valid TGT, so credentials check out, and a session ticket is granted for Server 1. The client then presents the session ticket to Server 1 for access to a resource such as a printer, file share or document. Server 1 will then check access rights on that resource to see what the user can do (read, write, etc.).
Windows authentication and authorization
In a Windows domain, all of the Kerberos-related services just described are held by each domain controller. Even though there are several, including the KDC, we refer to them collectively as the KDC on a domain controller. The KDC, in fact, runs as a service (Kerberos Key Distribution Center service) on every DC, and all of this functionality can be turned off by stopping the service.
When a user presents credentials for authentication in a Windows domain, the same Kerberos authentication process described above is used -- with one exception. In order to find a domain controller that is also the KDC, a client must use the DC Locator process, which requires a DNS server to locate an appropriate DC and send that information back to the client. The client then passes the credentials to the domain controller, which grants the TGT and then a session ticket if the server to be accessed is in the DC's domain. The access rights are checked by the server and granted to the client.
Note that in addition to clients authenticating to have access to resources, domain controllers must also be authenticated in the domain in order to carry out certain processes, such as replication. If the DC authentication fails, then replication will fail with an error of Access Denied. This error will show up in Events and when running commands such as repadmin /showrepl.
Authentication and authorization across domains
Figure 2 shows a forest with three domains: a root domain called Company.com and two child domains called East and West.company.com. A client in West.company.com wants to access a resource on SRV1 in the East domain. The process is just as we have seen up to this point:
- The client contacts a DC/KDC in its domain and gets a TGT.
- The client attempts to get a session ticket for SRV1 from West's DC/KDC, but instead gets a referral to the root domain.
- The root domain then refers the request to the DC in the East domain. This DC/KDC in the East domain then grants a session ticket to the client for SRV1.
- The session ticket is presented to SRV1, which then determines the client's access rights to the resource.
Again, the authentication and authorization principles are the same for a single domain or for access to resources across domains.
Interoperability with Kerberos realms
One of the selling points of using Kerberos authentication was the fact that it would allow Windows users to access Unix resources and vise versa. In a Kerberos realm, a user object is referred to as a "principal." Figure 3 shows a realm principal trying to access resources in a Windows domain:
- The client gets a TGT from its authenticating KDC.
- A request for a session ticket to the Windows server presented to the realm KDC is sent via the Kerberos trust to the Windows DC.
- The Windows DC/KDC grants the session ticket for the Windows server.
- The session ticket is then presented to the server, which checks access rights.
But wait a minute. Doesn't Windows expect a SID to grant and determine access rights? And isn't it true that a realm principal has no idea what a SID is? That's true, but this issue is resolved by using name mapping.
In the Active Directory Users and Computers snap-in (ADUC), you can right-click on a user object and in the ensuing menu, you will see an option called "Name Mappings…." Figure 4 shows the dialog used to map realm principal names to a Windows user object.
Note: If you'd like, you can map multiple realm principals to a single Windows user to prevent you from creating individual Windows accounts for all realm principals.
Kerberos security features, as mentioned previously, are extremely attractive. Its security is highly dependant on secure time services. Our next article will describe how Windows Time service works, allowing us to dig into the authentication process a little deeper. After that, I will present a step-by-step procedure on how to join a Linux client (using Red Hat's Fedora client) to a Windows domain, taking advantage of the Kerberos interoperability features described here.
Do you have an Active Directory issue or problem that you'd like Gary to write an article about? Email him at glo11749@yahoo.com. Note: Gary cannot answer each query personally or guarantee that all will be answered. However those queries that have widespread interest or involve common AD issues will be addressed.
Gary Olsen is a systems software engineer for Hewlett-Packard in Global Solutions Engineering. He authored Windows 2000: Active Directory Design and Deployment and co-authored Windows Server 2003 on HP ProLiant Servers. Gary is a Microsoft MVP for Windows Server-File Systems.
