Authentication Services

In Chapter 5, "User Environment Management and Security," we examined the processes involved with user authentication. We introduced the PAM module system and explored the relationship between the pam_unix2 module and the /etc/passwd and /etc/shadow files. Here, we expand on this topic and look at alternate sources that will allow for network-wide authentication of users. As the number of machines increases in an environment, it will become more and more difficult for users to keep track of passwords across multiple platforms. A centralized network authentication mechanism will help alleviate the difficulties of keeping passwords up to date and secure.

Network Information Services (NIS)

The Network Information Services (NIS), formally known as Yellow Pages, provide a Unix-centric client/server environment for controlling usernames, groups, and passwords as well as machine and directory information. In this environment, a master server is created and is configured to accept connections from a set group of client machines.

On the client side, no information is stored in the local /etc/passwd file. When an authentication request is made by a user initiating a session, the information is passed along to the master server. The master then either declines the authentication or returns the default directory for the user as well as the list of groups the user belongs to.

In such an environment, users' home directories are often resident on a single server and made available across the network as exported NFS shares.

In terms of PAM, the standard pam_unix2 module understands and interacts with the NIS environment.

Samba Domains

Samba is an implementation of a group of applications that provide for cross-platform file and print services. It is an open source implementation of the Server Message Block (SMB) and Common Internet File System (CIFS). Both of these protocols were originally defined by Microsoft. Unlike the Microsoft implementation of SMB and later CIFS, Samba is available on a multitude of platforms and native operating systems.

Included in the architecture of Samba is the concept of a domain within which users and servers reside. SLES can be configured to be the primary domain controller (PDC), a secondary (or backup) domain controller (BDC), or simply a member server. In any of these configurations, the authentication process for member SLES servers can be made to point to the central repository of domain accounts.

Unlike NIS, Samba allows for the bridging of the authentication environment across noncompatible operating systems such as OpenVMS, Unix, and Windows.

Lightweight Directory Access Protocol (LDAP)

The Lightweight Directory Access Protocol (LDAP) is a reduced scope implementation of the X.500 directory protocol. LDAP allows for a server or group of servers to share a common repository of information. A typical use for LDAP would be as an address book. Such repositories can contain large volumes of data that need to be accessed in a variety of ways quickly and efficiently. Additionally, LDAP does not demand that all entries contain the same collection of attributes.

As a central store of information, an LDAP server can be accessed by numerous systems simultaneously. Because it is based on an open standard, multiple different applications and platforms can exchange information through a consistent data model. These attributes make LDAP an ideal candidate for sharing account information.

In SLES, the centralized LDAP server can contain not only account information such as username, password, and default directory, but it can also contain information pertaining to DNS and DHCP.

Kerberos

Kerberos is an altogether different method of authentication. In the previous examples and in the case of using the /etc/passwd file, a user is prompted for both a username and password. Both are then sent to the authentication mechanism within PAM that looks at these pieces of information and confirms their correctness. When access to other disparate resources is required, the challenge response mechanism is invoked again and again.

Kerberos is based on a totally different approach. The Kerberos model requires that a server be set aside with the sole purpose of authentication. This server must be a system that the entire infrastructure can trust and must therefore be physically segregated from other servers, have a minimum number of administrators, and have no local users. Kerberos also requires that the network environment be kept time synchronized. One parameter used in the Kerberos environment is time stamps, which prevent information collected at one point in time to be rebroadcast on the network later. Because the information is time-stamped, the rebroadcast data would be considered tainted.

The Kerberos authentication process begins when a new user asks for access to a resource. When this occurs, the following events are put into motion:

1.	This user is prompted for his or her username.
2.	The client sends the client name to the Kerberos server as well as a request for a ticket.
3.	The authentication server collects information on time and IP addresses, generates a random session key, and encrypts this as a key known only by itself and a ticket-granting server. It then takes this encrypted data, a time stamp, and some additional information and reencrypts it in the client's own private key, its password. This new packet of data is sent back to the client.
4.	The local workstation then asks the user for his or her password. The password is then used to generate the decryption key for the data packet. Because the user's password is never sent over the network, the chance of its interception is zero.
5.	If the decryption is successful, the client now has a copy of the bundle that can be decrypted only by the ticket-granting server.
6.	The client can now send this packet to the ticket-granting server to obtain an authentication ticket that is valid for a fixed lifetime.

Kerberos is therefore quite secure. All conversations between the client and server are encrypted. The user's password is never transmitted over the network but is used as the encryption/decryption key for the conversation. Additionally, a portion of the data returned to the client is encrypted by the Kerberos server itself using a private key. Because only the Kerberos server and the ticket- granting server know this key, there are no mechanisms in place through which a client can generate a false ticket.

When a client requests access to a service, the ticket information, a time stamp, and the client IP address are bundled and encrypted with the session key and sent to the target server. The target server can then decrypt the information, verify the validity of the ticket, and grant access.