test

System Administration Guide

Chapter 53 Using Authentication Services (Tasks)

The first section of this chapter provides information about the authentication mechanisms that may be used with Secure RPC. Both Diffie-Hellman and Kerberos Version 4 authentication are supported. The second section covers the Pluggable Authentication Module (PAM) framework. PAM provides a method to "plug-in" authentication services and provides support for multiple authentication services.

This is a list of the step-by-step instructions in this chapter.

Overview of Secure RPC

Secure RPC is a method of authentication that authenticates both the host and the user making a request. Secure RPC uses either Diffie-Hellman or Kerberos authentication. Both of these authentication mechanisms use DES encryption. Applications that use Secure RPC include NFS and the NIS+ name service.

NFS Services and Secure RPC

The NFS software enables several hosts to share files over the network. Under the NFS system, a server holds the data and resources for several clients. The clients have access to the file systems that the server exports to the clients. Users logged in to the client machine can access the file systems by mounting them from the server. To the user on the client machine, it appears as if the files were local to the client. One of the most common uses of the NFS environment is to allow systems to be installed in offices, while keeping all user files in a central location. Some features of the NFS system, such as the -nosuid mount option, can be used to prohibit the opening of devices as well as file systems by unauthorized users.

The NFS environment uses Secure RPC to authenticate users who make requests over the network. This is known as Secure NFS. The authentication mechanism, AUTH_DH, uses DES encryption with Diffie-Hellman authentication to ensure authorized access. The AUTH_DH mechanism has also been called AUTH_DES. The AUTH_KERB4 mechanism uses DES encryption with Kerberos authentication. This mechanism is has also been called AUTH_KERB.

The NFS Administration Guide describes how to set up and administer Secure NFS. Setting up the NIS+ tables and entering names in the cred table are discussed in Solaris Naming Administration Guide. See "Implementation of Diffie-Hellman Authentication" for an outline of the steps involved in RPC authentication.

DES Encryption

The Data Encryption Standard (DES) encryption functions use a 56-bit key to encrypt a secret key. If two credential users (or principals) know the same DES key, they can communicate in private, using the key to encipher and decipher text. DES is a relatively fast encryption mechanism. A DES chip makes the encryption even faster; but if the chip is not present, a software implementation is substituted.

The risk of using just the DES key is that, with enough time, an intruder can collect enough cipher-text messages encrypted with the same key to be able to discover the key and decipher the messages. For this reason, security systems such as Secure NFS change the keys frequently.

Diffie-Hellman Authentication

The Diffie-Hellman method of authenticating a user is non-trivial for an intruder to crack. The client and the server each has its own private key (sometimes called a secret key) which they use together with the public key to devise a common key. They use the common key to communicate with each other, using an agreed-upon encryption/decryption function (such as DES). This method was identified as DES authentication in previous Solaris releases.

Authentication is based on the ability of the sending system to use the common key to encrypt the current time, which the receiving system can decrypt and check against its current time. Make sure you synchronize the time on the client and the server.

The public and private keys are stored in an NIS or NIS+ database. NIS stores the keys in the publickey map, and NIS+ stores the keys in the cred table. These files contain the public key and the private key for all potential users.

The system administrator is responsible for setting up NIS or NIS+ tables and generating a public key and a private key for each user. The private key is stored encrypted with the user's password. This makes the private key known only to the user.

Implementation of Diffie-Hellman Authentication

This section describes the series of transactions in a client-server session using DH authorization (AUTH_DH).

Generating the Public and Secret Keys

Sometime prior to a transaction, the administrator runs either the newkey or nisaddcred commands that generates a public key and a secret key. (Each user has a unique public key and secret key.) The public key is stored in a public database; the secret key is stored in encrypted form in the same database. To change the key pair, use the chkey command.

Running the keylogin Command

Normally, the login password is identical to the secure RPC password. In this case, a keylogin is not required. If the passwords are different, the users have to log in, and then do a keylogin explicitly.

