Welcome back! Last month we blasted through getting your single sign-on and corporate directory infrastructure up and running. In this article, we configure some Linux clients and Mac OS X clients to make full use of last month's hard work. We don't have as many pieces to investigate this time, but we still have a lot to cover, so let's get to it! Again, all the configuration files are available from the on-line Resources.

In this article, we explore how to connect Gentoo Linux and Red Hat Enterprise Linux (RHEL) v3 and v4, but most Linux clients should be about the same to configure, with minor differences. We also cover Mac OS X v10.4 (aka Tiger) client integration. In a later article, we'll explain how to configure Microsoft Windows clients to use the authentication and authorization system, since it depends on configuring and setting up the Samba package.

For single sign-on, Linux and Tiger clients need a Kerberos host keytab. We create one the same way we created other keytabs. For both Linux and Tiger clients, this keytab is kept in /etc/krb5.keytab.

Not all users, especially remote laptop users, will want or be able to have their machine incorporated fully into the Kerberos realm. Unless you have complete control of all the machines from which users will connect, you need to allow traditional password authentication. While this defeats some of the security of using Kerberos by having to transmit passwords over the Net, as long as you are aware of this as a sysadmin and take precautions to limit its use, you're no worse off than if you had not chosen to use Kerberos. Kerberos still has a few advantages over mechanisms such as /etc/passwd, NIS or LDAP storage of passwords. It's much simpler to enforce password rules with Kerberos than with the other mechanisms, and the storage of the passwords is more secure in a Kerberos database. Make sure to review “Centralized Authentication with Kerberos 5, Part I” by Alf Wachsmann (see Resources) on enabling Kerberos PAM authentication.

In “OpenLDAP Everywhere” by Craig Swanson and Matt Lung (see Resources), the authors touched on /etc/nsswitch.conf /etc/ldap.conf and /etc/openldap/ldap.conf. We're going to tweak these files to refine them for speed and security. First, let's look at /etc/openldap/ldap.conf. This file defines defaults for the OpenLDAP command-line tools, such as ldapadd and ldapsearch. Our /etc/openldap/ldap.conf file looks like Listing 1.

BASE "o=ci,dc=example,dc=com"
URI ldaps://ldap.example.com ldaps://kdc.example.com
TLS_CACERTDIR /etc/ssl/certs
TLS_REQCERT allow

For more options and more information, refer to ldap.conf(5). Because there's no way to specify that we want to use StartTLS in /etc/openldap/ldap.conf, we must explicitly use an ldaps:// URL. Now we can simply issue ldapsearch, which uses SASL authentication by default and then refers to /etc/openldap/ldap.conf for the default host and base.

Let's now work on getting name service switch (NSS) working properly. Make sure the nss_ldap package is installed. Also, be aware that older versions of this package didn't handle LDAP storage of some services such as netgroups, so try to get the latest version you can. First configure the nss_ldap package itself by editing /etc/ldap.conf. This file differs from /etc/openldap/ldap.conf, which is only for the OpenLDAP tools, whereas /etc/ldap.conf is the configuration file for nss_ldap. Listing 2 shows what /etc/ldap.conf should look like.

host ldap.example.com kdc.example.com
base o=ci,dc=example,dc=com

ssl start_tls
tls_checkpeer no
tls_cacertfile /etc/ssl/certs/ci-cert.pem

nss_base_passwd ou=people,o=ci,dc=example,dc=com
nss_base_group ou=group,o=ci,dc=example,dc=com
nss_base_hosts ou=hosts,o=ci,dc=example,dc=com
nss_base_services ou=services,o=ci,dc=example,dc=com
nss_base_netgroup ou=netgroups,o=ci,dc=example,dc=com

Let's look at what these different lines do, as there is no man page for this file. The first two lines define the LDAP servers to contact and the base from which to search. The next three lines explain how to initiate the TLS connection. As you can see, nss_ldap is aware of StartTLS, so we use that method to initiate a TLS connection. The last lines describe the bases to search from for various nsswitch controlled attributes. We set these for performance reasons. There's no need to have to search the whole directory for a given user name if all of our user names are under one branch of the tree. For example, nss_base_passwd specifies the base for searches traditionally associated with information in /etc/passwd. If, however, you do store user names in multiple branches of the directory, you can't use this option. A slew of other options can be defined in this file. To explore these options, check with the example ldap.conf that comes with the nss_ldap package.

Make sure you have the CA certificate in /etc/ssl/certs, and run c_rehash. This process needs to be done for any machine that will be contacting the LDAP server for any information over an SSL connection.

Next, edit /etc/nsswitch.conf to specify looking in LDAP for information. Don't put ldap as the first entry for hosts; if you do, you won't be able to resolve the LDAP server's hostname. If you had added a user locally to /etc/passwd or /etc/shadow that you wanted to be served out of LDAP, remove it or comment it out. Now you can test that it's working:

