Integrating With Third-Party Kerberos Servers

In addition to integrating with Kerberos provided by another Mac OS X Server computer, you can integrate the services running on Mac OS X Server with a Kerberos realm provided by an Active Directory server or an MIT Kerberos server.

Using Third-Party KDCs

Creating service principals and keytabs in a UNIX-hosted KDC is similar to the process on Mac OS X without the Apple configuration mechanisms and infrastructures. The service principals must be created first, and then the process varies with the type of KDC being used.

Keytabsone for each serviceshould be extracted using a tool specific to the KDC. These keytabs would then be moved to Mac OS X Server for processing.

Installing Keytabs on Mac OS X Server

Once the keytabs have been produced, they can be transferred to Mac OS X Server. Use a secure method, such as physically transporting a drive or using an encrypted transport protocol such as Secure Shell Protocol (SSH).

Tip

Keytab files are very sensitive, and in the wrong hands they could allow malicious parties to spoof the identity of your server. Securely copy the keytab files to the server using scp, or physically transfer them with a removable drive. Also delete any extra, unused keytab files so that unauthorized persons can't copy them.

Once the keytabs are on your Mac OS X server, they can be combined using the ktutil command, as demonstrated in the figure above. Optionally, the list command in ktutil may be used before the keytab is written out to verify that the principals were properly saved:

ktutil: list slot    KVNO    Principal ----    ----    ------------------------------------------------   1     1       afpserver/[e-mail]   2     1       ssh/[e-mail]   3     1       host/[e-mail]

The keytab must then be installed on Mac OS X Server at /etc/krb5.keytab and should be tested with the klist -ke command.

Note

If the server will be hosting mail services, the mail group must have read rights on the keytab.

Finally, the service-specific configuration files must be edited to reflect their service principals:

• /Library/Preferences/com.apple.AppleFileServer.plist

  Change the following keys:

  <key>kerberosPrincipal</key>

  <string>afpserver/[e-mail]</string>

• /etc/MailServiceOther.plist

  Add the following keys in the <cyrus> dictionary:

  <key>imap_principal</key>

  <string>imap/[e-mail]</string>

  <key>pop_principal</key>

  <string>pop/[e-mail]</string>

  Add the following keys in the <postfix> dictionary:

  <key>smpt_principal</key>

  <string>smtp/[e-mail]</string>

Kerberos authentication should now be enabled on the server.

Active DirectoryAuthentication and Identification

Like Open Directory, Active Directory provides both a directory of user records and a Kerberos KDC.

You can configure the Active Directory plug-in on a Mac OS X Server computer to allow a user to connect to services while authenticating as an Open Directory user. But what if your clients have already obtained a Kerberos TGT from the Active Directory server? Shouldn't they be able to access your kerberized services on Mac OS X Server using that TGT?

The first step is to join the Mac OS X server to the Active Directory domain. You can choose one of two methods to then have the Mac OS X server act as a member server to the Active Directory KDC:

1.	Click the Join Kerberos button and join the Active Directory KDC. This is similar to having one Mac OS X server become a member server to another Mac OS X server.
2.	Use the command-line tool dsconfigad to join the Active Directory KDC: sudo dsconfigad -enableSSO

At this point, the Mac OS X Server services that are kerberizedsuch as virtual private network (VPN), Apple Filing Protocol (AFP), and File Transfer Protocol (FTP)are kerberized services of the Active Directory KDC. The one caveat is Server Message Block (SMB) sharing.

SMB Authentication With Active Directory

Windows file service (provided by Samba) is a special case of Kerberos integration. The SMB service works only with an Active Directory KDC, and its access method is different from the other Mac OS X Server services.

Mac OS X Server includes Samba 3, which acts as an Active Directory member server for Kerberos authentication. The shared secret is not stored in a keytab as it is with the other services on Mac OS X Server. Samba maintains the shared secret, and it's created when Mac OS X Server joins the Active Directory domain.

Although it's not enabled out-of-box, this feature brings tremendous value to Mac OS X Server. It provides an end-user experience and a level of authentication security that are equivalent to that of a Windows server.

Note

Mac OS X Server version 10.3 and later supports the NTLMv2 authentication method. Prior to Mac OS X v10.4, Mac OS X did not support NTLMv2, only NTLMv1, which is not as secure as NTLMv2. If your users are running Mac OS X v10.3 or earlier, they cannot use NTLMv2. If you connect Mac OS X Server v10.4 or later to a directory domain of Mac OS X Server v10.3 or earlier, users defined in the older directory domain cannot be authenticated with NTLMv2.

Apple has simplified the process of joining an Active Directory domain. When you join an Active Directory domain and kerberize the SMB service, the following additions and modifications are made to Samba's configuration file, /etc/smb.conf:

• spnego = yes

• realm = MYADDOMAIN.PRETENDCO.COM

• security = ads

• workgroup = MYADDOMAIN