The keylogin program prompts the user for a secure RPC password and uses the password to decrypt the secret key. The keylogin program then passes the decrypted secret key to a program called the keyserver. (The keyserver is an RPC service with a local instance on every computer.) The keyserver saves the decrypted secret key and waits for the user to initiate a secure RPC transaction with a server.

If the passwords are the same, the login process passes the secret key to the keyserver. If the passwords are required to be different and the user must always run keylogin, then the keylogin program may be included in the user's environment configuration file, such as ~/.login, ~/.cshrc, or ~/.profile, so that it runs automatically whenever the user logs in.

Generating the Conversation Key

When the user initiates a transaction with a server:

  1. The keyserver randomly generates a conversation key.

  2. The kernel uses the conversation key to encrypt the client's time stamp (among other things).

  3. The keyserver looks up the server's public key in the public-key database (see the publickey(4) man page).

  4. The keyserver uses the client's secret key and the server's public key to create a common key.

  5. The keyserver encrypts the conversation key with the common key.

First Contact with the Server

The transmission including the encrypted time stamp and the encrypted conversation key is then sent to the server. The transmission includes a credential and a verifier. The credential contains three components:

The window is the difference the client says should be allowed between the server's clock and the client's time stamp. If the difference between the server's clock and the time stamp is greater than the window, the server would reject the client's request. Under normal circumstances this will not happen because the client first synchronizes with the server before starting the RPC session.

The client's verifier contains:

The window verifier is needed in case somebody wants to impersonate a user and writes a program that, instead of filling in the encrypted fields of the credential and verifier, just stuffs in random bits. The server will decrypt the conversation key into some random key and use it to try to decrypt the window and the time stamp. The result will be random numbers. After a few thousand trials, however, there is a good chance that the random window/time stamp pair will pass the authentication system. The window verifier makes guessing the right credential much more difficult.

Decrypting the Conversation Key

When the server receives the transmission from the client:

  1. The keyserver local to the server looks up the client's public key in the publickey database.

  2. The keyserver uses the client's public key and the server's secret key to deduce the common key--the same common key computed by the client. (Only the server and the client can calculate the common key because doing so requires knowing one secret key or the other.)

  3. The kernel uses the common key to decrypt the conversation key.

  4. The kernel calls the keyserver to decrypt the client's time stamp with the decrypted conversation key.

Storing Information on the Server

After the server decrypts the client's time stamp, it stores four items of information in a credential table:

The server stores the first three items for future use. It stores the time stamp to protect against replays. The server accepts only time stamps that are chronologically greater than the last one seen, so any replayed transactions are guaranteed to be rejected.

Note -

Implicit in these procedures is the name of the caller, who must be authenticated in some manner. The keyserver cannot use DES authentication to do this because it would create a deadlock. To solve this problem, the keyserver stores the secret keys by UID and grants requests only to local root processes.

Verifier Returned to the Client

The server returns a verifier to the client, which includes:

The reason for subtracting 1 from the time stamp is to ensure that the time stamp is invalid and cannot be reused as a client verifier.

Client Authenticates the Server

The client receives the verifier and authenticates the server. The client knows that only the server could have sent the verifier because only the server knows what time stamp the client sent.

Additional Transactions

With every transaction after the first, the client returns the index ID to the server in its second transaction and sends another encrypted time stamp. The server sends back the client's time stamp minus 1, encrypted by the conversation key.

Kerberos Version 4

Kerberos is an authentication system that was developed at the Massachusetts Institute of Technology. Kerberos uses DES encryption to authenticate a user when logging in to the system. Authentication is based on the ability of the sending system to use the common key to encrypt the current time, which the receiving system can decrypt and check against its current time. Kerberos Version 4 is supported in the Solaris 2.6 release.

