The Kerberos protocol, like the three-headed dog from Greek mythology from which it gets its name, guards a computing...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
environment with three primary components – server, client and a trusted third party. The trusted third party, Kerberos, manages shared secrets to allow a user to access resources on the client and server in a secure manner.
Kerberos is implemented with an Authentication Service (AS) and a Ticket Granting Service (TGS). Active Directory domain controllers (DCs) implement both services. These services run in a Unix realm to perform these functions as well. DCs are also referred to as Key Distribution Centers (KDCs). An account and password are created on the AS and stored in the database. The Kerberos client service takes the plain text password, adds a text string to it (which is the user name) then runs this through a program called String2key and stores the result as a “shared secret.”
When the user logs on to a workstation, he enters a username and password. The Kerberos client service on the workstation uses the same algorithm to come up with the shared secret. The shared secret is used to encrypt the AS_REQ packet, which requests a Ticket Granting Ticket (TGT). If the shared secret for that user matches what the server has for that user, the packet is read, and an encrypted TGT is returned to the user (AS_REP). The TGT is proof that the user is who they say they are and can be safely granted access to resources. Important: the password is never transmitted across the wire.
Figure 1 shows an overview of the Kerberos Authentication (logon) and Authorization (access to network resources) processes. After obtaining the TGT, the TGT is presented to the Ticket Granting Service. TGS to request services such as a login, or access to a share, application or device such as a printer. The TGT is sent in the TGS_REQ to the TGS, encrypted with the user’s shared secret. The TGS, like the AS, compares the stored shared secret for that user and if it is a match, the TGS_REQ is opened, read and honored. The TGS returns the TGS_REP and encrypts a service ticket with a “session key.” The client can open the TGS_REP and obtain the service ticket but cannot open the key itself – only a server can do that, since only a server knows the session key.
In Figure 2, the Authenticator is illustrated, which is sent via the AP_REQ. This contains the service ticket, presents it to the application server which knows the session key and honors the request. At this point, the user’s permissions to the resource (read, write, etc.) would be checked for proper task access. Note that the Authenticator also contains a timestamp which is the time the packet was created on the client. This is used to prevent replay attacks where an intruder takes a legitimate packet and presents it to the server. If this is attempted at the same time or after the time stamp, the packet is rejected. There is also a comparison to the server’s time stamp. If that difference is greater than 5 minutes, the packet is rejected, making time synchronization between all computers on the network critical. This is each computer’s system clock which is always UTC time and not affected by time zones.
Interoperability between Windows forests/domains and MIT Kerberos realms in Unix and Linux environments is possible because the Kerberos process and protocol are implemented similar enough to enable compatibility. In the Windows implementation, a DNS request is sent to locate the DC/KDC. The AS_REQ is sent to the DC to obtain the TGT as described previously.
To demonstrate Kerberos interoperability, consider the following scenarios. Note that each one follows the authentication and authorization process described previously and illustrated in Figure 1.
Scenario 1: Windows inter-domain
In Figure 3, authentication between Windows domains is shown. The client in the AMS.corp.net domain needs access to resources to a server in the EMEA.corp.net domain. The request for the TGT is obtained from an AMS.corp.net DC in order to logon. Since the application server is in the EMEA domain the AMS DC generates a “remote” TGT for the EMEA domain by virtue of the trust between domains. The EMEA TGT is then presented to the EMEA DC (the TGS), and a service ticked for the EMEA app server is returned to the client who then presents it to the EMEA server.
Scenario 2: Cross Platform: Unix realm client accessing Windows resource
Figure 4 shows a similar configuration as described in Scenario 1, except the client is a member of a Unix realm, desiring access to resources on a server in a Windows domain. Remember “Kerberos is Kerberos” in this environment. The authentication and authorization steps are the same as in Scenario 1. The MIT KDC issues a remote TGT for the windows domain (assuming the trust between domains). The remote TGT is presented to the Windows DC who grants the service ticket and the client presents that to the Windows server. The only gotcha here is that Unix knows nothing about SIDs or GUIDs or Windows authentication, groups, etc. Windows provides a name-mapping function that allows mapping of a Unix realm account to a Windows account which has the SID, group memberships and permissions. This is a feature in the Users and Computers snap-in – Advanced Features – Name Mapping. The dialog is shown in Figure 5. It is possible to map the accounts one to one or one to many (one windows account can be mapped to multiple Unix accounts). This is commonly done when using NFS to access files between systems. Note that name mapping is not always required.
Scenario 3: Unix/Linux offering domain protected service
In this case (Figure 5), a Linux application server provides a “domain protected service” to Windows clients. An example of this is Samba. To make this work, the following are required for the Unix/Linux Server:
- A computer account in the domain
- Krb5.conf file – this identifies the Windows KDC to access via the FQDN or IP address AD user object to use for TGT, Kerberos client.
- Krb5.keytab – encrypted key storage – service generate same key that is generated with the computer account to encrypt and decrypt packets
- Service that is Windows aware
There is of course a shared secret between the computer account and the application server. The encryption key for the shared secret is associated and stored with the computer object on the Windows server and in the keytab file on Unix/Linux server.
At this point, the Kerberos conversation for authentication and authorization is as described previously to get access to the service. Note that since the service ticket was generated by a Windows KDC and passed by Windows client, it will contain Windows authentication data. Whether that data is used depends on the application server being Active Directory aware.
Understanding Kerberos is fundamental to understanding authorization (logon) and authentication (resource access) in a Windows environment. With many organizations using Linux and Unix clients and servers offering services, it is important to understand how Kerberos provides interoperability between platforms. There are some excellent articles on Microsoft’s TechNet, like this (slightly outdated) guide to Kerberos 5.
I'd like to thank Don McCall of HP for his contribution to the content and figures of this article. Don and I presented a Kerberos session at TechEd North America 2011 on which this article is based.
ABOUT THE AUTHOR
Gary Olsen is a systems software engineer for HP in Global Solutions Engineering. He has authored or co-authored several books, including Windows 2000: Active Directory Design and Deployment and Windows Server 2003 on HP ProLiant Servers.