# getent passwd leggett
leggett:x:1001:100:Ti Leggett:/home/leggett:/bin/bash

# id leggett
uid=1001(leggett) gid=100(users)

If both of these commands work, you're ready to go. Some programs require a restart in order to recognize changes to /etc/nsswitch.conf. OpenSSH is one of these, so restart sshd and then attempt to slogin.

Everything we've done so far has led us to enabling Gentoo and RHEL clients, but let's review what needs to be in place.

The following files are needed for Kerberos authorization:

And the following files define OpenLDAP account management:

There's one caveat for RHEL 4 at the time of this writing. A bug occurs when you use hostnames in /etc/ldap.conf instead of IPs, so have LDAP as a lookup for the hosts database in /etc/nsswitch.conf and use DHCP to get client IPs. If you notice that bringing up your network devices causes a segfault in dhclient, change hostnames to IPs in /etc/ldap.conf.

Configuring sshd for single sign-on under Gentoo and RHEL v4 is a snap. You need to make sure the following options are set in /etc/ssh/sshd_config:

GSSAPIAuthentication yes
GSSAPICleanupCredentials yes
UsePAM yes

Once you've set these, make sure to restart sshd.

Unfortunately, RHEL v3's sshd supports an older GSSAPI mechanism called gssapi, which is susceptible to a man-in-the-middle attack. It's been replaced by the gssapi-with-mic mechanism, which is what both RHEL v4 and Gentoo use. If you're unsure which mechanism your sshd supports, simply enable GSSAPI authentication in the sshd_config file and then attempt to ssh in using the verbose flag. You'll get a report of all the mechanisms that sshd supports. If you attempt to ssh from a client that uses one mechanism to a server that uses the other, you'll be prompted for your password. This is because the credential passing is done slightly differently, and incompatibly, with each mechanism.

Our ultimate goal is for users to have to type their password only once per day and never have that password go across the wire. So why go through all this trouble if your users are sending their password over the wire every time they check e-mail? Fortunately, more e-mail clients are starting to support the GSSAPI mechanism. Unfortunately, if you're a Mozilla Thunderbird user, you're out of luck (as of this writing). A few other options exist, however; for example, both KDE's KMail v1.8 and Ximian Evolution v2.2 have GSSAPI support. I've never used KMail, so I'll stick to what I know. Configuring Evolution to use GSSAPI is simple. Just select GSSAPI as the authentication type under both the Receiving and Sending Email tabs (Figure 1). If you set the Use Secure Connection option to Whenever Possible, Evolution uses StartTLS to secure the data transport.

Figure 1. Evolution 2.2 Account Preferences

Starting with Tiger, Apple has Kerberized almost all portions of the operating system. If you need to incorporate Panther (v10.3) clients into your infrastructure, contact me for information; a good deal is required. Tiger, however, is relatively easy.

Start by editing the file /Library/Preferences/edu.mit.Kerberos. This file is quite similar to its Linux counterpart, /etc/krb5.conf, with some very minor changes. Ours looks like Listing 3.

[libdefaults]
 ticket_lifetime = 600
 default_realm = CI.EXAMPLE.COM
 default_tkt_enctypes = des3-hmac-sha1 des-cbc-crc
 default_tgs_enctypes = des3-hmac-sha1 des-cbc-crc
 dnsfallback = no

[realms]
 CI.EXAMPLE.COM = {
  kdc = kdc.example.com:88
  kdc = ldap.example.com:88
  admin_server = kdc.example.com:749
 }

[domain_realm]
 .example.com = CI.EXAMPLE.COM
 example.com = CI.EXAMPLE.COM

With Kerberos configured, the next step is to create a keytab for the host and place it in /etc/krb5.keytab. You can run kadmin from the OS X client, but because the version that comes with v10.4 is slightly buggy, you need to append the -O option:

#/usr/sbin/kadmin -p <admin princ> -O

That's it for Kerberos authentication with Tiger.

Unfortunately, at the time of this writing, a bug causes the machine's authentication subsystem to hang when a network user attempts to use sudo while having valid Kerberos credentials. I'm working with Apple to resolve this issue, so check back with me to find the solution.

Mac OS X does not use nsswitch for resolution of name services. Instead, it uses what it calls Directory Services. I explain how to modify Directory Services via a GUI called Directory Access, but ultimately the GUI makes modifications to two files: /Library/Preferences/DirectoryService/DSLDAPv3PlugInConfig.plist and /Library/Preferences/DirectoryService/SearchNodeConfig.plist.

