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.
Listing 1. /etc/openldap/ldap.conf
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.
Listing 2. /etc/ldap.conf
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
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
|Non-Linux FOSS: Seashore||May 10, 2013|
- RSS Feeds
- Dynamic DNS—an Object Lesson in Problem Solving
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- New Products
- A Topic for Discussion - Open Source Feature-Richness?
- Drupal Is a Framework: Why Everyone Needs to Understand This
- Validate an E-Mail Address with PHP, the Right Way
- What's the tweeting protocol?
- Readers' Choice Awards
- BASH script to log IPs on public web server
2 hours 39 min ago
6 hours 15 min ago
- Reply to comment | Linux Journal
6 hours 47 min ago
- All the articles you talked
9 hours 10 min ago
- All the articles you talked
9 hours 14 min ago
- All the articles you talked
9 hours 15 min ago
13 hours 40 min ago
- Keeping track of IP address
15 hours 31 min ago
- Roll your own dynamic dns
20 hours 44 min ago
- Please correct the URL for Salt Stack's web site
23 hours 56 min ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?