Configuring Kerberos on Mac OS X

To use Kerberos, a Mac OS X computer must be configured with the appropriate information about the Kerberos realm, the KDC, and the type of encryption being used.

Understanding Configuration Files

A kerberized principal needs to know the location of the KDC, the type of encryption to use, and the name of the Kerberos realm. In Mac OS X, this information is stored in a plaintext file called edu.mit.Kerberos. If your Mac OS X computer receives Kerberos information from a Dynamic Host Configuration Protocol (DHCP) or domain name system (DNS) server; or, if you had Kerberos already running on a previous version of Mac OS X, this file is created automatically.

The edu.mit.Kerberos file contains a libdefaults section and sections for realms and domain_realms. For compatibility, it also allows for Kerberosv4 realm settings. This file can be created using any text editor, as long as it is saved as plaintext.

The contents of the edu.mit.Kerberos file for the realm pretendco.com would be the following:

[domain_realm]      .pretendco.com = MAINSERVER.PRETENDCO.COM       pretendco.com = MAINSERVER.PRETENDCO.COM [libdefaults]       default_realm = MAINSERVER.PRETENDCO.COM       dns_fallback = yes [realms]       MAINSERVER.PRETENDCO.COM = {             admin_server = mainserver.pretendco.com:749             kdc = mainserver.pretendco.com:88      } [v4 domain_realm]      .pretendco.com = MAINSERVER.PRETENDCO.COM       pretendco.com = MAINSERVER.PRETENDCO.COM

The libdefaults section describes the default behavior of the Kerberos libraries. The default_realm entry should be automatically entered correctly, so you do not need to edit it. The ticket_lifetime entry is not supported in this file. The value is set by the Kerberos application.

The realms and domain_realms sections refer to Kerberosv5 realms. These sections define the KDC and the admin server, as well as how the names are resolved. If your site includes Kerberosv4 realms, you must include the v4 realms and v4 domain_realms sections. Under these sections, you will define the Kerberos v4 KDCs, admin servers, and default domains. The domain_realm actually maps DNS domains to Kerberos realms, which is useful in authenticating using the host/principal (such as SSH).

A copy of the one edu.mit.Kerberos file is typically located in /Library/Preferences, and all users on the system use this file. However, user-specific realm and server information can also be stored in an edu.mit.Kerberos file stored at ~/Library/Preferences. If you are manually configuring an edu.mit.Kerberos file for a specific user account, avoid duplicate realm entries with the system edu.mit.Kerberos. The system edu.mit.Kerberos file can be edited with the Kerberos application (discussed in the next section).

Once the edu.mit.Kerberos file is created, it should be placed in /Library/Preferences (for system-wide settings) or in ~/Library/Preferences (for user-specific settings).

More Info

For more information on configuring the Kerberos client manually, see the "References" section, at the end of this lesson.

In Mac OS X, the Kerberos login library preference and Kerberos management application preferences are stored in separate files: edu.mit.Kerberos.KerberosLogin.plist and edu.mit. KerberosApp.plist. The settings in these files are configured using the Kerberos application (located in /System/Library/CoreServices), and editing realms using the Kerberos application will write to both its preferences file and the edu.mit.Kerberos file. Mac OS X also provides UNIX compatibility allowing a krb5.conf file (which is formatted exactly like the edu.mit.Kerberos file) to reside in /etc, letting you use a standard Kerberos configuration file that comes from a UNIX workstation.

Configuration files for Kerberos are searched in the following order:

• /Library/Preferences/edu.mit.Kerberos

• ~/Library/Preferences/edut.mit.Kerberos

• /etc/krb5.conf

The realm values from these three files are merged and the libdefault values follow precedence (the first entry read is the first used). Mac OS X does not support a user configuration for Kerberos without a system configuration.

Using Kerberos Tools

Mac OS X has several tools to manage the Kerberos tickets. The command-line tool klist lists any credentials (tickets) stored locally in the cache. The -e option describes the encryption method used for each key, useful in determining whether the client has received tickets. When viewing the list of tickets, the krbtgt is the ticket-granting ticket.

But if you want to obtain a ticket from the command line, use kinit to request a ticket from a KDC. If you type kinit sharon, Mac OS X will request a ticket-granting ticket from the KDC for user account sharon. By using the -S option, kinit can be used to request a ticket for a particular service.

Finally, use the kdestroy command to remove tickets from the cache. If you run the command with no options, it will remove all tickets in the cache. Alternately, use the -p option to selectively remove tickets based on the principal name.

More Info

For more information on the command-line Kerberos utilities, refer to the man pages for each utility.

Mac OS X also includes the Kerberos application that performs many of the same tasks as these command-line utilities. Located in the /System/Library/CoreServices folder, this application can be used to add, delete, and edit realms with the Edit Realms option under the Edit menu.

Receiving Kerberos Authentication

While you can get TGTs, obtain service tickets, and participate in SSO, you still need to know how your users can leverage the fact that a KDC can be used for that authentication. The authentication method for Kerberos is stored in the user's entry in the LDAP directory. If you use dscl to list the user accounts in the LDAP directory, you will see that user accounts with an Open Directory password (as configured in Workgroup Manager) have two authentication authority attributes. The value for a Kerberos authentication method will contain "Kerberosv5," a GUID, the principal name, the realm name, and a public key, as shown in the following figure.

When the KDC attempts to identify the user principal, it will look for a principal entry first (username@KDChostname). If it cannot identify the principal based on that entry, or if the entry is not present, it will use the globally unique ID (GUID) and the realm name. If that does not work, it will find the short name to use. The public key is the same as that for ApplePasswordServer, but is not used for Kerberos. For example, this would be the Kerberos Authentication Authority for sharon:

;Kerberosv5;0x3fdf6eae0c3096df0000000600000009;[e-mail]; MAINSERVER.PRETENDCO.COM;1024 35 11455787430834638358938996965241681017907079523 3023475948111304185096244575079064662043645069949051174748674690618626171556163371 6820513942592510402577124571207210754982210574570023051069011871542324730683479466 3830159086521568311947446273412496047754300427804383197071699373369259416693103774 9492941908043763 [e-mail]

The ApplePasswordServer values reference the Simple Authentication and Security Layer (SASL) authentication method built in to Mac OS X Server. Password Server is covered in more detail in Lesson 8, "Providing Single Sign-on Authentication."