Kerberos works by authenticating the user's login password. A user enters the kinit command, which acquires a ticket that is valid for the time of the session (or eight hours, the default session time) from the Kerberos authentication server. When the user logs out, the ticket can be destroyed (using the kdestroy command).

The Kerberos software is available from MIT project Athena, and is not part of the SunOS 5.x software. SunOS 5.x software provides:

"Implementation of Kerberos Authentication with NFS" gives an overview of how the Kerberos authentication procedure works.

Note -

Solaris provides the ability to connect to the Kerberos functionality. It does not provide the Kerberos package. However, you can ftp Kerberos 4 source from athena-dist.mit.edu using anonymous as a username and your email address as a password. The source is located in the pub/kerberos directory.

Implementation of Kerberos Authentication with NFS

The following process assumes that the Kerberos key distribution center (KDC) is already installed on the network, using publicly available sources from MIT project Athena.

  1. The /usr/sbin/kerbd daemon must be running on the NFS client and server.

    This daemon is normally started when needed by inetd. The rpcinfo command can be used to make sure that the kerbd service is registered. kerbd is the user-mode daemon. It interfaces with the kernel RPC and the KDC. It generates and validates authentication tickets.

  2. The system administrator sets up the NFS server to use Kerberos authentication.

    The MIT Kerberos software is used to register the principal names in the Kerberos key distribution center (KDC) on the Kerberos server. The following entries are required:

    • root.hostname (required for each NFS client)

    • nfs.hostname (required for each NFS server)

  3. The user mounts the shared file system.

    The user on the client must get a ticket for root on the client to mount the shared file system.

  4. The user logs in to the Kerberos service, using the kinit command.

    The Kerberos authentication server authenticates the request, and grants a ticket for the ticket-granting service.

  5. The user accesses the mounted directory.

    The kerbd daemon automatically secures a ticket on behalf of the client for the NFS server exporting the file system. At this point, there are two valid tickets, the original ticket-granting ticket and one for the server.

  6. The user destroys the tickets at the end of the session to prevent them from being compromised.

    The kdestroy command destroys the user's active Kerberos authorization tickets by writing zeros to the file that contains the tickets. You can put the kdestroy command in your .logout file, so that all Kerberos tickets are automatically destroyed when you log out of the system.

  7. If tickets have been destroyed before the session has finished, the user must request a new ticket with the kinit command.

Administering Diffie-Hellman Authentication

A system administrator can implement policies that help secure the network. The level of security required will differ with each site. This section provides instructions for some tasks associated with network security.

How to Restart the Keyserver

  1. Become superuser.

  2. Verify that the keyserv daemon (the keyserver) is not running. 


    # ps -ef | grep keyserv
root  100 		   1		 16	  Apr 11 ?			   0:00 /usr/sbin/keyserv
root	2215   2211			 5  09:57:28 pts/0 0:00 grep keyserv

  3. Start the keyserver if it isn't running. 


    # /usr/sbin/keyserv

How to Set Up NIS+ Credentials for Diffie-Hellman Authentication

For detailed description of NIS+ security, see Solaris Naming Administration Guide.

To set up a new key for root on an NIS+ client:

  1. Become superuser.

  2. Edit the /etc/nsswitch.conf file and add the following line:


    publickey: nisplus

  3. Initialize the NIS+ client.


    # nisinit -cH hostname

    hostname is the name of a trusted NIS+ server that contains an entry in its tables for the client machine.

  4. Add the client to the cred table by typing the following commands. 


    # nisaddcred local
# nisaddcred des

  5. Verify the setup by using the keylogin command.

    If you are prompted for a password, the procedure has succeeded.

Example of Setting Up a New Key for root on a NIS+ Client

The following example uses the host pluto to set up earth as an NIS+ client. You can ignore the warnings. The keylogin command is accepted, verifying that earth is correctly set up as a secure NIS+ client. 


