Accessing Kerberized Services | Apple Training Series: Mac OS X System Administration Reference, Volume 1

To access a kerberized service running on a separate server, a client must first have a ticket-granting ticket (TGT) from the key distribution center (KDC), and the kerberized service running on the other server must be configured to accept service tickets from the KDC. The figure below shows the process of requesting a ticket, obtaining a TGT, and obtaining a ticket for a kerberized service on a separate server.

To access the service, the client uses the TGT to acquire a service ticket from the KDC in the following sequence:

The client sends the KDC a request, KRB_TGS_REQ. This request includes:
• The TGT in clear text
• The principal name of the service being requested (for example, afpserver/mainserver.pretendco.com@SECONDARYSERVER.PRETENDCO.COM)

Sent next is an authenticator, consisting of a timestamp encrypted with the secret session key the client originally obtained with the TGT in KRB_AS_REP.

The KDC decrypts the TGT and the authenticator (proving the client's identity) and prepares KRB_TGS_REP. This consists of:
• A new session key, for use between the client and the kerberized service, encrypted with the old session key to protect it as it is sent to the client
• A service ticket, otherwise unreadable to the client, containing the name of the client and a copy of the session key

The session key and service ticket are encrypted with a secret password known only by the KDC and the kerberized service. The client sends the service ticket to the kerberized service, with an authenticator (now with a timestamp encrypted with the new session key). Because the service ticket is encrypted with the service's secret, the session key can be extracted from it only by a legitimate service. The service decrypts the service ticket and extracts the new session key to decrypt the client's authenticator. If the authenticator is decrypted successfully, the client is authenticated. This portion of the Kerberos exchange is called KRB_AP_REQ.

For successful Kerberos integration, make sure that:

The KDC is configured with the proper service principal and key to issue a service ticket in step 2.
The service has a copy of those principals and keys so it can validate that the service ticket came from the KDC.

Authentication Scenarios

When configuring multiple services to participate in a Kerberos realm, there are four basic scenarios, as shown in the following figure:

Multiple Mac OS X Server computers: One Open Directory master provides the KDC. Additional servers are connected to a directory system and accept service tickets from the Open Directory master.
KDC provided by a third-party server: This is typically an Active Directory KDC.
Multiple KDCs (cross-realm authentication): Tickets issued by one KDC will be respected by a second KDC.
KDC provided by Mac OS X Server supporting a third-party server.

Identification Scenarios

Two related but independent processes are involved in securely accessing resources on a server:

The user must be identified: The service must know who is attempting to access the resource.
The user must be authenticated: The service must be sure that the user is who he or she claims to be.

When the user has been identified and authenticated, the service can determine which resources the user has access to (authorization).

Kerberos provides only authentication; identifying the user is handled by separate processes and protocols. Because they are independent processes, identification and authentication can be implemented in a variety of ways, which makes for flexibility but also complexity.

The simplest scenario is for the authentication and identification to be integrated (as they are with Open Directory). A user named Tom is trying to log in. First, loginwindow attempts to locate Tom's user account. Tom has an Open Directory account that includes an AuthenticationAuthority attribute. Because Tom is on Mac OS X, his computer can interpret this attribute. The rules in /etc/authorization say that if the authentication process as defined in the AuthenticationAuthority succeeds, then Tom should be authorized to log in.

Because Tom's user account is in the local NetInfo database, he does not have an Authentication-Authority attribute spelled in the same fashion as the Lightweight Directory Access Protocol (LDAP) server's AuthenticationAuthority attribute or password data. (Refer to the table below for the attribute name listings.) His system is configured to authenticate with a KDC. The name in the directory, tom, matches the name of the Kerberos principal, tom@PRETENDCO.COM. The following table lists the various attribute names for authentication:

Database Type	Usage	Password Type
NetInfo	authentication_authority	Shadow hash
Open Directory	AuthenticationAuthority	Password Server Kerberos
OpenLDAP	authAuthority	Password Server Kerberos

Lisa's account is in a third-party LDAP directory and therefore does not have an AuthenticationAuthority attribute. The KDC and the LDAP directory containing Lisa's account do not have to be related. If Mac OS X is configured for Kerberos authentication, any user who can be identified from the LDAP directory can be authenticated with a separate KDC and can log in.

If there's a local user called lisa, she can log in with a Kerberos password specified in Active Directory. If there's an Open Directory user called lisa, she also will be able to log in with the Kerberos password specified in Active Directory. This leads to the feasibility of a loosely coupled integration strategy. Users stored in a Mac OS X directoryeither locally or in a shared domaincan make use of the passwords stored in a Kerberos KDC, as long as their user names match.

Generally this implies some sort of synchronization process, or perhaps multiple synchronized directories relying on a single KDC.

Joining Multiple Mac OS X Servers

Single sign-on is a powerful feature of Mac OS X Server. It's enabled immediately for most of the services hosted on the Open Directory master when Kerberos is enabled. If you're hosting only one server, SSO requires no configuration beyond creating an Open Directory master.

However, it's more common for services to reside on a number of servers, thus spreading the load. SSO enables users to access all of these services with one user name and password. If all your servers use Mac OS X Server, Open Directory makes configuring this relatively simple.

Note

Servers that are configured to use Kerberos provided by another server are members of the Kerberos realm, or member servers.

To participate in SSO by supporting Kerberos, member servers must first be authorized to access the KDC, and the services' secret keys (the shared secrets known only by the KDC and the services) must be established. Generally this involves obtaining a keytab file from the KDC, installing the keytab on the member server, and editing the Kerberos configuration file, edu.mit.Kerberos.

The following table lists the various services that can be kerberized:

LDAP	SSH	VPN
AFP	FTP	SMB
IMAP	POP	SMTP
HTTP	Xgrid	XMPP (Jabber)

Kerberos Configuration in Open Directory

Mac OS X Server includes utilities that streamline the process of joining multiple computers to a single Kerberos realm. To participate in a Kerberos realm, each member server must share a set of secret keys with the KDC. Joining a realm securely transfers the secret keys to the member server. In Mac OS X, as in any MIT Kerberosbased distribution, the secrets are stored in a keytab file: /etc/krb5.keytab. You can use the klist -ke command to view them.

Tip

klist -ke can be useful for troubleshooting purposes. Sometimes authentication fails because the wrong keys get installed.

To transfer these keys, a number of processes need to occur:

An administrator on the Open Directory master must create a computer account for the member server. This is initially a standard computer account created using Workgroup Manager.

Server Admin modifies the account to contain additional Kerberos attributes containing the encrypted data (such as the keytab file) that the member server needs to join the directory domain hosted on the Open Directory master.

An administrator on the member server must use Server Admin to join the Kerberos realm established on the Open Directory master. The Kerberos data there is then decrypted and used for the local configuration files.

When the member server joins the Kerberos realm, it creates the local files necessary for the Kerberos configuration.

Creating a Kerberos Record on the Master

The first step to adding a kerberized server is to create a computer account for the member server by creating a computer record on the Open Directory master. When the computer account is created with Workgroup Manager, a basic computer record is stored in the shared domain.

Example commands:

sso_util info -r/LDAPv3/127.0.0.1 -p sso_util generateconfig -r SECONDARYSERVER.PRETENDCO.COM -R secondaryserver.pretendco. com -f/LDAPv3/127.0.0.1 -U -a diradmin -p

The next step is to create the Kerberos record on the Open Directory master with Server Admin. Click the Add Kerberos Record button in Server Admin's Open Directory Settings pane and the dialog below will appear.

Authority to join the Kerberos realm must be delegated to a specific user, even if that user is already a domain administrator. This user name and password allow the member server to join the Kerberos realm. When you click Add to add the Kerberos records and then Save in Server Admin, the sso_util command performs the following actions:

The default Kerberos realm is obtained using the sso_util info command.
The service principals and keys are securely stored in the computer record using the sso_util generateconfig command.

Note

Server Admin does not indicate which computer accounts have Kerberos information added, and there is no easy way to delete the Kerberos information without manipulating the raw directory data (as with the inspector in Workgroup Manager). Be careful when entering information, and double-check your entry before you click Save.

Joining an Open Directory KDC

After you create the required Kerberos record on the Open Directory master, you can configure the member server to join the directory domain. To configure the member server as an Open Directory client to another server, click the Open Directory settings tab and choose Connected to a Directory System. Then configure Directory Access to search the LDAP server on the Open Directory master.

The member server queries the Open Directory master for directory information, including the Kerberos records you created previously. The process of binding the Mac OS X server (the member server) to the Open Directory master is similar to that of binding a Mac OS X computer to an Open Directory master, covered in Lesson 3, "Accessing Mac OS X Server Directory Services."

The Open Directory master stores the Kerberos information in the computer record for the member server. Click the Join Kerberos button in Server Admin on the member server (see the preceding figure) and provide the user name and password of a delegated administrator. These credentials are used to authenticate to the directory and build a valid keytab file from the data that is stored in the server's computer record.

The resulting keytab contains the shared secret used to secure communication between the Open Directory master KDC and the member server. Once this secret is established, SSO is enabled.

When you save changes to the settings on the member server, sso_util useconfig produces a proper /etc/krb5.keytab, and it modifies both /Library/Preferences.com.apple. AppleFileServer and /etc/MailServiceOther.plist to reflect the service principals contained there.

This process occurs in the GUI and is very streamlined, giving the administrator freedom from manually managing the configuration filesa tremendous asset when using Mac OS X Server.