Centralized User Management with Kerberos and LDAP
Travis Crawford
Many computing environments are designed to make network resources available to users from any location, such as personal workstations, public workstations, and the Web. User management is an important part of this type of distributed computing environment because it provides the consistent authentication and authorization service necessary for universal access. Kerberos and LDAP are two protocols that have been designed to solve the distributed authentication and authorization problem.
Centralized management of user accounts solves a major problem in distributed computing environments. Without centralization in an environment with X users, Y computers, and Z services, we have (X*Y)+(X*Z) accounts to manage. With centralization, we have X+Y+Z accounts to manage.
In this article, I will provide an overview of user account management with Kerberos and LDAP. I will describe the protocols and how they work as well as their implementation. Finally, I will discuss how to manage accounts using this new system.
Login Overview
The login process for a Linux system must first be understood before it can be extended. The process begins with a user entering credentials such as username and password into the login program (step 1). Login uses the PAM abstraction layer to authenticate the user (step 2). Typically, the pam_unix module (step 2.1) is used to compare the password entered by the user to the hash stored in the shadow file (2.2). If no entry exists in the shadow file, the normal login process will fail. However, this environment has Kerberos configured, and the pam_krb5 PAM module (2.3) authenticates the user by obtaining a ticket-granting-ticket from the Kerberos server (2.4).
Authentication is only part of the login process. At this point, login has verified that a user is who they claim to be. The authorization phase determines whether the user is allowed to use this resource. Login uses the name service switch (step 3) to look up user information, such as uid number, shell, and home directory. Typically, the nss_files module (3.1) looks up this information in the passwd file (3.2). If the user information is not found locally, this environment uses the nss_ldap module (3.3) to look up the user information from the LDAP server (3.4). The success or failure of this login attempt is reported to the system logger (4), and finally, if steps 2 and 3 are completed successfully, the user is granted access (5) (see Figure 1).
Kerberos
The Kerberos protocol is designed to securely authenticate users over an insecure network and to enable single sign-on. A trusted third party and strong cryptography are used to meet these goals.
Passwords are never sent over the network while using Kerberos. Additionally, mutual authentication verifies the identity of both parties involved in any communication. Finally, single sign-on securely authenticates users automatically after they have logged into the realm.
Kerberos tickets are analogous to a weekend pass at a ski resort. Upon arrival, one obtains a passcard that is valid for a limited period of time. At each mountain, the passcard can be used to obtain a lift ticket. At the end of the weekend, the passcard expires as well as all lift tickets. Kerberos calls its weekend passcard a Ticket Granting Ticket (TGT), which is by default valid for the length of a typical work day. TGTs are used to obtain service tickets that grant access to a specific service, such as LDAP. Additional service tickets must be obtained for additional services.
While this method was first implemented at MIT, Roger Needham and Michael Schroeder designed much of the original protocol at the Xerox Palo Alto Research Center. Their research included both public and private key cryptography and compared the strengths and weaknesses of each method. They concluded that private key cryptography was superior for a network authentication system because it required fewer protocol operations per transaction while remaining equally secure.
Kerberos was first released to the public as Kerberos-4, with the first three releases used internally at MIT; the current release is Kerberos-5. Because of the export controls on strong encryption technologies, an independent Kerberos implementation called Heimdal has been developed at the Center for Parallel Computers in Sweden. Both implementations are well supported and are functionally the same.
Kerberos is an Internet standards track protocol defined in RFC 1510: The Kerberos Network Authentication Service (V5).
Protocol
The Kerberos protocol is designed to securely authenticate users over an insecure network and to enable single sign-on. With these goals in mind, we define two major modes of operation. Initial sign-on (ISO) describes the mode in which a user authenticates as a principal in a Kerberos realm, a concept similar to logging in as a user to a Windows domain. Successful completion of ISO provides the user with a ticket-granting ticket, an electronic ID card that verifies the identity of its owner. Single sign-on (SSO) describes the mode in which a user authenticates to an application in the Kerberos realm; this authentication is automatically performed for the user by the Kerberos client. SSO enables users to enter their username and password just once per computing session.
Initial Sign-On
Initial sign-on describes the following Kerberos Authentication Service protocol exchange:
1. Client to Kerberos: Authentication service request (KRB_AS_REQ)
2. Kerberos to Client: Authentication service reply (KRB_AS_REP) or Error (KRB_ERROR)
The KRB_AS_REQ request message is constructed by a Kerberos client and sent to a Kerberos server. This plain-text message contains the client identity assertion, local time, authentication server principal name, and requested lifetime. The client identity assertion is described as such because a user may attempt to acquire the credentials of a different user; this type of brute force attack is preventable with pre-authentication and will be discussed later. The client's local time is used to ensure reasonably synchronized clocks; although the request message does not rely on synchronized clocks, future protocol operations do, and this helps prevent errors later on. The authentication server principal name is usually krbtgt/INSTANCE@REALM. The requested lifetime is used to request a non-default ticket lifetime.
Pre-authentication is used to prevent the construction of request messages with arbitrary principal names. In response to KRB_AS_REQ request messages for a principal that requires pre-authentication, the Kerberos server returns an encrypted challenge value inside a KRB_ERROR error message. The client must decrypt the challenge value with the user's password and resend the KRB_AS_REQ request message with the appended challenge value. If the server accepts the challenge response, a KRB_AS_REP reply message is constructed and sent to the client. Note that the user has been authenticated without sending his or her password over the network, even in encrypted form.
The KRB_AS_REP reply message is constructed by a Kerberos server and sent to clients in response to KRB_AS_REQ request messages. This message, encrypted with the user's password, contains the user's copy of the unique session key, authentication server principal name, ticket lifetime, and TGT encrypted with the authentication server's password. The encrypted TGT contains the authentication server's copy of the unique session key, client principal name, ticket lifetime, timestamp, and client IP address.
Subsequent communication is encrypted with the session key known only to client and server that is valid for a limited time, for a specific user, from a specific host. These checks ensure that, in the event a KRB_AS_REP reply message is captured and decrypted, the TGT is invalid because either the IP address is incorrect or the ticket lifetime has been exceeded.
The session key contained in a KRB_AS_REP reply message is a private encryption key known only to client and server and is valid only for the current session. Encrypting client to Kerberos server and client to application server communication with unique session keys increases security in several ways. First, every two principals in a Kerberos realm that wish to communicate have a unique session key, thus providing mutual authentication. Second, breaking the encryption on a single session is time sensitive because tickets expire after a period of time.
While confusing at first, the ISO process becomes clear with some inspection. Clients construct a clear-text request message for a TGT that is sent to the server. If pre-authentication is enabled, the server returns an error message that includes a challenge value encrypted with the user's password. The client decrypts the challenge value and appends it to a second TGT request message. The server has now verified the user's identity and sends the client a reply message containing a TGT encrypted with the user's password. The client decrypts the TGT and is authenticated.
Single Sign-On
Single sign-on describes the following Kerberos Authentication Service protocol exchange:
1. Client to Kerberos: Authentication service request (KRB_AS_REQ).
2. Kerberos to Client: Authentication service reply (KRB_AS_REP) or Error (KRB_ERROR).
3. Client to Application server: Application request (KRB_AP_REQ)
4. [Optional] Application server to Client: Application Reply (KRB_AP_REP) or Error (KRB_ERROR).
The KRB_AS_REQ authentication service request message is constructed by a Kerberos client and sent to a server, similar to ISO, except that the authentication server principal name is replaced with the application server principal name. The KRB_AS_REP authentication server reply message contains the user's copy of a unique session key and a service ticket encrypted with the application's password.
After acquiring a service ticket, the client constructs a KRB_AP_REQ application request message and sends it to the application. This message contains the service ticket and authenticator encrypted with the session key; the authenticator contains a timestamp and client principal name. The application decrypts the service key with its password and decrypts the authenticator with the session key. Mutual authentication is achieved because only the appropriate application can decrypt the service ticket, and only the appropriate client has knowledge of the session key to encrypt the authenticator.
Installation and Configuration
Before configuring Kerberos, it is important to decide which implementation to use. Two major Kerberos implementations are freely available for Linux: MIT Kerberos and Heimdal. Both implementations are stable, well supported, and have an active user base. The major difference is that Heimdal is developed outside the United States and therefore is not subject to export control restrictions; many free operating systems use Heimdal for that reason.
The following installation and configuration description is based on MIT Kerberos on Fedora. Begin by downloading the source code from the MIT Web site or installing the krb5-servers and krb5-workstation packages. The default installation path for the source distribution is /usr/local and the packages install to /usr/kerberos.
A new Kerberos server configuration comprises the following steps:
1. The Kerberos configuration file krb5.conf sets defaults used during the configuration process.
2. [libdefaults]
3. default_realm = EXAMPLE.EDU
4.
5. [realms]
6. EXAMPLE.EDU = {
7. kdc = kerberos.example.edu:88
8. admin_server = kerberos.example.edu:749
9. }
10. Initialize a new Kerberos database using kdb5_util. The -s option is used to create a stash file that includes the master database password for unattended server startup.
11. kdb5_util create -s
12. Create administrative and regular users and policies using kadmin.local.
This administrative interface directly modifies the Kerberos database and must be run as root on the KDC; use this interface because no principals currently exist with which to log in. Use kadmin after creating the administrative principal and setting the appropriate access control list.
Kerberos-5 principals are written in the form username/instance@REALM, where username is a user's unique name, instance is an optional group (such as admin), and realm is the realm name in which this ticket is valid.
Create the administrative and default policies:
# kadmin.local -q "addpol -maxlife \"1 month\" -minlength 8 \ -minclasses 3 admin" # kadmin.local -q "addpol -maxlife \"3 months\" -minlength 8 \ -minclasses 3 default"Create an administrative and regular principal for testing the environment:
# kadmin.local -q "addprinc -policy admin +requires_preauth travis/admin" Authenticating as principal root/[email protected] with password. Enter password for principal "travis/[email protected]": Re-enter password for principal "travis/[email protected]": Principal "travis/[email protected] created. # kadmin.local -q "addprinc travis" Authenticating as principal root/[email protected] with password. NOTICE: no policy specified for [email protected]; assigning "default" Enter password for principal "[email protected]": Re-enter password for principal "[email protected]": Principal "[email protected] created.13. Edit the kadmind access control list. /var/kerberos/krb5kdc/kadm5.acl. This file contains a list of principals that are authorized to perform administrative tasks. From the kadmind(8) man page we find the following access controls. If the character is lowercase, then the operation is permitted; if the character is uppercase, then the operation is disallowed. 14. a -- [Dis]allows the addition of principals or policies in the database. 15. d -- [Dis]allows the deletion of principals or policies in the database. 16. m -- [Dis]allows the modification of principals or policies in the database. 17. c -- [Dis]allows the changing of passwords for principals in the database. 18. i -- [Dis]allows inquiries to the database. 19. l -- [Dis]allows the listing of principals or policies in the database. 20. x -- Short for admcil. 21. * -- Same as x. A simple ACL that allows all principals with an administrative instance full control may be sufficient in small environments, while more complex lists may be required in environments with distributed support groups:
*/[email protected] *22. Start the krb5kdc and kadmind services and test that everything works by logging into kadmin with the principals you created. A minimal Kerberos server is now configured and should be adequate for testing purposes. Before using in a production environment, be sure to read the man pages and understand very well what you are doing. Backup and Restore Several methods are available for backing up the Kerberos-5 database, including a full filesystem backup and Kerberos database dump. The recommended backup method is to use the dump mode of kdb5_util(8). As root, stop the server process, dump the Kerberos database, and then restart the process:
service krb5kdc stop kdb5_util dump kerberos-backup.txt service krb5kdc startThe backup file is encrypted with either the KDC password or dump-specific password if the mkey_convert option is used. Write this file to tape or a remote filesystem and protect it to the same extent as the live KDC; compromising the backup database is as dangerous as compromising the live database. Restore the KDC database using the load mode of kdb5_util. Load creates a new database containing only the principals in the dump file, overwriting any existing principals. Existing principals are kept when using the update option. As root, stop the server process, load the Kerberos database, and then restart the process:
service krb5kdc stop kdb5_util load kerberos-backup.txt current-database service krb5kdc startA Kerberos database into which the backup will be loaded must already exist. LDAP The Lightweight Directory Access Protocol (LDAP) defines a method to search and modify a remote database. Directory services are used to reduce the number of administrative data repositories in an organization. LDAP has its roots in the X.500 series of specifications, a worldwide directory service complete with protocol, object classes, attribute types, authentication framework, and replication. The directory as defined was so thorough in its design that it became difficult to implement. The complexity of implementation was not limited to servers; clients were difficult to write as well. The University of Michigan recognized this limitation and created LDAP, a gateway to X.500 servers with a simple client interface. By making LDAP clients easier to implement, more applications began to use the directory, thus making it more useful. Eventually the gateway became the first standalone LDAP server. LDAP is an Internet standards track protocol defined in RFC 2251: Lightweight Directory Access Protocol (v3). Protocol LDAP directory access operations describe the following protocol exchange: 1. Client to server: Bind request 2. Server to client: Bind result 3. Client to server: Search request 4. Server to client: Search entry 5. Server to client: Search result 6. Client to server: Unbind request The bind request message is constructed by an LDAP client and sent to an LDAP server. It indicates the beginning of a new connection and contains the distinguished name and password credentials with which to bind. LDAP supports several authentication methods (specified by the Auth Type), including Kerberos through the GSSAPI, so this data may or may not be encrypted, depending on how the server is configured. Servers respond with a bind result message to bind request messages. A result code, such as success, or error message indicates whether the bind was successful and whether the connection should continue. Once bound, the client sends a search request message that contains a Base DN, scope, and filter. The Base DN, such as ou=people,dc=example,dc=edu, specifies where in the namespace hierarchy to start the search. For example, a search for user accounts might be limited to the user section of the namespace and omit searching application settings. The scope specifies how deep to look and may be base (base DN only), oneLevel (children of the base DN), or sub (all entries below the base DN). Finally, the search filter specifies what to look for. Search filters are written in the form attribute=value and may be combined with a subset of boolean operators. To find the entry that represents my user account, I would construct a query such as (&(objectClass=posixAccount)(uid=travis)). Most LDAP-aware applications take care of constructing the search filter; however, the command-line program ldapsearch allows you to specify a custom filter. You might be surprised at how much information can be extracted from public LDAP servers by constructing custom queries because many sites implement access control, not in the LDAP server itself, but in their Web-based front-end. The search entry message is sent from server to client, with one message per entry matching the search filter. These messages contain the distinguished name and all associated attribute/value pairs. The results are either returned printed to the screen or returned to the application as an array for processing. The Search result message is sent from server to client to indicate a successful operation after all search entry messages have been sent. Finally, an unbind request message is sent from client to server to indicate no additional search requests will be sent. This implies that multiple search requests may be sent during a single connection, which reduces overhead. Schema The LDAP schema defines what data can be stored in the directory. It is the collection of attribute types and object classes that are valid. Attribute types define a specific type of variable for use in the directory. It defines the name, matching rule, and whether the attribute may be defined multiple times for a specific entry. Directory-enabled applications use attribute types to store their data. RFC2307 defines a schema that enables Linux clients to store user accounts in a directory server. The nis.schema file packaged with OpenLDAP implements RFC2307 and provides the attribute and object class definitions to store the contents of /etc/passwd, /etc/shadow, and /etc/group in a directory. Providing the functionality of these files in the directory allows it to replace local databases throughout an organization. Structural object classes typically represent real-world objects, such as people or organizations. Every LDAP entry has exactly one structural object class but may have additional auxiliary object classes. For example, the structural object class person represents a person, and the auxiliary object classes posixAccount and shadowAccount represent the person's computer account. Object classes and attributes are defined in the schema files included with directories and directory-enabled applications. Directory entries with structural object class person represent individual people who may or may not have a computer account:
objectclass ( 2.5.6.6 NAME 'person' SUP top STRUCTURAL MUST ( sn $ cn ) MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) )Directory entries with auxiliary object class posixAccount represent user accounts by allowing attributes that map directly to each field in the /etc/passwd file:
objectclass ( 1.3.6.1.1.1.2.0 NAME 'posixAccount' SUP top AUXILIARY
DESC 'Abstraction of an account with POSIX attributes'
MUST ( cn $ uid $ uidNumber $ gidNumber $ homeDirectory )
MAY ( userPassword $ loginShell $ gecos $ description ) )
Directory entries with auxiliary object class shadowAccount allow attributes
that map directly to each field in the /etc/shadow file:
objectclass ( 1.3.6.1.1.1.2.1 NAME 'shadowAccount' SUP top AUXILIARY
DESC 'Additional attributes for shadow passwords'
MUST uid
MAY ( userPassword $ shadowLastChange $ shadowMin $
shadowMax $ shadowWarning $ shadowInactive $
shadowExpire $ shadowFlag $ description ) )
Directory entries with the object class posixGroup represent groups; these
entries are used to replace the /etc/group file:
objectclass ( 1.3.6.1.1.1.2.2 NAME 'posixGroup' SUP top STRUCTURAL
DESC 'Abstraction of a group of accounts'
MUST ( cn $ gidNumber )
MAY ( userPassword $ memberUid $ description ) )
Attributes are given a name, unique object identifier, matching rule, and type.
The object type specifies whether this attribute may exist more than once for
the same entry. For example, the homeDirectory attribute may be assigned
only once to an entry and, like all Linux path names, is case sensitive:
attributetype ( 1.3.6.1.1.1.1.3 NAME 'homeDirectory'
DESC 'The absolute path to the home directory'
EQUALITY caseExactIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
Configure the Server
The OpenLDAP configuration file slapd.conf contains configuration information
for the OpenLDAP server. It should not be world-readable because several secret
pieces of information must be stored in it, such as the root directory account
and password and access control list definitions. Schema files that represent
Linux user accounts and groups must be imported and the schema check enabled
to ensure the schema are followed:
# Linux user accounts (objectClass posixAccount) are defined in # nis.schema # core.schema and cosine.schema are required by nis.schema include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/nis.schema schemacheck onLogging will be very useful when configuring the server; the level of verbosity is specified with the loglevel option:
# Messages are logged to LOCAL4 # Add "local4.* /var/log/slapd.log" to your syslogd configuration loglevel 256The database section of slapd.conf specifies the backend database in which the directory will be stored. Specify the database format, where to store the database files, mode for new files, and the directory suffix:
# back-end database configuration database ldbm directory "/var/lib/ldap" mode 0600 suffix "dc=example,dc=edu"The root directory user specifies a distinguished name that, when bound as, has no search or modify restrictions. Although the password may be stored in this file as plain text, that practice is highly discouraged; use a password hash instead. Again, ensure the permissions on the configuration file prevent read access:
# root directory user account
rootdn "cn=Manager,dc=example,dc=edu"
rootpw {MD5}Xr4ilOzQ4PCOq3aQ0qbuaQ==
SASL AND GSSAPI
OpenLDAP does not directly support Kerberos-5 authentication. However, support
is available through the SASL GSSAPI mechanism. The Simple Authentication and
Security Layer (SASL) is a framework for integrating external authentication methods
into an existing protocol. SASL does not provide any authentication methods of
its own; it simply provides a framework to integrate third-party authentication
services. One supported SASL authentication source is Kerberos-5, which is accessed
via the Generic Security Services Application Programming Interface (GSSAPI):
LDAP <--> SASL <--> GSSAPI <--> KerberosThe following options are available in slapd.conf for enabling Kerberos support. Specify the server, realm, and security properties:
sasl-host kerberos.example.edu sasl-realm EXAMPLE.EDU sasl-secprops noplain,noactive,noanonymousThe sasl-secprops option specifies which security options to use; the above listed values are sufficient for GSSAPI. When GSSAPI is used as an authentication source, slapd.conf ACL entries must be modified because GSSAPI-distinguished names end with cn=gssapi,cn=auth. To allow all users who authenticate with GSSAPI to have read access, machines to have read access, and everyone to have no access, use an ACL similar to the following:
access to *
by dn.children="cn=gssapi,cn=auth" read
by dn.children="ou=Machines,dc=example,dc=edu"
by anonymous auth
A Kerberos principal must be created for LDAP, and the LDAP server keytab must
be updated. Ensure slapd has read access to the keytab:
kadmin -q "addprinc -randkey ldap/[email protected]" kadmin -q "ktadd ldap/[email protected]"Clients can query the LDAP server using GSSAPI for authentication by first obtaining a TGT and specifying the appropriate SASL mechanism:
kinit travis ldapsearch "(uid=travis)" -Y gssapiTransport Layer Security Transport Layer Security (TLS) is the evolution of SSL and is used to encrypt the communication between hosts at the transport layer. Enabling TLS first requires the creation of a digital certificate and key:
/usr/local/ssl/misc/CA -newcertThe script will prompt you for several pieces of information, such as country, state, etc. These values can be filled with whatever you like, except for the common name of your server. This must be the DNS name of your LDAP server or TLS will not work. List the required cipher strength, certificate, and key in:
slapd.conf. TLSCipherStrength HIGH TLSCertificateFile /etc/openldap/ldap-key-cert.pem TLSCertificateKeyFile /etc/openldap/ldap-key-cert.pemBackup and Restore A comprehensive backup strategy will allow the directory to be restored after a disaster, user error, or malicious network attack. Two methods are available for backing up directory data: back up the entire filesystem on which the directory database is stored, or create an LDIF file containing all directory entries. The dump and restore commands are used to back up and restore entire filesystems. The slapcat and slapadd commands are used to create and restore LDIF files. Creating then archiving an LDIF file is the recommended backup method because the format is server independent and stored as ASCII text rather than in binary format. This allows an administrator to make changes or correct errors before restoring the directory. As root, stop the LDAP server, write the directory contents to a file on disk, and then restart the server:
service ldap stop slapcat > directory-backup.ldif service ldap startThis method may be unacceptable because it requires stopping the service. In a replicated environment, a slave server may be used to export the database, thus keeping the service available. The directory-backup.ldif file may be copied to tape or a remote file system for safekeeping. Security of the backup is critical because access control restrictions are implemented in the LDAP server, not the data file itself. This file is organized in superior first order, the same format that slapadd requires. The directory may be restored with:
service ldap stop slapadd < directory-backup.ldif service ldap startThe LDAP server must be properly configured, purged of any old data, and not running before data can be added. Client Configurations Each Linux client must be configured to authenticate users and look up account information over the network rather than to use the default local databases. These network services should be transparently accessed to make the login process easy for the user. Kerberos and Pluggable Authentication Modules (PAM) implement authentication, while LDAP and the Name Service Switch (NSS) implement look up of user information in the directory. Kerberos Client Configuration The Kerberos client configuration file /etc/krb5.conf specifies the local realm name and other parameters needed for authentication. More information is available in krb5.conf(5):
[libdefaults]
default_realm = EXAMPLE.EDU
[realms]
EXAMPLE.EDU = {
kdc = kerberos.example.edu:88
admin_server = kerberos.example.edu:749
}
Pluggable Authentication Modules
PAM is the Linux subsystem that handles authentication tasks on behalf of
applications. It breaks down authentication into four distinct tasks: authentication,
account management, session management, and password management. Authentication
verifies the user is who he or she claims to be. Account management determines
whether the authenticated user is permitted access at this time. Session management
functions trigger events at login and logout, such as writing log entries. Password
management functions change users' passwords.
PAM-aware applications can be configured globally with /etc/pam.conf
or individually with files in /etc/pam.d. The presence of the /etc/pam.d
directory causes the global configuration file to be ignored. The pam_stack.so
module can be used to include configuration files.
We enable the Kerberos authentication service in PAM by adding the pam_krb5.so
module to the appropriate PAM stack, such as the system-auth file that
is included in most application configurations. Enable Kerberos for authentication
and password tasks:
# /etc/pam.d/system-auth auth required pam_env.so auth sufficient pam_unix.so likeauth nullok auth sufficient pam_krb5.so use_first_pass auth required pam_deny.so account required pam_unix.so password required pam_cracklib.so retry=3 type= password sufficient pam_unix.so nullok use_authtok md5 shadow password sufficient pam_krb5.so use_authtok password required pam_deny.so session required pam_limits.so session required pam_unix.soAfter enabling Kerberos authentication in PAM, test the configuration by logging in with Kerberos credentials. More information is available in pam(8), The Linux-PAM System Administrators' Guide, and The Linux-PAM Module Writers' Guide (see References). LDAP Client Configuration The LDAP client configuration file /etc/ldap.conf specifies server connection parameters. More information is available in ldap.conf(5):
uri ldaps://ldap.example.edu base dc=example,dc=eduName Service Switch The NSS specifies where to look up name information and in what order. Traditionally, names were looked up in the passwd file by each application. The introduction of NSS allowed multiple name services by abstracting the lookup request from the actual lookup. Programs now make a request to NSS for a lookup and the appropriate library is used. Specify LDAP as a source for user account and group information in nsswitch.conf(5):
passwd: files ldap shadow: files ldap group: files ldapEach line specifies a type of information to look up, followed by a list of locations in which to look it up. Local files are first consulted for account information. If a user account does not exist locally, the LDAP server is queried. This allows local users to still log in if the LDAP server is unavailable. After LDAP and NSS are configured, user account information may be looked up in the directory. Configuration Tools Most Linux distributions have tools for configuring Kerberos, PAM, LDAP, and NSS. Red Hat and Fedora users have authconfig(8) and the GUI-equivalent, authconfig-gtk, for reconfiguring an existing installation and Kickstart for new installations. Kickstart allows an administrator to automate the installation process by providing an answer file for common configuration questions, such as authentication and user account lookup methods. Check the documentation of your distribution for more information on configuration tools. Account Management The creation, modification, and deletion of user accounts on a single Unix system are simple tasks with the user{add|mod|del}, group{add|mod|del} and passwd commands. These commands are not compatible with Kerberos or LDAP, so we must look elsewhere for user management tools. Administrative Tools Kadmin is the Kerberos administrative interface for use over a network. It can be used to create, modify, and delete principals and policies. It authenticates using Kerberos and supports both command-line and interactive use. Kadmin replaces the passwd command in this environment. Change password utility (CPU) is a user and group management tool that supports an LDAP backend. CPU replaces user{add|mod|del}, and group{add|mod|del}, making it a useful tool in our environment, performing most user and group management tasks. Kadmin uses the main Kerberos configuration file krb5.conf(5). CPU uses the configuration file cpu.conf. Most of the defaults are sensible; however, be sure to change the connection parameters and directory suffix. See cpu.conf(5) for more information. Password Policies The policies feature allows an administrator to set password requirements such as length and number of required character classes. Specific policies may be assigned to principals during creation; if it exists, the policy named "default" is used when no policy is specified. See kadmin(8) for more addpol options:
kadmin -q "addpol -maxlife \"90 days\" -minlength 8 -minclasses 3 default" kadmin -q "addpol -maxlife \"30 days\" -minlength 12 -minclasses 3 admin"Creating Accounts Users, machines, and services are represented as principals in the Kerberos database. Password and account aging similar to chage is supported, along with some Kerberos-specific options such as pre-authentication. It is recommended to assign each user the default policy, as well as to require pre-authentication. See kadmin(8) for more add_principal options. The workflow for creating a user account in an environment with Kerberos and LDAP is very similar to creating users on a traditional Unix system. Create the user account with an LDAP-aware tool such as cpu, then create the Kerberos principal. These steps are very similar to creating a user with useradd and setting the password with passwd. Principals with an administrative instance typically do not require an LDAP user account because these principals are reserved for Kerberos administrative tasks only:
cpu useradd travis kadmin -q "addprinc -policy admin travis/admin" kadmin -q "addprinc travis"Disabling Accounts Users come and go, so occasionally user accounts will need to be disabled. The process of disabling an account is similar to the method used with passwd and shadow files. We delete the user's Kerberos principal to prevent password-based authentication and change the user's shell to /sbin/nologin to prevent authentication with SSH keys. This method preserves a record of the user and ensures the uid is not reused. Remember to remove all principals for the users, such as their principal with an administrative instance:
kadmin -q "delprinc travis" cpu usermod -s /sbin/nologin travisReferences
MIT Kerberos Site -- http://web.mit.edu/kerberos/
RFC 1510 (Kerberos specification) -- http://www.ietf.org/rfc/rfc1510.txt
Kerberos FAQ -- http://www.cmf.nrl.navy.mil/CCS/people/kenh/kerberos-faq.html
Heimdal -- http://www.pdc.kth.se/heimdal/
Fedora -- http://fedora.redhat.com/
comp.protocols.kerberos -- http://www.google.com/groups?group=comp.protocols.kerberos
Needham, R., and M. Schroeder. "Using Encryption for Authentication in Large Networks of Computers." Communications of the ACM, 21(12):993-999.
Carter, Gerald. 2003. LDAP System Administration. O'Reilly & Associates.
RFC 2251 (LDAP specification) -- http://www.ietf.org/rfc/rfc2251.txt
Linux-PAM System Administrator's Guide -- http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/pam.html
Linux-PAM Module Writer's Guide --http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/pam_modules.html
Garman, Jason. 2003. Kerberos: The Definitive Guide. O'Reilly & Associates.
Howes, T., M.G. Smith, and G.S. Good. 2003. Understanding and Deploying LDAP Directory Services, 2nd Ed. Addison-Wesley.
Change Password Utility -- http://cpu.sourceforge.net/
Travis Crawford is a Systems Administrator at Google, where he works with large Linux clusters, and recently a graduate of the Rochester Institute of Technology where he studied Information Technology. He can be reached at [email protected].