# nisinit -cH pluto
NIS Server/Client setup utility.
This machine is in the North.Abc.COM. directory.
Setting up NIS+ client ...
All done.
# nisaddcred local
# nisaddcred des 
DES principal name : unix.earth@North.Abc.COM
Adding new key for unix.earth@North.Abc.Com (earth.North.Abc.COM.)
 
Network password: xxx <Press Return>
Warning, password differs from login password.
Retype password: xxx <Press Return>
 
# keylogin
Password:
#

To set up a new key for an NIS+ user:

  1. Add the user to the cred table on the root master server by typing the following command: 


    # nisaddcred -p unix.UID@domainname -P username.domainname. des

    Note that, in this case, the username-domainname must end with a dot (.)

  2. Verify the setup by logging in as the client and typing the keylogin command.

Example of Setting Up a New Key for an NIS+ User

The following example gives DES security authorization to user george.


# nisaddcred -p unix.1234@North.Abc.com -P george.North.Abc.COM. des
DES principal name : unix.1234@North.Abc.COM
Adding new key for unix.1234@North.Abc.COM (george.North.Abc.COM.)
 
Password:
Retype password:
 
# rlogin rootmaster -l george
# keylogin
Password:
#

How to Set Up NIS Credentials with Diffie-Hellman Authentication

To create a new key for sueruser on a client:

  1. Become superuser on the client.

  2. Edit the /etc/nsswitch.conf file and add the following line:


    publickey: nis

  3. Create a new key pair by using the newkey command.


    # newkey -h hostname

    hostname is the name of the client.

Example of Setting Up an NIS+ Client to Use Diffie-Hellman Security

The following example sets up earth as a secure NIS client.


# newkey -h earth
Adding new key for unix.earth@North.Abc.COM
New Password:
Retype password:
Please wait for the database to get updated...
Your new key has been successfully stored away.
#

To create a new key for a user:

  1. Log in to the server as superuser.

    Only the system administrator, logged in to the NIS+ server, can generate a new key for a user.

  2. Create a new key for a user.


    # newkey -u username

    username is the name of the user. The system prompts for a password. The system administrator can type a generic password. The private key is stored encrypted with the generic password.


    # newkey -u george
Adding new key for unix.12345@Abc.North.Acme.COM
New Password:
Retype password:
Please wait for the database to get updated...
Your new key has been successfully stored away.
#

  3. Tell the user to log in and type the chkey -p command.

    This allows the user to re-encrypt their private key with a password known only to the user. 


    earth% chkey -p
Updating nis publickey database.
Reencrypting key for unix.12345@Abc.North.Acme.COM
Please enter the Secure-RPC password for george:
Please enter the login password for george:
Sending key change request to pluto...
#
    Note -

    The chkey command can be used to create a new key-pair for a user.

How to Share and Mount Files With Diffie-Hellman Authentication

Prerequisite

The Diffie-Hellman publickey authentication must be enabled on the network. See "How to Set Up NIS+ Credentials for Diffie-Hellman Authentication", and "How to Set Up NIS Credentials with Diffie-Hellman Authentication".

To share a file system with Diffie-Hellman authentication:

  1. Become superuser.

  2. Share the file system with Diffie-Hellman authentication. 


    # share -F nfs -o sec=dh /filesystem
To mount a file system with Diffie-Hellman authentication:

  1. Become superuser.

  2. Mount the file system with Diffie-Hellman authentication.


    # mount -F nfs -o sec=dh server:resource  mountpoint

    The -o sec=dh option mounts the file system with AUTH_DH authentication.

Administering Kerberos Version 4 Authentication

A system administrator can implement policies that help secure the network. The level of security required will differ with each site. This section provides instructions for some tasks associated with network security.

How to Share and Mount Files With Kerberos Authentication

Prerequisite

Kerberos Version 4 authentication must be enabled on the network.

To share a file system with Kerberos authentication:

  1. Become superuser.

  2. Share the file system with Kerberos authentication. 


    # share -F nfs -o sec=krb4 /filesystem
