Times are changing. For those Linux users in corporate environments, being able to share files securely--both with other Linux users and with Windows users--still means remembering a set of passwords for Linux and a set for other platforms. But there's a better way: You can set up your systems so Linux users can gain secure authentication against a Windows NT Domain. That way they won't need a Linux account and a separate NT Domain account. It'll make life easier for you as a network administrator and make your power users happier.
Authentication vs. Account Management
Authentication is a process in which a system identifies a user. Access control determines what is permitted after authentication. Authentication is often closely tied to the concept of accounts, which are, generically, a set of information tied to a unique identifier. This information usually comprises the data needed to let someone use system resources. For example, it provides the location of the user's personal files or the user's real name. It may include environmental variables and resource limits. We'll focus primarily on authentication services and protocols.
Most recent Linux distributions use PAMs (Pluggable Authentication Modules), which are the key to flexible authentication. A PAM is an ASP designed to modularize the process of authenticating a user to a service. It was developed by Sun Microsystems and can be found on recent versions of Sun Solaris, IBM AIX, Hewlett-Packard's HP-UX and Apple Mac OS X, though it is used most widely with the various free operating systems, including Linux (notably Red Hat, Debian and SuSE), FreeBSD and NetBSD.
PAM on Red Hat
We're going to use the PAM system to show how to authenticate against a number of authentication sources. But first, let's get an overview on PAM as installed on a Red Hat Linux 7.2 system (the same techniques should work for any PAM-aware system).
Any service can use PAM for authentication. A service is just another name for an application that needs to perform authentication on behalf of its users. Examples are login, FTP and POP. Note that services must be specially written to use PAM; on Red Hat 7.2, all applications that perform authentication use PAM. You can check if a given executable--for example, login, which is used by the telnet service to check a user's identity--uses PAM by checking if it uses the PAM library, known as libpam, by typing the command as shown in "PAM Library Check". Notice the second line refers to libpam.
Just to make things a bit more complicated, remember that even if an application can authenticate via PAM, it doesn't have to. That is, the application may leave that as a configuration option. Samba and Apache both offer but do not require using PAM.
For each service, there is a file in the /etc/pam.d/ directory. This file contains rules or instructions for how authentication and account information should be obtained for that service, one rule per line. The files are laid out as in "Sample PAM Service Configuration" (at right).
The module, from the third column, is a PAM-aware library that implements some authentication mechanism. The optional fourth column provides arguments to the authentication module. Arguments are module-specific. A module is the program that is executed to determine if the rule allows or denies access.
There are four possible types: auth, account, password and session. Auth specifies that this line should be used when the service is trying to authenticate a user. Account is used when the service needs account information, such as userid. Password is used when the service is trying to change the user's password. And session is used by the service just before user login and immediately after user logout. This is handy for generating audit logs but also could be used to set up various environment settings or mount network disk drives. More than one of each type is allowed; they will be followed in order, unless one of the lines has a control of requisite.
There are four controls: requisite, required, sufficient and optional. Requisite says that if this rule fails, immediately deny access. Required says that if this rule fails, deny access but keep trying the rest of the rules for type. Sufficient says that if this rule succeeds, allow access, but if it fails, fall back to another rule. Optional says to ignore the results of this rule, unless there are no other rules for this type. Optional is typically used for doing additional setup unrelated to authenticating a user (in which case we don't care if the setup fails).
These controls can be confusing. For authentication, it requires the use of the pam_unix PAM module. The arguments to it allow for empty passwords and tell the system to use MD5 cryptographic hashes rather than simple Unix crypt() hashes and to use a shadow password system. Since it is the only type for authentication, it makes the final decision concerning whether to let the user log in.
For account information, the pam_unix module is again used. This is marked as sufficient, so if the module is able to determine the users account, processing stops. If it fails, the PAM system continues and tries the next account rule. This one is marked required and uses the pam_deny module. This module always denies access, so if the first rule was unable to determine account information for the user, the user will be denied access. The example for changing passwords is similar to the account information example.
For determining session requirements, the last example has two rules, which are required. Both modules must execute properly to grant the user a session.
PAM modules are in the directory /lib/security/ on a Red Hat Linux 7.2 system. Some are multifunctional in that they can provide a mechanism for more than one type. Others provide only for single types. To allow for greater flexibility (and further complicate explanation), there is a pam_stack module that provides a way for system administrators to configure any number of services so they authenticate consistently. It is used heavily in Red Hat Linux 7.2 (see "Default Login Configuration").
Note that one rule for each type requires the pam_stack module and provides it an argument of service=system-auth. This in effect says "jump to the system-auth PAM configuration," which is found in /etc/ pam.d/system-auth. So when the login program is trying to authenticate a user, first it runs the pam_security module, which checks to make sure the user is logging in via a trusted console (usually login uses plain-text passwords). If so, it jumps to the configuration found in /etc/pam.d/system-auth, as seen in "Default System-Auth Configuration".
Any service using this system-auth configuration for authentication will first run the pam_env module to set up various environmental variables or check certain prerequisites. Since pam_env is labeled required, the system must report success (and usually will, unless something disastrous occurs, such as the loss of the user's home directory). Then the service will run the pam_unix module, which provides traditional Unix /etc/passwd-type authentication. Since pam_ unix is labeled sufficient, if the configuration returns success, PAM accepts the user as authenticated. Otherwise, the system goes on to the pam_deny module, which always denies access.
Any service using this system-auth configuration to obtain account information also will run pam_unix but this time to locate user name, user ID number, group membership and other traditional Unix /etc/passwd-type information. This is labeled required, though because it's the only account line, it's required by default.
Any service using this system-auth configuration to change passwords first subjects prospective passwords to the pam_cracklib module, which checks the password's strength. As it is labeled required, if the module rejects the password, the service is not allowed to change the password. After that, the prospective password is passed to pam_unix, which will update the traditional Unix /etc/passwd file. If that fails, the password change is denied. See the documentation for PAM for a full explanation of what is going on here, including other available modules.
REPORTS
ANALYTICS
Follow 
