Previous Next Contents Index


Chapter 6 Managing Password and Account Lockout Policies

Netscape Directory Server provides several security mechanisms to help you protect your directory data. Two of the most fundamental security mechanisms are password protection and account lockouts. Weak password and account lockout policies make your directory more vulnerable to break-ins.

This chapter contains the following sections:

Other security mechanisms are described in Chapter  5, "Managing Access Control," and Chapter  11, "Managing SSL."


Managing the Password Policy
A password policy is a set of rules that govern how passwords are used in a given system. The password policy mechanism provided by the Directory Server allows you to dictate such things as how short a password must be and whether users can reuse passwords. When users attempt to bind to the directory, the Directory Server compares the password with the value in the password attribute of the user's directory entry to make sure they match. The Directory Server also uses the rules defined by the password policy to ensure that the password is valid before allowing the user to bind to the directory.

Configuring the Password Policy

Although you are not required to do so, Netscape recommends that you set an account lockout policy in addition to a password policy. (See  "Managing the Account Lockout Policy" for more information.)

The password policy you configure applies to all users within the directory except for the Directory Manager (Root DN).

To set up or modify the password policy for your Directory Server:

  1. On the Directory Server Console, select the Configuration tab and then the Database folder.
  2. The Database tabs appear in the right pane.

  3. Select the Passwords tab in the right pane.
  4. This tab contains the password policy for the Directory Server.

  5. You can specify that users must change their password the first time they log on by selecting the "User must change password after reset" checkbox.
  6. See "Password Change After Reset" for more information about this parameter.

  7. To specify that users can change their own passwords, select the "User May change password" checkbox.
  8. See  "User-Defined Passwords" for information on this parameter.

  9. If you want, you can specify that users cannot change their password for a specific amount of time by entering the number of days in the "Allow Changes in X Day(s)" text box.
  10. See "Password Minimum Age" for information on this parameter.

  11. To configure the server to maintain a history list of passwords used by each user, select the "Keep Password History" checkbox.
  12. See  "Password History" for more information about password history lists.

  13. If you configure the server to keep password histories, specify the number of passwords you want the server to keep for each user in the "Remember X Passwords" text box.
  14. If you do not want user passwords to expire, select the "Password never Expires" radio button.
  15. If you want users to have to change their passwords periodically, select the "Password Expires After X Days" radio button and then enter the number of days that a user password is valid.
  16. See  "Password Expiration" for information on this parameter.

  17. If you have turned password expiration on, you need to specify how long before the password expires to send a warning to the user by entering the number of days in the "Send Warning X Days Before Password Expires" text box.
  18. See  "Expiration Warning" for information on this parameters.

  19. If you want the server to check the syntax of a user password to make sure it meets the minimum requirements set by the password policy, select the "Check Password Syntax" checkbox.
  20. For more information about the type of syntax checking the server performs, see "Password Syntax Checking".

  21. If you turn password syntax checking on, you need to specify the minimum acceptable length in the "Password Minimum Length" text box.
  22. See  "Password Length" for more information on this parameter.

  23. Specify what encryption method you want the server to use when storing passwords from the "Password Encryption" pull-down menu.
  24. Specific information about each encryption method is provided in "Password Storage Scheme".

  25. When you have finished making changes to the password policy, click Save.
Password Policy Parameters

This section describes the parameters you set to create a password policy for your server. The parameters are described in the following sections:

Password Change After Reset

The Directory Server password policy lets you decide whether users must change their passwords after the first login or after the password is reset by the administrator. Often the initial passwords set by the administrator follow some sort of convention, such as the user's initials, user ID, or the company name. Once the convention is discovered, it is usually the first value tried by a hacker trying to break in. In this case, it is a good idea to require users to change their passwords after such a change. If you configure this option for your password policy, users will be required to change their password even if user-defined passwords are disabled. (See "User-Defined Passwords" for information.) If you choose to disallow users from changing their own passwords, administrator assigned passwords should not follow any obvious convention and should be difficult to discover.

By default, users do not need to change their passwords after reset.

