Paranoid Penguin - Single Sign-On and the Corporate Directory, Part II

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