The spnego entry already exists but is set to no; it's changed to yes. The realm property should be set to the name of the Kerberos realm your Active Directory server supports. Generally, this will be the capitalized DNS name of the Active Directory server. The security option is an internal Samba flag, alerting smbd that it should use Active Directory authentication (the ads flag). Finally, the workgroup should be set to the name of the NT domain emulated by Active Directory (although this is configurable in the graphical interface).

Modifying smb.conf was difficult in the previous version of Mac OS X Server, since sambadmind rewrote the configuration file every time it was restarted, and manual changes to the file were not preserved. In Mac OS X Server v10.4, the file is still rewritten every time Samba restarts, but manual changes are preserved.

Using Multiple Directories

Integration with Active Directory lets you take advantage of cross-platform directory standards. Because both Mac OS X Server and Active Directory support Kerberos and LDAP, a deep level of integration can be achieved with relatively little effort.

Unfortunately, the same cannot be said for many of the applications that rely on those directories. For instance, it would be unreasonable to expect Microsoft Exchange to work with Open Directory. Likewise, client management and group policy are features that tend to be proprietary and vendor-specific. The managed client data used by Mac OS X is not currently read or understood by other platforms. Similarly, Mac OS X servers are not going to enforce the policies defined by a Windows Group Policy object.

Because the format of the data is not standardized, Workgroup Manager is the only application capable of writing and maintaining it.

A common solution to this challenge is the deployment of a supplementary directoryone specifically for Mac OS X data, in addition to the Active Directory. User principals still reside in Active Directory, but management of Mac-specific data is delegated to the administrators of the Mac-specific domain. Mac OS X computers are then configured to access both domains and receive a combination of the data from both directories.

Here are two common scenarios describing how you can use both Open Directory and Active Directory to help manage your Mac OS X computers:

• User sadams logs in to workstation.pretendco.com. As a user account from Active Directory, sadams does not belong to any workgroups with managed preferences. However, the computer, named mac005, belongs to a group of computers (NY-office) defined in Open Directory. A set of preferences will be enforced for any user logging in to that group of computers, regardless of where the user record is stored: locally, in Active Directory, or in Open Directory. Mac-specific security policy is applied to Active Directory users without administrative impact on the enterprise directory.

• User jdoe logs in to workstation.pretendco.com. User jdoe exists only in Active Directory. However, mcx.loginplugin searches the authentication path of the computer named mac006 and determines that jdoe belongs to a workgroup with managed preferences. Because jdoe is logging in to a managed client (mac006 also belongs to the NY-office group), he will receive an aggregate of per-host and perworkgroup preferences.

Cross-Realm Authentication

A final Kerberos integration option involves a different kind of trust. Whereas in the last case of multiple directory integration, Mac OS X Server essentially trusted Active Directory, in this case Active Directory trusts Mac OS X Server. Cross-realm authentication is a standard built into the Kerberos v5 protocol, and it is widely deployed in organizations that had a well-developed pre-existing Kerberos infrastructure before their Active Directory rollout. Although user accounts still have to exist in both domains, a single authentication authority can be maintained.

Once again, because cross-realm authentication is a feature of Kerberos, it can also be established with MIT (and Heimdal) KDCs. Active Directory is covered in depth, due to its ubiquitous nature and high impact on Mac OS X integration, but an MIT example is also included.

In cross-realm authentication, a TGT from the trusted domain is accepted in a second domain, and a shared secret is established so that data sent between the domains in question is secure.

Setting up a trust with another MIT Kerberos realm is similar to integration with Active Directory. A cross-realm secret is established along with appropriate cross-realm tickets, but there are three primary differences:

• kadmin is used on both domain controllers, rather than just on the Open Directory master.

• More secure encryption types can be used.

• Service integration is site-specific. Active Directory offers a predictable model for integrating user and service principals with its KDC, as does Open Directory. This level of integration is not defined in the Kerberos standard, though, and the KDC you're establishing the trust with might follow a different model.

To create the cross-realm trust, use kadmin to add TGT principals to both KDCs.

kadmin.local -q "add_principal -pw password krbtgt/ENGINEERING.PRETENDCO. [e-mail]"

Use the same password on both KDCs when adding the principal.

kadmin.local -q "add_principal -pw password krbtgt/MARKETING.PRETENDCO. [e-mail]"

Again, use the same password on both KDCs when adding the principal.

Setting up cross-realm authentication with an Active Directory server involves using the Windows Active Directory Domain and Trusts utility and the New Trust Wizard. For details on establishing the trust, see "To create an external trust" in Windows Server Help.

The other half of the trust is established in the Open Directory domain using the kadmin utility:

kadmin.local -q "add_principal -e des-cbc-crc:normal -pw pass krbtgt/MAINADSERVER. [e-mail]" kadmin.local -q "add_principal -e des-cbc-crc:normal -pw pass krbtgt/MAINSERVER.PRETENDCO. [e-mail]"

Note that the -pw flag should be used to specify the same password used in Active Directory Domains and Trusts. If a more secure transaction is needed, don't specify the -pw flag; kadmin.local will prompt you for it.

Next, mappings must be added to Active Directory users so that Open Directory principals can be used to authenticate them, and Windows clients must be set up to access the Open Directory KDC.