To mount a file system with Kerberos authentication:

  1. Become superuser.

  2. Mount the file system with Kerberos authentication.


    # mount -F nfs -o sec=krb4 server:resource mountpoint

    The -o sec=krb4 option mounts the file system with AUTH_KERB authentication.

How to Acquire a Kerberos Ticket for Superuser on a Client

If the NFS file system that you need to access has not been mounted, you need to acquire a ticket for superuser on the client before mounting it.

To acquire a ticket for a not-yet-mounted file system:

  1. Become superuser.

  2. Acquire a Kerberos ticket on the client.


    # kinit root.hostname

    hostname is the name of the client system.


    # kinit root.earth
Password:
#
To acquire a ticket for a mounted file system:

If the entry root.hostname for the client has been entered into the /etc/srvtab configuration file, you can use the ksrvtgt command to get a ticket for superuser. In this case, you are not required to give a superuser password. Consult the MIT documentation for information about initializing the /etc/srvtab file.

  1. Become superuser.

  2. Acquire a ticket for a mounted file system. 


    # ksrvtgt root.hostname

Example--Acquiring a Kerberos Ticket for Superuser on a Client


# ksrvtgt root.earth
#

How to Log In to Kerberos Service

Log in to the Kerberos service by using the kinit -l username command. 


earth% kinit -l username

The kinit command prompts you for the ticket lifetime (-l option), and your password. It prints out ticket status using the verbose mode (-v option).

Example of Logging In to Kerberos Service


earth% kinit -l jjones
SunOS (earth)
Kerberos Initialization for "jjones"
Kerberos ticket lifetime (minutes): 480
Password:
earth%

How to List Kerberos Tickets


earth% klist

Example of Listing Kerberos Tickets


earth% klist
Ticket file: /tmp/tkt8516
Principal: jjones@North.Abc.COM
  Issued            Expires          Principal
  Jan 14 20:40:54   Jan
15:04:40:54  krbtgt.North.Abc.COM@North.Abc.COM

How to Access a Directory With Kerberos Authentication

Type cd /mountpoint.

Access the mounted directory, just as you would any other mounted directory. You can list the files in the directory with the ls command, or list the Kerberos tickets with the klist command.

Example of Accessing a Directory With Kerberos Authentication

In the following example, user jjones can change to the mounted mntkrb directory and list the files in this directory.

The kerbd daemon has automatically secured a ticket on the user's behalf for the NFS server exporting the file system. At this point there are two valid tickets--the original ticket-granting ticket, and the server ticket. These two tickets are listed by klist.


earth% cd /mntkrb
earth% ls -l /mntkrb
-rw-r--r-- 1 marks  staff  29 Jul 14 12:22 sports
drwxr-xr-x 3 jjones staff 512 Sep 13 13:44 market
 
earth% klist
Ticket file: /tmp/tkt8516
Principal: jjones@North.Abc.COM
  Issued            Expires          Principal
  Jan 14 20:40:54   Jan
15:04:40:54  krbtgt.North.Abc.COM@North.Abc.COM
  Jan 14 20:43:21   Jan 15:04:43:21  nfs.pluto@North.Abc.COM

How to Destroy a Kerberos Ticket

Enter kdestroy.

Destroy Kerberos tickets when the session is over, so that an unauthorized user cannot to gain access to it. If you want to reinitiate Kerberos authentication, use the kinit command.

Example of Destroying a Kerberos Ticket

The following example shows how to destroy the Kerberos ticket. If the user then tries to change to or list a Kerberos-protected directory, the ticket server denies access.


earth% kdestroy
Tickets destroyed
earth% ls /mntkrb
Can't get Kerberos key: No ticket file (tf_util)
NFS getattr failed for server pluto: RPC: Authentication error
can not access directory /mntkrb.

Introduction to PAM