User-Defined Passwords

You can set up your password policy to either allow or disallow users from changing their own passwords. A good password is the key to a strong password policy. Good passwords do not use trivial words—that is, any word that can be found in a dictionary, names of pets or children, birthdays, user IDs, or any other information about the user that can be easily discovered (or stored in the directory itself). Additionally, a good password should contain a combination of letters, numbers, and special characters. Often, however, users simply use passwords that are easy to remember. This is why some enterprises choose to set passwords for users that meet the criteria of a "good" password and disallow the users from changing the passwords. However, this approach requires a significant administrative effort. In addition, by providing passwords for users rather than letting them come up with passwords that are meaningful to them and therefore more easily remembered, you run the risk that they will write their passwords down somewhere where they can be discovered.

By default, user-defined passwords are allowed.

Password Expiration

You can set your password policy so that users can use the same passwords indefinitely. Or, you can set your policy so that passwords expire after a given amount of time. In general, the longer a password is in use, the more likely it is to be discovered. On the other hand, if passwords expire too often, users may have trouble remembering them and resort to writing their passwords down. A common policy is to have passwords expire every 30 to 90 days.

The server remembers the password expiration even if you turn the password expiration feature off. This means that if you turn the password expiration option back on, passwords will be valid only for the duration you had set before you last disabled the feature. For example, suppose you set up passwords to expire every 90 days and then decided to disable password expiration. When you decide to re-enable password expiration, the default password expiration duration is 90 days because that is what you had it set to before you disabled the feature.

By default, user passwords never expire.

Expiration Warning

If you choose to set your password policy so that user passwords expire after a given number of days, it is a good idea to send users a warning before their passwords expire. You can set your policy so that users are sent a warning 1 to 24,855 days before their passwords are due to expire. The Directory Server displays the warning when the user binds to the server. If password expiration is turned on, by default, a warning will be sent (via LDAP message) to the user one day before the user's password expires, provided the user's client application supports this feature. Both Netscape Directory Express and the Netscape Directory Server Gateway provide this functionality.

Password Syntax Checking

The password policy establishes some syntax guidelines for password strings, such as the minimum password length guideline. The password syntax-checking mechanism ensures that the password strings conform to the password syntax guidelines established by the password policy. Additionally, the password syntax-checking mechanism also ensures that the password is not a "trivial" word. A trivial word is any value stored in the uid, cn, sn, givenName, ou, or mail attribute of the user's entry.

By default, password syntax checking is turned off.

Password Length

The Directory Server allows you to specify a minimum length for user passwords. In general, shorter passwords are easier to crack. You can require passwords that are from 2 to 512 characters. A good length for passwords is 8 characters. This is long enough to be difficult to crack, but short enough that users can remember the password without writing it down.

By default, no minimum password length is set.

Password Minimum Age

You can configure the Directory Server to disallow users from changing their passwords for a given period of time. You can use this feature in conjunction with the Password History parameter to discourage users from reusing old passwords. Setting the password minimum age parameter to 2 days, for example, prevents a user from repeatedly changing her password during a single session in order to cycle through the password history and reuse an old password once it is removed from the history list. You can specify any number from 0 to 24,855 days. A value of zero (0) indicates that the user can change the password immediately.

Password History

You can set up the Directory Server to store from 2 to 24 passwords in history, or, you can disable password history, thus allowing users to reuse passwords.

If you set up your password policy to enable password history, the directory stores a specific number of old passwords. If a user attempts to reuse one of the passwords the Directory Server has stored, the password will be rejected. This feature prevents users from reusing a couple of passwords that are easy to remember.

The passwords remain in history even if you turn the history feature off. This means that if you turn the password history option back on, users will not be able to reuse the passwords that were in history before you disabled password history.

The server does not maintain a password history by default.

Password Storage Scheme

The password storage scheme specifies the type of encryption used to store Directory Server passwords within the directory. You can specify

Although passwords stored in the directory can be protected through the use of access control information (ACI) instructions, it is still not a good idea to store cleartext passwords in the directory. SHA is the most secure of the choices and the one Netscape recommends. The crypt algorithm provides compatibility with Unix passwords.


