The candidate should be able to configure PAM to support authentication
via traditional /etc/passwd, shadow passwords, NIS
or LDAP.
Key files, terms and utilities include:
/etc/pam.d |
/etc/pam.conf |
PAM stands for Pluggable Authentication Modules. PAM consists of a set of libraries and an API (Application programming Interface) that can be used to perform authentication tasks. Privilege granting programs, such as login and su, use the API to perform standard authentication tasks.
The authentication tasks can be subdivided into four different functional groups:
Provide account verification types of service: has the user's password expired?; Is this user permitted access to the requested service?
Establish if the user really is whom he claims to be. This can be done, for example, by asking a password or, given the right module, by reading a chip-card or by performing a retinal or fingerprint scan.
This group's responsibility is the task of updating authentication mechanisms. Typically, such services are strongly coupled to those of the authentication group. Some authentication mechanisms lend themselves well to being updated. The user might be presented with a question like “Please enter the new password”.
This group of tasks covers things that should be done prior to a service being offered and after it is withdrawn. Such tasks include the maintenance of audit trails and the mounting of the user's home directory. The session management group is important as it provides both an opening and closing hook for modules that affect the services available to a user.
PAM can be configured using the file /etc/pam.conf
which has the following format:
service type control module-path module-arguments
The meaning of these five fields is:
This is the name of the application involved, for example: login, ssh or passwd.
This is the type of group the task to be performed belongs to: account, auth (the authentication group), password or session.
This field indicates what the PAM-API should do in case authentication fails for any module.
The are four valid values for the control field:
Upon failure, the authentication process will be terminated immediately.
This will return failure after the remaining modules for this service and type have been invoked.
Upon success, the authentication process will be satisfied, even if a prior required module has failed the authentication.
The success or failure of this module is only important if this is the only module associated with this service and this type.
This is the filename, including the full path, of the PAM that is to be used by the application.
These are module specific arguments, separated by spaces, that are to be passed to the module. Refer to the specific module's documentation for further details.
Configuration is also possible using individual configuration
files, which is recommended. These files should all be located in the
/etc/pam.d directory. If this directory exists,
the file /etc/pam.conf will be ignored. The
filenames should all be lowercase and be identical to the name of the
service, such as login. The format of these
files is identical to /etc/pam.conf with the
exception that there is no service field.
What we need is the unix authentication module
pam_unix.so which uses standard calls from the
system's libraries to retrieve/set account information/authentication.
This information is obtained from the files
/etc/passwd and, if shadow passwords are enabled,
/etc/shadow.
The pam_unix.so module supports the following
management groups:
The type “account” does not authenticate the user but checks
other things such as the expiration date of the password and
might force the user to change his password based on the contents
of the files /etc/passwd and
/etc/shadow.
The following options are supported:
Log information using syslog.
Also logs information, even more than debug does.
The type “auth” checks the user's password against the password
database(s). This component is configured in the file
/etc/nsswitch.conf. Please consult the
man page (man nsswitch.conf) for further
details.
The following options are supported:
Log information using syslog.
Also logs information using syslog but less than audit.
This argument sets the delay-on-failure, which has a default of a second, to nodelay.
Allows empty passwords. Normally authentication fails if the password is blank.
Use the password from the previous stacked auth module and prompt for a new password if the retrieved password is blank or incorrect.
Use the result from the previous stacked auth module, never prompt the user for a password and fails if the result was a fail.
The type “password” changes the user's password.
The following options are supported:
Log information using syslog.
Use the DEC “C2” extension to crypt().
Also logs information using syslog but less than audit.
Use md5 encryption instead of crypt().
Use NIS (Network Information Service) passwords.
Don't use the passwords from other stacked modules and do not give the new password to other stacked modules.
Allows empty passwords. Normally authentication fails if the password is blank.
Remember the last n passwords to prevent the user from using one of the last n passwords again.
Use the password from the previous stacked auth module, and prompt for a new password if the retrieved password is blank or incorrect.
Set the new password to the one provided by a previous module.
Use the result from the previous stacked auth module, never prompt the user for a password and fails if the result was a fail.
The type “session” uses syslog to log the user's name and session type at the start and end of a session.
The “session” type does not support any options.
For each service that requires authentication a file with the name of
that service must be created in /etc/pam.d.
Examples of those services are: login,
ssh, ppp,
su.
For example purposes the file
/etc/pam.d/login will be used:
# Perform password authentication and allow accounts without a password
auth required pam_unix.so nullok
# Check password validity and continue processing other PAM's even if
# this test fails. Access will only be granted if a 'sufficient' PAM,
# that follows this 'required' one, succeeds.
account required pam_unix.so
# Log the user name and session type to syslog at both the start and the end
# of the session.
session required pam_unix.so
# Allow the user to change empty passwords (nullok), perform some additional
# checks (obscure) before a password change is accepted and enforce that a
# password has a minimum (min=4) length of 4 and a maximum (max=8) length of
# 8 characters.
password required pam_unix.so nullok obscure min=4 max=8
To be able to authenticate via NIS, the module
pam_nis.so is needed. This module can be
found at
PAM NIS Authorisation Module.
To set up things in such a way that NIS authentication is sufficient
(and if that is not the case try pam_unix.so), the
lines that do the trick in /etc/pam.d/login are:
auth sufficient pam_nis.so item=user \
sense=allow map=users.byname value=compsci
auth required pam_unix.so try_first_pass
account sufficient pam_ldap.so \
item=user sense=deny map=cancelled.byname error=expired
account required pam_unix.so
To be able to authenticatie via LDAP, the module
pam_ldap.so is needed. This module can be
found at
PADL Software Pty Ltd.
To set up things in such a way that LDAP authentication is sufficient,
(and if that is not the case try pam_unix.so), the
lines that do the trick in /etc/pam.d/login are:
auth sufficient pam_ldap.so
auth required pam_unix.so try_first_pass
account sufficient pam_ldap.so
account required pam_unix.so