The Pluggable Authentication Module (PAM) framework lets you "plug in" new authentication technologies without changing system entry services such as login, ftp, telnet, and so on. You can also use PAM to integrate UNIX login with other security mechanisms like DCE or Kerberos. Mechanisms for account, session, and password management can also be "plugged-in" using this framework.

Benefits of Using PAM

The PAM framework allows a system administrator to choose any combination of system entry services (ftp, login, telnet, or rsh, for example) for user authentication. Some of the benefits PAM provides are:

Overview of PAM

PAM employs run-time pluggable modules to provide authentication for system entry services. These modules are broken into four different types based on their function: authentication, account management, session management, and password management. A stacking feature is provided to let you authenticate users through multiple services, as well as a password-mapping feature to not require that users remember multiple passwords.

PAM Module Types

It is important to understand the PAM module types because the module type defines the interface to the module. These are the four types of run-time PAM modules:

Stacking Feature

The PAM framework provides a method for authenticating users with multiple services using stacking. Depending on the configuration, the user can be prompted for passwords for each authentication method. The order in which the authentication services are used is determined through the PAM configuration file.

Password-Mapping Feature

The stacking method can require that a user remember several passwords. With the password-mapping feature, the primary password is used to decrypt the other passwords, so the user doesn't need to remember or enter multiple passwords. The other option is to synchronize the passwords across each authentication mechanism. Note that this could increase the security risk, since the security of each mechanism is limited by the least secure password method used in the stack.

PAM Functionality

The PAM software consists of a library, several modules, and a configuration file. New versions of several system entry commands or daemons which take advantage of the PAM interfaces are also included.

Figure 53-1 illustrates the relationship between the applications, the PAM library, the pam.conf file, and the PAM modules.

Figure 53-1 How PAM Works

Graphic

The applications (ftp, telnet, and login) use the PAM library to access the appropriate module. The pam.conf file defines which modules to use, and in what order they are to be used with each application. Responses from the modules are passed back through the library to the application.

The following sections describe this relationship.

PAM Library

The PAM library, /usr/lib/libpam, provides the framework to load the appropriate modules and manage the stacking process. It provides a generic structure to which all of the modules can plug in.

PAM Modules

Each PAM module implements a specific mechanism. When setting up PAM authentication, you need to specify both the module and the module type, which defines what the module will do. More than one module type (auth, account, session, or password) may be associated with each module.

The following list describes each of the PAM modules.

PAM Configuration File

The PAM configuration file, /etc/pam.conf, determines the authentication services to be used, and in what order they are used. This file can be edited to select authentication mechanisms for each system-entry application.

Configuration File Syntax

The PAM configuration file consists of entries with the following syntax:


service_name module_type control_flag module_path module_options

service_name

Name of the service (for example, ftp, login, telnet).

module_type

Module type for the service. 

control_flag

Determines the continuation or failure semantics for the module. 

module_path

Path to the library object that implements the service functionality. 

module_options

Specific options that are passed to the service modules. 

You can add comments to the pam.conf file by starting the line with a # (pound sign). Use white space to delimit the fields.

Note -

An entry in the PAM configuration file is ignored if one of the following conditions exist: the line has less than four fields, an invalid value is given for module_type or control_flag, or the named module is not found.

Valid Service Names

Table 53-1 lists some of the valid service names, the module types that can be used with that service, and the daemon or command associated with the service name.

There are several module types that are not appropriate for each service. For example, the -password module type is only specified to go with the passwd command. There is no -auth module type associated with this command since it is not concerned with authentication.

Table 53-1 Valid Service Names for /etc/pam.conf

Service Name 

Daemon or Command 

Module Type 

dtlogin

/usr/dt/bin/dtlogin

auth, account, session

ftp

/usr/sbin/in.ftpd

auth, account, session

init

/usr/sbin/init

session

login

/usr/bin/login

auth, account, session

passwd

/usr/bin/passwd

password

rexd

/usr/sbin/rpc.rexd

auth

rlogin

/usr/sbin/in.rlogind

auth, account, session

rsh

