Authentication Servers

Prerequisites: Directory Servers

We want a single point of authentication for our users. We prefer either LDAP or NIS. If NIS, the NIS domain name is always the same as the DNS domain name. It's possible we could tree out NIS domains which are subsets of the DNS domain, but this has not yet been necessary.

We'd like to clarify how we differentiate between a simple directory service and an authentication service: A directory service supplies information through a one-way trust relationship -- the client trusts the server to give accurate information. This trust typically comes from the fact that a local configuration file (resolv.conf, ypservers) tells the client which server to contact. This is part of an authentication service, but there is a fine distinction.

An authentication service supplies an interaction that develops a two-way trust. The client uses the service to prove itself trustworthy. The UNIX login process provides a good example of this interaction. The client (in this case, a person) enters a text string, the password. This is compared to a trusted valued by the server (the UNIX host.) If they do not match, no trust is developed. Login is denied. If they do match, the user is rewarded with control of a process operating under their name and running their shell. The whole point of an authentication service is that it allows the client to prove itself to be trustworthy, or at least to prove itself to be the same nefarious character it claims.

LDAP, NIS, NIS+, Kerberos, and a raft of commercial products can be used to provide authentication services. We've been through endless gyrations trying to find the "perfect" authentication service. In the past, we kept on ending up back at NIS, not because we liked it so much as because it was there. LDAP is today a much better choice. NIS+ has been proven, over and over again, to not be reliable enough to justify the extra security.

It's useful to note that there are really only four elements to a user's account in UNIX -- the encrypted password, the other info contained in /etc/passwd (such as UID), the info contained in /etc/group, and the contents of the home directory. To make a user you have to create all of these. Likewise, to delete a user you have to delete all of these.

Of these four elements, the encrypted password is the most difficult to manage. The UID and GID mappings found in /etc/passwd and /etc/group can easily be distributed to clients via file replication (see File Replication Servers ) . The home directory is usually best served via NFS and automounter (see Client File Access ) .

In shadow password implementations, the encrypted password is located in a separate database on the local host. In implementations such as NIS and Kerberos, the encrypted password and the mechanisms used to authenticate against it are moved totally off the local host onto a server machine.

We wanted to develop a single point of authentication for our users. This meant either replicating the same /etc/passwd, /etc/group, and /etc/shadow to all machines and requiring users to always change their password on a master machine, or using LDAP or NIS, or installing something like Kerberos, or putting together an in-house solution.

It's interesting to note that even if we had used Kerberos we still would have needed to replicate /etc/passwd and /etc/group; Kerberos does not provide the information contained in these files.

What we usually ended up doing in the past was using NIS and replicating /etc/passwd and /etc/group with minimal contents. This way we were able to overlay any local changes made to the files; we didn't want local users and groups proliferating.

Today, LDAP can be used instead, even for those platforms which don't explicitly support it -- a Perl script in cron to dump selected objects to a local flat file is sufficient.

In keeping with the "enterprise cluster" philosophy, we always retained a one-to-one mapping between the borders of the DNS, NIS, and/or LDAP domains or trees. The NIS domain name was always the same as the DNS domain name. This gave us no leeway in terms of splitting our cluster up into security realms, but we found that we didn't want to; this kept things simple.

In fact, the DNS domain name is the name of the cluster -- our scripts, configuration files, and design assumptions depend on this useful abstraction.

If you do want to split things up, you might try subclassing machines into different DNS subdomains, and then either use NIS+ subdomains, hack the way NIS generates and distributes its maps to create a subdomain-like behavior, use LDAP subtrees, or use different Kerberos realms in these DNS subdomains. Either way, these DNS subdomains would be children of a single parent DNS domain, all of which together would be nested clusters, with only one gold server to tie them all together.

A note about username strings and keeping users happy: In today's wired world, people tend to have many login accounts, at home, at work, and with universities and professional organizations. It's helpful and will gain you many points if you allow users to pick their own login name, so they can keep all of their worlds synchronized. You don't have to look at and type that name every day -- they do, over and over. They will think of you every time. You want that thought to be a positive one.