Target Skills

By the end of this module you will be able to...

  • Generate an appropriate password policy for the Server.
  • Managing Passwords


    The Directory Server provides several security mechanisms to help you protect your directory data. Perhaps the most fundamental security mechanism is password protection. However, because password protection is so fundamental, it is often given little thought. Yet it is a weak password policy that makes your directory most vulnerable to break-ins. 

    Password Policies

    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 the minimum length 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 binding the user to the directory. 

    Specifically, the password policy defines:

    • The length of time a given password is valid
    • How many days before their passwords expire that users are warned
    • Whether users can reuse passwords
    • How many characters the password must contain
    • Whether the password syntax is checked before the password is saved
    • Whether users are allowed to change their own passwords
    • Whether passwords must be changed after they are reset by the administrator
    • Whether users will be locked out of the directory after a given number of failed bind attempts
    • How long users will be locked out of the directory after a given number of failed bind attempts
    • The length of time before the password counter is reset
    • The encryption method used to store user passwords in the directory tree

    •  

       
       
       
       
       

    Password Expiration

    You can set your password policy such that users can use the same passwords indefinitely. In this case, the passwords never expire. Or, you can set your policy so that passwords expire every 1 to 24855 days. 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. 

    Note that the password expiration time is remembered 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 reenable password expiration, the default password expiration duration is 90 days because that is what you had it set to before you disabled the feature.

    Expiration Warning
    If you choose to set your password policy so that user passwords expire after a given number of days, it may also be 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 24855 days before their passwords are due to expire. The Directory Server displays the warning when the user binds to the server. 

    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. 

    Password history refers to whether users are allowed 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. 

    Note that 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. 

    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 6 or 7 characters. This is long enough to be difficult to crack, but short enough that users can remember the password without writing it down. 

    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 one of the following "trivial" words:

    • the user ID
    • the user's first or last name
    • any attribute value stored in the user's directory entry
    • a string comprised of a single letter or digit
    By default, password syntax checking is turned off.

    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. 

    Password Change After Reset
    The Directory Server password policy lets you decide whether users must change their passwords after the first log in 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. Of course, if you chose to disallow users from changing their own passwords, administrator assigned passwords should not follow any obvious convention and should be difficult to discover. 

    Account Lockout
    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 in to 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. 

    Note that the account lockout policy is remembered 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 reenable 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. 

    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 so that users are locked 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. 

    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. 

    The account lockout feature protects against hackers who try to break into the directory by repeatedly trying to guess a user's password. Each time an invalid password is sent from the user's account, the password 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. 
     

    Password Storage Scheme

    The password storage scheme specifies the type of encryption used to store Directory Server passwords within the directory. You can specify:
    • No encryption
    • SHA (Secure Hash Algorithm)
    • crypt (UNIX crypt algorithm)
    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. 
     

    Produced By Netscape Learning.  Copyright © 1998 Netscape Communications, Inc.