/usr/sbin/in.rshd

auth, account, session

sac

/usr/lib/saf/sac

session

su

/usr/bin/su

>>auth, account, session

telnet

/usr/sbin/in.telnetd

auth, account, session

ttymon

/usr/lib/saf/ttymon

session

uucp

/usr/sbin/in.uucpd

auth, account, session

Control Flags

To determine continuation or failure behavior from a module during the authentication process, you must select one of four control flags for each entry. The control flags indicate how a successful or a failed attempt through each module are handled. Even though these flags apply to all module types, the following explanation assumes that these flags are being used for authentication modules. The control flags are as follows:

Generic pam.conf File

The following is an example of a generic pam.conf file:


# PAM configuration
# Authentication management
#
login	auth	required	/usr/lib/security/pam_unix.so.1
login	auth	required	/usr/lib/security/pam_dial_auth.so.1
rlogin	auth	sufficient	/usr/lib/security/pam_rhost_auth.so.1
rlogin	auth	required	/usr/lib/security/pam_unix.so.1
dtlogin	auth	required	/usr/lib/security/pam_unix.so.1
telnet	auth	required	/usr/lib/security/pam_unix.so.1
su	auth	required	/usr/lib/security/pam_unix.so.1
ftp	auth	required	/usr/lib/security/pam_unix.so.1
uucp	auth	required	/usr/lib/security/pam_unix.so.1
rsh	auth	required	/usr/lib/security/pam_rhost_auth.so.1
OTHER	auth	required	/usr/lib/security/pam_unix.so.1
#
# Account management
#
login	account	required	/usr/lib/security/pam_unix.so.1
rlogin	account	required	/usr/lib/security/pam_unix.so.1
dtlogin	account	required	/usr/lib/security/pam_unix.so.1
telnet	account	required	/usr/lib/security/pam_unix.so.1
ftp	account	required	/usr/lib/security/pam_unix.so.1
OTHER	account	required	/usr/lib/security/pam_unix.so.1
#
# Session management
#
login	session	required	/usr/lib/security/pam_unix.so.1
rlogin	session	required	/usr/lib/security/pam_unix.so.1
dtlogin	session	required	/usr/lib/security/pam_unix.so.1
telnet	session	required	/usr/lib/security/pam_unix.so.1
uucp	session	required	/usr/lib/security/pam_unix.so.1
OTHER	session	required	/usr/lib/security/pam_unix.so.1
#
# Password management
#
passwd	password	required	/usr/lib/security/pam_unix.so.1
OTHER	password	required	/usr/lib/security/pam_unix.so.1

This generic pam.conf file specifies:

  1. When running login, authentication must succeed for both the pam_unix and the pam_dial_auth modules.

  2. For rlogin, authentication through the pam_unix module must succeed, if authentication through pam_rhost_auth fails.

  3. The sufficient control flag indicates that for rlogin the successful authentication provided by the pam_rhost_auth module is sufficient and the next entry will be ignored.

  4. Most of the other commands requiring authentication require successful authentication through the pam_unix module.

  5. Authentication for rsh must succeed through the pam_rhost_auth module.

The OTHER service name allows a default to be set for any other commands requiring authentication that are not included in the file. The OTHER option makes it easier to administer the file, since many commands that are using the same module can be covered using only one entry. Also, the OTHER service name, when used as a "catch-all," can ensure that each access is covered by one module. By convention, the OTHER entry is included at the bottom of the section for each module type.

The rest of the entries in the file control the account, session and password management.

With the use of the default service name, OTHER, the generic PAM configuration file is simplified to: 


