Understanding Kerberos Basics

Kerberos provides secure authentication to a variety of network services. It also supports SSO, so users can access all of these resources by logging in just once. While extremely interesting, the background of Kerberos won't help you learn how to integrate Mac OS X with Kerberos and troubleshoot problems. Instead, let's take a look at how Kerberos works.

Note

To further your background knowledge of Kerberos, refer to the "References" section, at the end of this lesson.

Meeting Requestor Needs

In a directory-services environment, servers on the network provide services; then clients request those services. Requestors like Login Window or the Mail application need to authenticate file or mail servers, authorize particular tasks, and centralize password management so that each person has to remember only a single password to access all network services. That provides a better user experience, but it still does not address the fact that the password may be used on each server to authenticate the usersomething that is not in the best interest of keeping your network secure. But Kerberos addresses that issue, as well.

This figure illustrates how Mac OS X leverages identification information from one source while obtaining authentication information from another source. A third source can also be leveraged for additional information required by Mac OS X.

One comprehensive solution is to configure Mac OS X to use Kerberos for authentication. Kerberos provides secure authentication services using a ticket system, allowing for a seamless end-user experience. Also, Kerberos authentication works cross-platform, meaning that your Mac OS X computers can use existing Active Directory Kerberos services and vice versa, even if those services are served from another platform.

That provides a tremendous level of flexibility and compatibility when configuring various services that come from different servers on different platforms. The open architecture of Kerberos permits all this to take place, regardless of whether your users exist in the Mac OS X Server Lightweight Directory Access Protocol (LDAP) database or the Active Directory domain. This piece of Kerberos, called cross-platform integration, will be explored in more detail in Lesson 9, "Integrating With Kerberos."

Defining Kerberos Terms

There are three main players in a complete Kerberos transaction:

• The user

• The service that the user is interested in accessing

• The key distribution center (KDC), which is responsible for creating and routing secure tickets and generally supplying the authentication mechanism

Within Kerberos there are different realms, specific databases or authentication domains. Each realm contains the authentication information for users and services, called Kerberos principals. For example, if you have a user with a long name of John Significant and a short name of johnsig on a KDC with the realm of PRETENDCO.COM, the user principal would be [e-mail]@PRETENDCO.COM.

For a service to take advantage of Kerberos, it must be kerberized, which means that it can accept tokens from a client. While the service does not talk directly to the KDC, it is an integral part of the Kerberos structure. Not only can Mac OS X Server provide a KDC when configured to host a shared LDAP directory, but it can also provide a kerberized Login Window, HTTP, Mail, File Transfer Protocol (FTP), AFP, virtual private network (VPN), XGrid, Windows (SMB), and Secure Shell Protocol (SSH) services.

When a user account in the LDAP directory is configured to use the Open Directory password type (in Workgroup Manager), the keys pertaining to that user account exist solely on the KDC. Those keys are used to encrypt and decrypt any messages sent over the network. The Kerberos implementation in Mac OS X is based on Kerberos version 5 (Kerberosv5).

Using Kerberos

When a computer running Mac OS X binds to an LDAP directory on Mac OS X Server, it will, by default, also bind to the Mac OS X Server KDC. Then kerberosautoconfig (located in /sbin) uses the values found in the Config attribute in any LDAP directory in the directory search path to create the configuration file, edu.mit.Kerberos, on the Mac OS X computer. However, before a user can start using kerberized services, the account must receive a ticket-granting ticket (TGT) from the KDC.

When using Mac OS X Server as the KDC and using an account in the LDAP directory, the authentication process works as follows:

1. The client requests authentication from KDC:

   a. The user logs in (proposes a user name and password) with a user account on the LDAP directory configured to use a Kerberos password.

   b. Login Window requests and receives the identification information from the LDAP directory.

   c. If the identification includes Kerberosv5 as the AuthenticationAuthority, Mac OS X sends a KRB_AS_REQ message to the KDC. The message consists of the user name (so that the KDC knows which principal is attempting to authenticate), a timestamp, and the requested ticket lifetime.

2. The KDC generates a TGT:

   a. The TGT includes the user name, the name of the KDC, the current time and the time the ticket remains valid, the IP address of the Mac OS X computer, and a random session key generated by the KDC.

   Note

   Most tickets are addressless (to accomodate Network Address Translation, or NAT) and therefore do not contain IPs.

   
   

   b. The KDC issues a KRB_AS_REP, in which the KDC combines the TGT with a copy of the random session key into a message. It then sends this back to the client in clear text because the TGT cannot be decrypted by the client; only the KDC can decrypt the TGT.

   c. Both the TGT and the session key are stored in the client's credentials cache, which is managed by the CCacheServer process. The Mac OS X version of Kerberos has a RAM-based credentials cache, making it more difficult for malicious parties to gain access to sensitive data, and ensuring that, should the machine quit unexpectedly or otherwise lose power, sensitive data will not be on the file system.

   d. The Mac OS X computer generates a user key using the proposed password. Using that generated user key, the requesting application (in this case, the Login Window) unlocks the message and extracts the TGT and session key.

   e. The user key is discarded. The TGT (in conjunction with authenticators generated with the initial session key) is used to authenticate the client to the TGT. A later service ticket and an authenticator generated with a second session key is used to authenticate (but not to identify) the user to kerberized services.

3. The client makes a service request:

   a. When you want to access a kerberized service, in this case the AFP service running on mainserver.pretendco.com, you use the Connect to Server option under the Go menu in the Finder to specify the kerberized AFP server. Then the request is sent to the KDC. The negotiation for the use of Kerberos happens in the AFP protocol. Once the client and Mac OS X Server decide on Kerberos as the authentication method (as opposed to standard authentication), Kerberos on the server informs the client which service principal it should ask the KDC for. This is called KRB_TGS_REQ.

   b. The request message contains the TGT, the name of the service, and the host name of the server (Kerberos host principal).

4. The KDC sends back the TGT, which means:

   P• The KDC extracts and verifies the user based on the authenticator which was produced using the first session key and then sends a service ticket to the user for the requested service.

   • The service ticket contains a version of the user's name that is encrypted with a service key, known only by the KDC and the service.

5. The user sends the service ticket to the service.

6. The service authorizes the request:

   a. The service unlocks the ticket with the service key, extracts the user's name, and determines if the user is authorized to use the service.

   b. If the user account is authorized to use the service, the client is given access to the service.

   c. All sensitive data exchanged between the client and the service is now encrypted is some fashion.

   Note

   Since Mac OS X Server can function as a KDC, it provides SSO authentication: As long as the user has a valid ticket, he or she is never prompted to authenticate when accessing kerberized services. One single password works for all kerberized services, and any user account in the shared LDAP directory that uses an Open Directory password is configured for Kerberos and takes advantage of the SSO feature. It is totally transparent to the user.