Enabling Active Directory Users for Cross-Realm Authentication

Every Active Directory user who is going to be authenticated through Open Directory needs to have a particular attribute added through his or her user record. Graphically, this can be accomplished using the Active Directory Users and Groups MMC Snap-in by enabling its Advanced Features option. After advanced features are enabled, you can right-click the user in question and choose Name Mappings. In the resulting window, shown in the following figure, choose Kerberos Mappings and add the user's Open Directory Kerberos principal (the user's short name, followed by the @ symbol and the name of the Open Directory Kerberos realm; for instance, dave@MAINSERVER. PRETENDCO.COM).

However, in all but the smallest domains this will be scripted as part of the user creation process, so add the user's Open Directory Kerberos principal to the right attribute in their Active Directory user record. Having a standardized convention for the generation of user names lets you make assumptions when scripting, rather than querying a database or some other data source to determine the user's Open Directory user name.

Finally, Windows client computers must be alerted to the presence of the Open Directory KDC using ktpass, just as it was used on the domain controller. The Windows client must then be rebooted, and users should be able to choose the Open Directory KDC from the list of domains at the Windows login screen. On login, users will get an Open Directory TGT. To complete login, an Active Directory TGT will probably be needed (to access Active Directory resources such as home folder shares). Open Directory will grant a cross-realm TGT that will be respected by Active Directory due to the trust in place between the realms, and you've got true cross-realm integration.

Kerberos Security

Although Kerberos provides a reasonably secure authentication infrastructure, it's not perfect, and it's possible for a sufficiently sophisticated and motivated attacker to breach Kerberos security by attacking some of the weaker links in the Kerberos protocol. Luckily, most of these attacks are well understood, and much can be done to decrease the likelihood of their success.

The following table lists the various concerns when using Kerberos:

Concerns	Precautions
Keys are recoverable	Physically secure KDC Minimize services on KDC
Offline dictionary attack	Pre-authentication Password restrictions Network security
Man-in-the-middle attack	Mutual authentication
Replay	Address in ticket Finite authenticator lifetime Replay cache

Perhaps the most important security issue relating to Kerberos administration is that user keys are easily recovered, given root access to the KDC. For this reason, Open Directory master computers should run no other services if possible, and should be physically secured behind a locked door, through which access is thoroughly monitored. Note that even if the keys are recovered, an attacker could not extract the original passwords. The keys are created from the users' passwords via a hash. Still, uncontrolled access to the keys is a serious security breach that would compromise the security of the server.

A second concern is a dictionary attack. Specifically, certain Kerberos transactions encrypted with the user's secret are known to contain structured data. By sniffing an encrypted transaction off the network and applying a list of passwords against the encrypted data, the structured data may be decrypted. A number of measures can be used to foil dictionary attacks.

Tip

The risk of a successful dictionary attack can be greatly reduced by using sufficiently complex or non-English passwords. Policies can be put in place to help users choose safe passwords.

In Kerberos's default configuration, it is trivial to get Kerberos to send encrypted data across the network. To prevent such easy access to encrypted data, pre-authentication can be enabled. Pre-authentication forces the client to prove their identity before the KDC will send encrypted data and must be enabled on a per-principal basis. To enable pre-authentication for a principal, use the following command:

sudo kadmin.local -q "modify_principal +requires_preauth principalname"

And finally, malicious sniffing can be deterred though the use of Network Intrusion Detection Systems (NIDSs).

In a man-in-the-middle attack, a malicious party attempts to impersonate a kerberized service. Kerberos v5 minimizes the feasibility of this by using mutual authentication, which allows client-side software to require that the service prove it is legitimate by successfully using the shared session key.

Replay attacks harvest the authentication data that client software sends to a kerberized service. Although this data is encrypted, it can be reused later to gain access to the service. Several factors combine to make this sort of attack much more difficult.

One way Kerberos works to prevent replay attacks is by embedding the IP address of the client in the ticket, helping ensure that the ticket may be used only by a legitimate host. However, this is not entirely secure because IPs can be spoofed. Additionally, Network Address Translation NAT requires tickets that have no real address, since a nonroutable IP address generally has little meaning to the KDC.

Another way to prevent replay attacks is to add a timestamp to encrypted data. If the server's system clock differs by more than 5 minutes from the timestamp sent by the client, the user is not authenticated. Legitimate authentication data will probably be used shortly after it's obtained from the KDC.

Finally, the kerberized service caches the authentication data, disallowing the connection if it has seen the same data before. Ideally this would mean that a replay attack could not occur, because for a malicious party to harvest it, it would have to be sent to the server. It is feasible, though, that given a compromise of the network, the server could be subject to a Denial of Service (DoS) attackmeaning that the server would never receive the authentication data until the malicious party sent it.

Note

This requires some very specific circumstances and is feasible only because of inadequacies in IPv4. (It relies on ARP spoofing.) If anything, it should indicate that no single tool is sufficient to secure a network. In this case, measures should have been taken to prevent ARP spoofing.