# PAM configuration
#
# Authentication management
#
login	auth	required	/usr/lib/security/pam_unix.so.1
login	auth	required	/usr/lib/scurty/pam_dial_auth.so.1
rlogin	auth	sufficient	/usr/lib/security/pam_unix.so.1
rlogin	auth	required	/usr/lib/security/pam_rhost_auth.so.1
rsh	auth	required	/usr/lib/security/pam_rhost_auth.so.1
OTHER	auth	required	/usr/lib/security/pam_unix.so.1
#
# Account management
#
OTHER	account	required	/usr/lib/security/pam_unix.so.1
#
# Session management
#
OTHER	session	required	/usr/lib/security/pam_unix.so.1
#
# Password management
#
OTHER	password	required	/usr/lib/security/pam_unix.so.1

Normally, the entry for the module_path is "root-relative." If the filename you enter for module_path does not begin with a slash (/), the path /usr/lib/security/ is prepended to the filename. A full pathname must be used for modules located in other directories.

The values for the module_options can be found in the man pages for the module (for example, pam_unix(5)).

The use_first_pass and try_first_pass options, which are supported by the pam_unix module, let users reuse the same password for authentication without retyping it.

If login specifies authentication through both pam_local and pam_unix, then the user is prompted to enter a password for each module. In situations where the passwords are the same, the use_first_pass module option prompts for only one password and uses that password to authenticate the user for both modules. If the passwords are different, the authentication fails. In general, this option should be used with an optional control flag, as shown below, to make sure that the user can still log in.


# Authentication management
#
login	auth	required	/usr/lib/security/pam_unix.so.1
login	auth	optional	/usr/lib/security/pam_local.so.1	use_first_pass

If the try_first_pass module option is used instead, the local module prompts for a second password if the passwords do not match or if an error is made. If both methods of authentication are necessary for a user to get access to all the tools they need, using this option could cause some confusion for the user since the user could get access with only one type of authentication.

Configuring PAM

The section below discusses some of the tasks that may be required to make the PAM framework fully functional. In particular, you should be aware of some of the security issues associated with the PAM configuration file.

Planning for PAM

When deciding how best to employ PAM in your environment, start by focusing on these issues:

How to Add a PAM Module

  1. Become superuser.

  2. Determine which control flags and other options should be used.

    Refer to "PAM Modules" information on the module.

  3. Copy the new module to /usr/lib/security.

  4. Set the permissions so that the module file is owned by root and permissions are 555.

  5. Edit the PAM configuration file, /etc/pam.conf, and add this module to the appropriate services.

Verification

It is very important to do some testing before the system is rebooted in case the configuration file is misconfigured. Run rlogin, su, and telnet before rebooting the system. If the service is a daemon spawned only once when the system is booted, it may be necessary to reboot the system before you can verify that the module has been added.

How to Prevent Unauthorized Access from Remote Systems with PAM

Remove the rlogin auth rhosts_auth.so.1 entry from the PAM configuration file. This prevents reading the ~/.rhosts files during an rlogin session and therefore prevents unauthenticated access to the local system from remote systems. All rlogin access requires a password, regardless of the presence or contents of any ~/.rhosts or /etc/hosts.equiv files.

Note -

To prevent other unauthenticated access to the ~/.rhosts files, remember to disable the rsh service. The best way to disable a service is to remove the service entry from /etc/inetd.conf. Changing the PAM configuration file does not prevent the service from being started.

How to Initiate PAM Error Reporting

  1. Edit the /etc/syslog.conf to add any of the following PAM error reporting entries:

    • auth.alert -- messages about conditions that should be fixed immediately

    • auth.crit -- critical messages

    • auth.err -- error messages

    • auth.info -- informational messages

    • auth.debug -- debugging messages

  2. Restart the syslog daemon or send a SIGHUP signal to it to activate the PAM error reporting.

Example--Initiating PAM Error Reporting

The example below displays all alert messages on the console. Critical messages are mailed to root. Informational and debug messages are added to the /var/log/pamlog file.


auth.alert	/dev/console
auth.crit	'root'
auth.info;auth.debug	/var/log/pamlog

Each line in the log contains a time stamp, the name of the system that generated the message, and the message itself. The pamlog file is capable of logging a large amount of information.