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
Fast/Flexible Linux OS Recovery
On Demand Now
In this live one-hour webinar, learn how to enhance your existing backup strategies for complete disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible full-system recovery solution for UNIX and Linux systems.
Join Linux Journal's Shawn Powers and David Huffman, President/CEO, Storix, Inc.
Free to Linux Journal readers.Register Now!
|Fancy Tricks for Changing Numeric Base||May 29, 2016|
|Working with Command Arguments||May 28, 2016|
|Secure Desktops with Qubes: Installation||May 28, 2016|
|CentOS 6.8 Released||May 27, 2016|
|Secure Desktops with Qubes: Introduction||May 27, 2016|
|Chris Birchall's Re-Engineering Legacy Software (Manning Publications)||May 26, 2016|
- Tips for Optimizing Linux Memory Usage
- Secure Desktops with Qubes: Introduction
- Working with Command Arguments
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- Secure Desktops with Qubes: Installation
- Fancy Tricks for Changing Numeric Base
- CentOS 6.8 Released
- Linux Mint 18
- The Italian Army Switches to LibreOffice
- Petros Koutoupis' RapidDisk
Until recently, IBM’s Power Platform was looked upon as being the system that hosted IBM’s flavor of UNIX and proprietary operating system called IBM i. These servers often are found in medium-size businesses running ERP, CRM and financials for on-premise customers. By enabling the Power platform to run the Linux OS, IBM now has positioned Power to be the platform of choice for those already running Linux that are facing scalability issues, especially customers looking at analytics, big data or cloud computing.
￼Running Linux on IBM’s Power hardware offers some obvious benefits, including improved processing speed and memory bandwidth, inherent security, and simpler deployment and management. But if you look beyond the impressive architecture, you’ll also find an open ecosystem that has given rise to a strong, innovative community, as well as an inventory of system and network management applications that really help leverage the benefits offered by running Linux on Power.Get the Guide