|
| Sun ONE Directory Server Administration Guide |
Chapter 7 User Account Management
When a user connects to your directory server, the user is authenticated and the directory can grant access rights and resource limits to the user depending upon the identity established during authentication.
This chapter describes tasks for user account management, including configuring the password and account lockout policy for your directory, inactivating accounts or groups of users so they cannot access the directory, and limiting system resources available to users depending upon their bind DNs.
Directory Server 5.2 introduces the individual password policy. You may define any number of different password policies and apply any one of them to a given user or group of users. This makes it much easier to control how different types of users may access the directory.
This chapter contains the following sections:
- Overview of Password Policies
- Configuring the Global Password Policy
- Managing Individual Password Policies
- Resetting User Passwords
- Inactivating and Activating Users and Roles
- Setting Individual Resource Limits
Overview of Password Policies
A secure password policy minimizes the risks associated with easily-guessed passwords by enforcing the following:
- Users must change their passwords according to a schedule.
- Users must provide non-trivial passwords.
- Accounts may be locked after a number of binds with the wrong password.
As of Directory Server 5.2, you may have both individual and global password policies. An individual password policy is defined by a subentry in the directory tree which is then referenced by user entries having that policy. If a user entry does not reference an individual policy, the global password policy in cn=PasswordPolicy,cn=config applies to it.
The following sections explain how to implement password policies and assign them to users and groups. For more information, see "Designing Your Password Policies" in Chapter 7 of the Sun ONE Directory Server Deployment Guide.
Preventing Dictionary-Style Attacks
In a dictionary-style attack, an intruder attempts to crack a password by repeatedly guessing the password until gaining authorization. The server provides three tools to counter such attacks:
- Password syntax checking verifies that a password does not match values of the uid, cn, sn, givenName, ou, or mail attributes of the user entry. The server will not allow a user to set a password if it matches one of these values. However, syntax checking does not thwart actual dictionary attacks, in which the intruder tries every word in /usr/dict/words, for example.
- A minimum password length ensures that the user cannot set a short password. Passwords with more characters are exponentially harder to guess or attempt all values. In Directory Server, you must enable password syntax checking and minimum length simultaneously.
- The account lockout mechanism prevents binding after a certain number of failed authentication attempts. The lockout may either be temporary or permanent, depending on how strict you wish to make your password policy.
Both will effectively prevent automated guessing of passwords. For example, if you allow five attempts and then lock the user account for five minutes, the intruder can make only one guess per minute, on average, and a poor typist is inconvenienced only momentarily. If the lock is permanent, the user's password must be reset manually by the Directory Manager.
Password Policies in a Replicated Environment
Both individual and the global password policies are replicated. As a result, you may define them on a master and allow replication to propagate the policy to replicated servers. All the attributes you set are replicated, as are operational attributes containing the password history (old passwords already used) and password expiration dates.
However, you should consider the following impact of password policies in a replicated environment:
- A user with an impending password expiration will receive a warning from every replica to which they bind before changing their password.
- When a user changes their password, it may take time for this information to be updated on all replicas. If a user changes a password and then immediately rebinds to one of the consumer replicas with the new password, the bind may fail until the replica receives the updated password.
- Each replica keeps separate, non-replicated account lockout counters. As a result, the lockout policy will be enforced on any single replica, but may be circumvented when a user attempts to bind to several replicas. For example, if you have 10 servers in the replication topology, and lock out is activated after three attempts, an intruder could potentially try 30 guesses of the password.
While replication does allow an intruder more guesses, the number is insignificant when compared to the billions of password values. It is much more important to force users to have strong passwords by turing on password checking and setting a password length of six characters or more. You should also give them guidelines on how to select and remember a password that is not a common dictionary word. Finally, you should ensure that all directory administrator users have very strong passwords.
Configuring the Global Password Policy
The global password policy applies to all users in the directory who do not have an individual policy defined. However, the global password policy does not apply to the Directory Manager.
Configuring the Password Policy Using the Console
To set up or modify the global password policy for your Directory Server:
- On the top-level Configuration tab of the Directory Server console, select the Data node, then select the Passwords tab in the right-hand panel.
- On the Passwords tab, set the following aspects of the policy:
- Specify that users must change their password the first time they log on by selecting the "User must change password after reset" checkbox.
If you select this checkbox, only the Directory Manager is authorized to reset the users's password. A regular administrative user cannot force the user to update their password.
- To allow users to change their own passwords, select the "User may change password" checkbox.
- To limit how often users may change their own password, enter the number of days in the "Allow changes in X day(s)" text box. To allow users to change their password as often as they desire, select the No Limitation checkbox.
- To prevent users from using the same password over and over, select the "Keep password history" checkbox and specify the number of passwords you want the server to keep for each user text box. Users will not be able to set a password that still exists in the list. To be effective, you should also limit how often users may change their password.
- If you do not want user passwords to expire, select the "Password never expires" radio button.
- Otherwise, select the "Password expires after X days" radio button to force users to periodically change their passwords, and then enter the number of days that a user password is valid.
- If you selected expiring passwords, you can specify how long before the password expires to send a warning to the user in the "Send warning X days before password expires" field.
When the user receives a warning, the password will expire on the original date. Deselect the "Expire regardless of warning" checkbox to extend the expiration to allow a full warning period after the warning is sent. Only one warning and one extension will occur. There is no grace login if the user binds after the password has expired.
- 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. Then, specify the minimum acceptable password length in the "Password minimum length" text box.
- By default, the Directory Manager cannot reset a password that violates the password policy, for example reusing a password in the history. Select the "Allow Directory Manager to bypass Password Policy" checkbox to allow this.
- Specify what encryption method you want the server to use when storing passwords from the "Password encryption" pull-down menu.
- Click on the Account Lockout tab and select the "Accounts may be locked out" checkbox to define the account lockout policy:
- Enter the number of login failures and the period in which they must occur to trigger a lockout.
- Select the Lockout forever radio button to make a lockout permanent until the Directory Manager resets the user password.
- Otherwise, select the Lockout duration radio button and enter the number of minutes the user account will be temporarily locked.
- When you have finished making changes to the password policy, click Save. The new global password policy will be enforced immediately.
Configuring the Password Policy From the Command Line
The global password policy is defined by the attributes of the cn=Password Policy, cn=config entry. Use the ldapmodify utility to change the global policy in this entry.
The definition of all possible attributes in a password policy is given in "cn=Password Policy" in Chapter 4 of the Sun ONE Directory Server Reference Manual.
For example, password syntax and length checking are off by default and account lockout is disabled. Use the following command to turn on syntax checking, set the minimum length to 8, and enable a temporary five-minute lockout after 5 incorrect password attempts:
dn: cn=Password Policy,cn=config
changetype: modify
replace: passwordCheckSyntax
passwordCheckSyntax: on
-
replace: passwordMinLength
passwordMinLength: 8
-
replace: passwordLockout
passwordLockout: on
-
replace: passwordMaxFailure
passwordMaxFailure: 5
-
replace: passwordLockoutDuration
passwordLockoutDuration: 300
-
replace: passwordUnlock
passwordUnlock: onManaging Individual Password Policies
An individual password policy is defined in a subentry with the passwordPolicy object class. The policy may be defined anywhere in your directory tree with a DN of the form cn=policy name,subtree. After defining the password policy using the Directory Server console or the command-line utilities, you assign the password policy by setting the passwordPolicySubentry attribute in the desired user entry.
In this section, we use the example of implementing a password policy for temporary employees at Example.com, whose subtree root is dc=example,dc=com.
Defining a Policy Using the Console
- On the top-level Directory tab of the Directory Server console, display the entry where you wish to define the individual password policy subentry.
- Right-click on the entry and select New>Password Policy. Alternatively, you may left-click the entry to select it and choose New>Password Policy from the Object menu.
The custom editor for Password Policy entries is displayed.
- In the General fields, enter a name and optional description for this policy. The name will become the value of the cn naming attribute for the subentry that defines the policy.
- Click on the Password tab to set the following aspects of the policy:
- Specify that users must change their password the first time they log on by selecting the "User must change password after reset" checkbox.
If you select this checkbox, only the Directory Manager is authorized to reset the users's password. A regular administrative user cannot force the user to update their password.
- To allow users to change their own passwords, select the "User may change password" checkbox.
- To limit how often users may change their own password, enter the number of days in the "Allow changes in X day(s)" text box. To allow users to change their password as often as they desire, select the No Limitation checkbox.
- To prevent users from using the same password over and over, select the "Keep password history" checkbox and specify the number of passwords you want the server to keep for each user text box. Users will not be able to set a password that still exists in the list. To be effective, you should also limit how often users may change their password.
- If you do not want user passwords to expire, select the "Password never expires" radio button.
- Otherwise, select the "Password expires after X days" radio button to force users to periodically change their passwords, and then enter the number of days that a user password is valid.
- If you selected expiring passwords, you can specify how long before the password expires to send a warning to the user. In the "Send warning X days before password expires" text enter the number of days before password expiration to send a warning.
When the user receives a warning, the password will expire on the original date. Deselect the "Expire regardless of warning" checkbox to extend the expiration to allow a full warning period after the warning is sent. Only one warning and one extension will occur. There is no grace login if the user binds after the password has expired.
- 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. Then, specify the minimum acceptable password length in the "Password minimum length" text box.
- By default, the Directory Manager cannot reset a password that violates the password policy, for example reusing a password in the history. Select the "Allow Directory Manager to bypass Password Policy" checkbox to allow this.
- Specify what encryption method you want the server to use when storing passwords from the "Password encryption" pull-down menu.
- Click on the Lockout tab and select the "Accounts may be locked out" checkbox to define the account lockout policy:
- Enter the number of login failures and the period in which they must occur to trigger a lockout.
- Select the Lockout forever radio button to make a lockout permanent until the Directory Manager resets the user password.
- Otherwise, select the Lockout duration radio button and enter the number of minutes the user account will be temporarily locked.
- Click OK in the custom editor to save your policy and create its subentry.
Defining a Policy From the Command Line
For this password policy, imagine you want passwords of temporary employees to expire after 100 days (8 640 000 seconds), with a warning about the expiration returned to the user upon binds starting 3 days (259 200 seconds) before the password expires. Turn on syntax checking to force minimal checks for password security, and enforce lock outs to prevent intruders from trying to crack the password through a dictionary attack. For other aspects of the policy, you apply the default values.
Define this password policy in the Example.com subtree by adding the following subentry under dc=example,dc=com:
dn: cn=TempPolicy,dc=example,dc=com
objectClass: top
objectClass: passwordPolicy
objectClass: LDAPsubentry
cn: TempPolicy
passwordStorageScheme: SSHA
passwordChange: on
passwordMustChange: on
passwordCheckSyntax: on
passwordExp: on
passwordExp: on
passwordMinLength: 6
passwordMaxAge: 8640000
passwordMinAge: 0
passwordWarning: 259200
passwordInHistory: 6
passwordLockout: on
passwordMaxFailure: 3
passwordUnlock: on
passwordLockoutDuration: 3600
passwordResetFailureCount: 600The definition of all possible attributes in a password policy is given in "cn=Password Policy" in Chapter 4 of the Sun ONE Directory Server Reference Manual.
Assigning Password Policies
Assigning individual password policies consists of pointing to the appropriate policy subentry. Either you add the policy to a single entry as the value of passwordPolicySubentry, or you manage the policy with CoS and roles.You must also set access control to prevent users from modifying the password policy that applies to them.
Using the Console
The Directory Server console provides an interface for managing the password policy assigned to a user or group:
- On the top-level Directory tab of the Directory Server console, display the user or group entry where you wish to assign or modify the individual password policy.
- Right-click the entry and select Set Password Policy from the pop-up menu. Alternatively, you may left-click the entry to select it and then choose Set Password Policy from the Object menu.
- The Password Policy dialog tells you which password policy applies to this entry:
- If the global policy applies, click Assign to select a password policy subentry anywhere in the directory tree.
- If an individual policy is already defined, you may replace it, remove it, or edit it. Clicking Edit Policy will invoke the custom editor for the named policy subentry.
Assigning or replacing a password policy will invoke a directory browser dialog where you may find password policy subentries shown with a small key icon.
- Click OK in the Password Policy dialog if you have changed the policy. The new policy will take effect immediately.
From the Command Line
To assign a password policy to a user or a group entry, add the DN of the password policy as the value of passwordPolicySubentry attribute. For example, the following command will assign cn=TempPolicy,dc=example,dc=com to Barbara Jensen:
dn: uid=bjensen,ou=People,dc=example,dc=com
changetype: modify
add: passwordPolicySubentry
passwordPolicySubentry: cn=TempPolicy,dc=example,dc=comUsing Roles and CoS
When grouping users with roles, you can use CoS to point to the appropriate policy subentry. Refer to Chapter 5 "Advanced Entry Management" for details on using Roles and CoS.
As an example, the following command will create a filtered role for temporary employees at Example.com and assign cn=TempPolicy,dc=example,dc=com to those having the role:
dn: cn=TempFilter,ou=people,dc=example,dc=com
objectclass: top
objectclass: LDAPsubentry
objectclass: nsRoleDefinition
objectclass: nsComplexRoleDefinition
objectclass: nsFilteredRoleDefinition
cn: TempFilter
nsRoleFilter: (&(objectclass=person)(status=contractor))
description: filtered role for temporary employees
dn: cn=PolTempl,dc=example,dc=com
objectclass: top
objectclass: nsContainer
dn: cn="cn=TempFilter,ou=people,dc=example,dc=com",
cn=PolTempl,dc=example,dc=com
objectclass: top
objectclass: extensibleObject
objectclass: LDAPsubentry
objectclass: costemplate
cosPriority: 1
passwordPolicySubentry: cn=TempPolicy,dc=example,dc=com
dn: cn=PolCoS,dc=example,dc=com
objectclass: top
objectclass: LDAPsubentry
objectclass: cosSuperDefinition
objectclass: cosClassicDefinition
cosTemplateDN: cn=PolTempl,dc=example,dc=com
cosSpecifier: nsRole
cosAttribute: passwordPolicySubentry operationalThe users who have the status of contractor now become subject to the password policy cn=TempPolicy,dc=example,dc=com.
Protecting the Individual Password Policy
To prevent users from modifying which password policy applies to them, you must also add an ACI such as the following to the root entry:
dn: dc=example,dc=com
changetype: modify
add: aci
aci: (targetattr != "passwordPolicySubentry")(version 3.0; acl
"Allow self modification except for passwordPolicySubentry";
allow (write) (userdn ="ldap:///self");)Resetting User Passwords
The directory stores password values in the userPassword attribute of the user entry. Depending on the access control settings for the server, users may set the value of userPassword in accordance with the password policy you specify, using standard tools, such as ldapmodify for example.
In case permanent account lockout occurs (accountUnlockTime, an operational attribute for the user, is 0, and passwordUnlock is off in the password policy), you can reset the password as Directory Manager to unlock the user account. For example, assume Example.com directory user Barbara Jensen gets permanently locked out after forgetting and guessing her password:
dn: uid=bjensen,ou=People,dc=example,dc=com
changetype: modify
replace: userPassword
userPassword: ChAnGeMeIf passwordMustChange is on in the password policy, Barbara will have to change her password after the next bind. Remember to tell her that you changed her password to ChAnGeMe, preferably through a secure channel.
Inactivating and Activating Users and Roles
You can temporarily inactivate a single user account or a set of accounts. Once inactivated, a user cannot bind to the directory. The authentication operation will fail.
The procedures in this section can be used for inactivating both users and roles in the same manner. However, when you inactivate a role, you are inactivating the members of the role and not the role entry itself. For more information about roles in general and how roles interact with access control in particular, refer to Chapter 5 "Advanced Entry Management."
Setting User and Role Activation Using the Console
- On the top-level Directory tab of the Directory Server console, browse the directory tree to display the user or role entry you wish to inactivate or reactivate.
- Double-click the entry to display its custom editor, and click on the Account tab in the left-hand column.
The right panel displays the activation status of the entry.
- Click the button to inactivate or activate the user or role corresponding to this entry. A red box and bar through the user or role icon in the editor indicates that the entry will be inactivated.
- Click OK to close the dialog box and save the new activation state of the entry.
As a short cut to opening the custom editor, you may also select the entry and choose Inactivate or Activate from the Object menu.
You can view the activation state of any directory object by selecting Inactivation State from the Console View>Display menu. The icons of all inactive entries are then shown with a red bar through them. The correct activation state of user entries is shown regardless of whether they are inactivated directly or through role membership.
Setting User and Role Activation From the Command Line
To inactivate a user account or the members of a role, use the ns-inactivate.pl script (directoryserver account-inactivate in the Solaris Packages). To activate or reactivate a user or role, use the ns-activate.pl script (directoryserver account-inactivate in the Solaris Packages). The commands for these scripts are platform-dependent:
The following commands show how to use the perl scripts to inactivate and reactivate Barbara Jensen's user account:
ns-inactivate.pl -h host -p port -D "cn=Directory Manager" -w password \
-I "uid=bjensen,ou=People,dc=example,dc=com"ns-activate.pl -h host -p port -D "cn=Directory Manager" -w password \
-I "uid=bjensen,ou=People,dc=example,dc=com"In both of these commands, the -I option specifies the DN of the user or role for which you wish to set the activation state.
For more information, see "ns-inactivate.pl" and "ns-activate.pl" in Chapter 2 of the Sun ONE Directory Server Reference Manual.
Setting Individual Resource Limits
You can control server limits for search operations using special operational attribute values on the client application binding to the directory. You can set the following search operation limits:
- The look-through limit specifies the maximum number of entries that will be examined for a search operation.
- The size limit specifies the maximum number of entries the server returns to the client application in response to a search operation.
- The time limit specifies the maximum time the server spends processing a search operation.
- The idle timeout specifies the time a client connection to the server can be idle before the server drops the connection.
Note The Directory Manager may use unlimited resources by default.
The resource limits you set for a specific user take precedence over the default resource limits you set in the global server configuration. You should verify that attributes which store the individual resource limits are protected from self modification by the following ACI on the suffix containing user entries:
Setting Resource Limits Using the Console
- On the top-level Directory tab of the Directory Server console, browse the directory tree to display the user for which you wish to set resource limits.
- Double-click the entry to display the custom editor, and click on the Account tab in the left-hand column. The right panel displays the current limits set on the entry.
- Enter values in the four text fields for the resource limits described above. Entering a value of -1 indicates no limit for that resource.
- Click OK when you are finished to save the new limits.
Setting Resource Limits From the Command Line
The following attributes can be set with the ldapmodify command on a user entry to limit that user's resource usage:
For example, you might set the size limit for an entry by performing an ldapmodify as follows:
dn: uid=bjensen,ou=People,dc=example,dc=com
changetype: modify
add: nsSizeLimit
nsSizeLimit: 500The ldapmodify statement adds the nsSizeLimit attribute to Barbara Jensen's entry and gives it a search return size limit of 500 entries.