How to Specify a New Password Algorithm for an LDAP Domain

When the LDAP client is properly configured, the LDAP client can use the new password algorithms. The LDAP client behaves just as a NIS client behaves.

1. Specify a password encryption algorithm in the /etc/security/policy.conf file on the LDAP client.

2. Copy the modified policy.conf file to every client machine in the LDAP domain.

3. Ensure that the client's /etc/pam.conf file does not use a pam_ldap module.

   Ensure that a comment sign (#) precedes entries that include pam_ldap.so.1. Also, do not use the new server_policy option with the pam_authtok_store.so.1 module.

The PAM entries in the client's pam.conf file enable the password to be encrypted according to the local algorithms configuration, and enable the password to be authenticated.

When users in the LDAP domain change their passwords, the LDAP client consults its local algorithms configuration in the /etc/security/policy.conf file. The LDAP client machine encrypts the password. The client sends the encrypted password, with a {crypt} tag, to the server. The tag tells the server that the password is already encrypted. The password is then stored, as is, on the server. For authentication, the client retrieves the stored password from the server. The client then compares the stored password with the encrypted version that the client has just generated from the user's typed password.

Note - To take advantage of password policy controls on the LDAP server, use the server_policy option with the pam_authtok_store entries in the pam.conf file. Passwords are then encrypted on the server by using the Sun ONE Directory Server's cryptographic mechanism. For the procedure, see "Setting Up Clients (Task)" in System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP).

How to Install a Password Encryption Module From a Third Party

A third-party password encryption algorithm is typically delivered as part of a software package. When you run the pkgadd command, scripts from the vendor should modify the /etc/security/crypt.conf file. You then modify the /etc/security/policy.conf file to include the new module and its identifier.

1. Add the software by using the pkgadd command.

   For detailed instructions on how to add software, see "Adding or Removing a Software Package" in System Administration Guide: Basic Administration.

2. Read the /etc/security/crypt.conf file to confirm that the new module and module identifier are in the list of encryption algorithms.

   For example, the following lines show a crypt.conf file that was modified by a package that installed the crypt_rot13 algorithm.

   # crypt.conf # md5 /usr/lib/security/$ISA/crypt_md5.so rot13 /usr/lib/security/$ISA/crypt_rot13.so # For *BSD - Linux compatibility # 1 is MD5, 2a is Blowfish 1 /usr/lib/security/$ISA/crypt_bsdmd5.so 2a /usr/lib/security/$ISA/crypt_bsdbf.so

   
   

3. Modify the /etc/security/policy.conf file to add the identifier of the newly installed algorithm.

   The following lines show excerpts from the policy.conf file that would need to be modified to add the rot13 identifier.

   # Copyright 1999-2002 Sun Microsystems, Inc. All rights reserved. # ... #ident "@(#)policy.conf 1.6 02/06/07 SMI" # ... # crypt(3c) Algorithms Configuration CRYPT_ALGORITHMS_ALLOW=1,2a,md5,rot13 #CRYPT_ALGORITHMS_DEPRECATE=__unix__ CRYPT_DEFAULT=md5

   
   

In this example, the rot13 algorithm is used if the current password was encrypted with the crypt_rot13 algorithm. New user passwords are encrypted with the crypt_sunmd5 algorithm. This algorithms configuration works on Solaris-only networks.

Monitoring and Restricting Superuser

An alternative to using the superuser account is to set up role-based access control. Role-based access control is called RBAC. For overview information on RBAC, see Chapter 5, Role-Based Access Control (Overview). For how to set up RBAC, see Chapter 6, Role-Based Access Control (Tasks).

How to Monitor Who Is Using the su Command

The sulog file lists every use of the su command, not only the su attempts that are used to switch from user to superuser.

1. Become superuser or assume an equivalent role.

2. Monitor the contents of the /var/adm/sulog file on a regular basis.

   # more /var/adm/sulog SU 12/20 16:26 + pts/0 nathan-root SU 12/21 10:59 + pts/0 nathan-root SU 01/12 11:11 + pts/0 root-janedoe SU 01/12 14:56 + pts/0 pmorph-root SU 01/12 14:57 + pts/0 pmorph-root

   
   

   The entries display the following information:

   • The date and time that the command was entered

   • If the attempt was successful

     A + indicates a successful attempt. A - indicates an unsuccessful attempt.

   • The port from which the command was issued

   • The name of the user and the name of the switched identity

   The su logging in this file is enabled by default through the following entry in the /etc/default/su file:

   SULOG=/var/adm/sulog

   
   

How to Display Superuser (root) Access Attempts to the Console

1. Become superuser or assume an equivalent role.

2. Edit the /etc/default/su file.

3. Uncomment the following line:

   CONSOLE=/dev/console

   
   

4. Use the su command to become root.

   Verify that a message is printed on the system console.

   This method immediately detects someone who is trying to gain superuser access to the system that you are on.

How to Prevent Remote Login by Superuser (root)

Note - Superuser login is restricted to the console by default when you install the Solaris release.

1. Become superuser or assume an equivalent role.

2. Edit the /etc/default/login file.

3. Uncomment the following line:

   CONSOLE=/dev/console

   
   

   When superuser access is restricted to the console, you can log in to a system as superuser only from the console. Any users who try to remotely log in to this system must first log in with their user login. After logging in with their user name, users then use the su command to become superuser.

4. Attempt to log in remotely as superuser to this system, and verify that the operation fails.