The GUI utility can be found in /Applications/Utilities. First, enable the LDAPv3 plugin, then select it and click the Configure button. Once inside, click the Show Options drop-down, and then click New to define a new LDAP server. Enter your LDAP server's name, make sure all three check boxes are checked (Figure 2), and click Continue. Next, choose RFC 2307 (Unix) as the template, enter your LDAP base, click Continue and define a Configuration Name. That's it!

You can refine how Directory Services searches the directory, much as you can with /etc/ldap.conf under Linux. If you highlight the directory service and click Edit, it brings up some more advanced options. Click on the Search & Mappings tab. There you'll see a list labeled Record Types and Attributes. For each of those you can select and then define a more specific Search base (Figure 3). Click Ok twice, and then Apply to save your changes.

Figure 2. Creating a New OS X LDAP Directory Connection

Figure 3. Refining OS X LDAP Searches

Of course, you'll want to verify that your directory changes are correct and working. OS X has a command-line utility, dscl, that is used to query not only an LDAP directory but also a NetInfo directory, NIS directory or any other directory listed in Directory Access. First, we should make sure we can query our LDAP server directly:

# dscl localhost list \
 /LDAPv3/ldap.example.com/Users

If you run dscl without any options, you are given usage instructions and left at an interactive prompt. Here are two more examples of using dscl:

# dscl localhost list /Search/Users
# dscl localhost read /Search/Users/leggett

Here we use the /Search directory, which acts on all enabled directories. So, if you have local users in a NetInfo directory and also LDAP users, the /Search acts on both of those directories, merging the results for display. The second example uses the read action to show the detailed information of the leaf of the branch specified, /Search/Users/leggett in this case. The dscl utility can be helpful when all you have is console access to your OS X machine.

Having verified that our LDAP users are available, we need to create local home directories for the LDAP users we've just enabled:

# install -d -o leggett /Users/leggett
# ln -sf /Users /home

OS X v10.4 has some finer-grained policies than standard POSIX access for controlling access to certain aspects of the OS. By default, members of the group admin have administrator privileges. However, this group is locally stored in each machine's NetInfo directory, and I've been told it's very bad to remove or rename this group. You also can't override this group with an LDAP group named admin, because the search order for directories always searches the local NetInfo directory first. To use an LDAP group to replace the local group role, you need to edit the file /etc/authorization. This is a standard Apple plist-formatted file, and it defines roles for different aspects of the system. If you change lines that look like:

<key>group</key>
<string>admin</string>

to:

<key>group</key>
<string>ldap-admins</string>

for the different rights, you'll enable those users in the ldap-admins group to be administrators on that machine. These rights are different from sudo privileges, which are defined in /etc/sudoers. These rights control rights to tasks such as installing software and modifying system preferences.

At this point we should be able to log in as user leggett. Tiger's sshd supports both GSSAPI mechanisms, gssapi and gssapi-with-mic. Previous OS X versions supported only gssapi, so a password was required when logging in to or from an OS X client. SSO support is enabled out of the box for sshd, so there's no config files to edit.

As I stated earlier, with v10.4, almost all of OS X's built-in services and applications are Kerberized, including Apple's Mail.app. If you're running your own CA or using self-signed certificates, you need to import your CA's certificate into the System keychain first, so Mail.app won't complain when connecting to self-signed SSL-enabled services like IMAP and SMTP. Copy the CA cert to the OS X client and then run certtool:

sudo certtool i ci-cert.pem v \
 k=/System/Library/Keychains/X509Anchors

Now you're ready to start Mail.app. The trick to enabling GSSAPI during the account creation process is to fill in the user name and leave the password blank. If you don't already have valid credentials, it will prompt you for your Kerberos password. Once the account is created, go back and enable SSL for IMAP. By default it's not enabled, and Mail.app doesn't give you the choice at account creation time.

All versions of OS X since v10.3 ship with a GUI application for managing Kerberos credentials named Kerberos.app (Figure 4), but it's buried in /System/Library/CoreServices. You can add this useful app to your dock and have it start at boot. It can automatically renew your credentials when they're expiring and easily show you how much longer your credentials are valid, among other useful features.

Figure 4. OS X Kerberos Application

Many of Apple's services and applications are fully Kerberized, including Safari, VPN, Xgrid and AFP, making your Apple users and administrators first-class citizens in your network.

By now you're probably starting to realize the enormous potential of LDAP directories and Kerberos authentication. You have a powerful and scalable infrastructure as well as clients making full use of it. In my next article, we'll discuss how to integrate in one more type of client, Microsoft Windows. Until then, enjoy the fruits of your labor!

This work was supported by the Mathematical, Information, and Computational Sciences Division subprogram of the Office of Advanced Scientific Computing Research, Office of Science, U.S. Department of Energy, under Contract W-31-109-ENG-38. Additional support has been provided by the Computation Institute at the University of Chicago and the National Science Foundation under Grant SCI: 0451491.

Resources for this article: /article/8636.