Managing the Account Lockout Policy
The lockout policy works in conjunction with the password policy to provide further security. The account lockout feature protects against hackers who try to break into the directory by repeatedly trying to guess a user's password.

Configuring the Account Lockout Policy

Although you are not required to do so, Netscape recommends that you set a password policy in addition to an account lockout policy. (See  "Managing the Password Policy" for more information.)

To set up or modify the account lockout policy for your Directory Server:

  1. On the Directory Server Console, select the Configuration tab and then the Database folder.
  2. The Database tabs appear in the right pane.

  3. Select the Account Lockout tab in the right pane.
  4. To enable account lockout, select the "Accounts may be locked out" checkbox.
  5. For specific information on this parameter, see "Account Lockout". Clear this checkbox if you do not want to set an account lockout policy for the server.

  6. Enter the maximum number of allowed bind failures in the "Lockout Account After X Login Failures" text box. The server locks out users who exceed the limit you specify here.
  7. Enter the number of minutes you want the server to wait before resetting the bind failure counter to 0 in the "Reset Failure Counter After X Minutes" text box.
  8. For specific information about this parameter, see "Password Failure Counter Reset".

  9. Set the period of time you want users to be locked out of the directory.
  10. You can set it up so that users are locked out until their passwords are reset by the administrator by selecting the Lockout Forever radio button. Or, you can set it up so that users are locked out from 1 to 35,791,394 minutes by selecting the Lockout Duration radio button and entering the time in the available text box. For more information on this parameter, see "Lockout Duration".

  11. When you have finished making changes to the account lockout policy, click Save.
Account Lockout Policy Parameters

This section describes the parameters you set to create an account lockout policy for your server. The following parameters are described:

Account Lockout

You can choose not to lock users out regardless of the number of failed bind attempts. Alternatively, you can set up your policy to lock out users after 1 to 32,767 failed bind attempts.

Often when hackers are trying to break into a system, they will repeatedly try to guess a user's password. To prevent this type of attack, you can set up your password policy so that a specific user will be locked out of the directory after a given number of failed attempts to bind to the directory.

The server remembers the account lockout policy even if you turn the lockout feature off. This means that if you turn the account lockout option back on, users will by default be locked out after the number of failed bind attempts you had set before you last disabled account lockout. For example, suppose you set up account lockout so that users are locked out after 7 failed bind attempts and then decided to disable account lockout. If you decide to re-enable account lockout, the default number of failed bind attempts after which users are locked out is 7 because that is what you had it set to before you disabled the feature.

Password Failure Counter Reset

The Directory Server requires that you specify that the password failure counter be reset every 1 to 35,791,394 minutes.

Each time an invalid password is sent from the user's account, the password failure counter is incremented. When the counter reaches the number of tries specified by the account lockout parameter, the user will be locked out of the directory for the amount of time specified by the lockout duration parameter. Because the counter's purpose is to gauge when a hacker is trying to gain access to the system, the counter must continue for a period long enough to detect a hacker. However, if the counter was to increment indefinitely over days and weeks, valid users would probably be locked out inadvertently at some point.

Lockout Duration

If you enable account lockout, you can also set the period of time users will be locked out of the directory. You can set it up to lock users out until their passwords are reset by the administrator, or you can set it up so that users are locked out from 1 to 35,791,394 minutes.


Setting User Passwords
Because user passwords are stored in the directory, you can use whatever LDAP operation you normally use to update the directory to set or reset the user passwords.

For information on creating and modifying directory entries, see Chapter  9, "Managing Directory Entries."

You can also use the Users and Groups area of the Administration Server or the Directory Server gateway to set or reset user passwords. For information on how to use the Users and Groups area, see the online help that is available through the Administration Server. For information on how to use the gateway to create or modify directory entries, see the online help that is available through the gateway.

 

© Copyright 1999 Netscape Communications Corporation, a subsidiary of America Online, Inc. All Rights Reserved.