Chapter 7 Directory Server Password Policy

When a user connects to Directory Server, the user is authenticated. The directory can grant access rights and resource limits to the user depending on the identity established during authentication. An account in this chapter refers loosely to a user entry. The account also reflects the permissions for the user to perform operations on the directory. In this discussion of password policy, every account is associated with a user entry, and a password.

This chapter also addresses account activation, an aspect of password policy. The Directory Administrator can directly lock and unlock accounts, independently of password policy.

This chapter does not cover authentication methods. Some authentication methods, such as SASL GSSAPI and client SSL certificate-based authentication, do not involve the use of passwords. The information about password policy in this chapter does not apply to such authentication methods. See Chapter 5, Directory Server Security for instructions on configuring authentication mechanisms.

This chapter also does not cover the compatibility of password policies between Directory Server 6.2 and previous Directory Server versions. When you create a Directory Server 6.2 instance, the password policy implementation defaults to a Directory Server 5 compatible mode to facilitate upgrading from earlier versions. To take full advantage of the password policy features described in this chapter, you will need to change the password policy compatibility mode. For more information about setting the password compatibility mode, see Password Policy Compatibility in Sun Java System Directory Server Enterprise Edition 6.2 Migration Guide.

This chapter covers the following topics:

• Password Policies and Worksheet

• Managing the Default Password Policy

• Managing Specialized Password Policies

• Modifying Passwords From the Command Line When pwdSafeModify Is TRUE

• Resetting Expired Passwords

• Setting Account Properties

• Manually Locking Accounts

Password Policies and Worksheet

This section explains password policy settings and provides a worksheet to help you define password policies that fit your requirements.

To use the default password policy, see Managing the Default Password Policy.

Password Policy Settings

When you specify a password policy in Directory Server, you either modify or create an entry that includes the object class pwdPolicy(5dsoc).

When defining a password policy for a particular type of user, you need to consider the following:

• How accounts get locked out when an intruder appears to be trying to crack a password.

  See Policy for Account Lockout for details.

• How password changes can be made.

  See Policy for Password Changes for details.

• What password values are allowed.

  See Policy for Password Content for details.

• How password expiration is handled.

  See Policy for Password Expiration for details.

• If the server records the time of the last successful authentication.

  See Policy for Tracking Last Authentication Time.

Subsequent sections in this chapter explain how you handle these areas of password policy. Use the Worksheet for Defining Password Policy to clarify each password policy that you plan to implement.

Policy for Account Lockout

This section explains the policy attributes that govern account lockout.

A Directory Server account refers loosely to a user's entry and to the permissions that user has to perform operations on the directory. Each account is associated with a bind DN and a user password. When an intruder appears to be trying to crack a password, you want Directory Server to lock the account. The lock prevents the intruder from using the account to bind. The lock also prevents the intruder from being able to continue the attack.

As administrator, you can also manually render inactive an account or the accounts of all users who share a role. See Manually Locking Accounts for instructions. Yet, a key part of your password policy is specifying under what circumstances Directory Server locks an account without your intervention.

First of all, you must specify that Directory Server can use pwdLockout(5dsat) to automatically lock accounts when too many failed binds occur. Directory Server keeps track of consecutive failed attempts to bind to an account. You use pwdMaxFailure(5dsat) to specify how many consecutive failures are allowed before Directory Server locks the account.

Directory Server locks accounts strictly according to password policy. The operation is purely mechanical. Accounts can lock not because an intruder is mounting an attack against the account, but because the user typed the password incorrectly. Thus, you can use pwdFailureCountInterval(5dsat) to specify how long Directory Server should wait between tries before cleaning out the records of failed attempts. You use pwdLockoutDuration(5dsat) to specify how long lockout should last before Directory Server automatically unlocks the account. The administrator does not have to intervene to unlock accounts of users who make legitimate mistakes with no malicious intent.

If your user data is replicated across a replication topology, lockout attributes are replicated along with other entry data. The pwdIsLockoutPrioritized(5dsat) attribute's default setting is TRUE, so updates for lockout attributes are replicated with a higher priority. A user is thus limited to making pwdMaxFailure consecutive failed attempts to bind to any single replica before being locked out, and probably fewer attempts at other replicas before being locked out. For details about how to make sure that a user gets exactly pwdMaxFailure attempts before being locked out across an entire replicated topology, see Preventing Authentication by Using Global Account Lockout in Sun Java System Directory Server Enterprise Edition 6.2 Deployment Planning Guide.

Policy for Password Changes

This section explains the policy attributes that govern changes to passwords.

In many deployments, Directory Server is the repository for identity data. Users should be able to change their own passwords, as specified by pwdAllowUserChange(5dsat), so you do not have to change the passwords.

After you allow users to change their own passwords, you might also want to control the circumstances under which users can change their passwords. You can use pwdSafeModify(5dsat) to specify that users who change a password must provide the correct existing password before they are allowed to replace the password. See Modifying Passwords From the Command Line When pwdSafeModify Is TRUE for an example of how to modify the password. You can prevent users from reusing passwords by using pwdInHistory(5dsat) to specify how many passwords Directory Server remembers. You can also prevent users from changing their passwords too often by setting pwdMinAge(5dsat).

In many cases either you as administrator or some application that you manage creates user entries in the directory. You can assign a user password value to change when the user first binds to the new account. You might also have to reset a user password, after which the user should change the password when next using the account. Directory Server has a specific attribute, pwdMustChange(5dsat), that you can use to indicate whether a user must change passwords after the password value is reset by another user.

You can also specify that the Directory Administrator is not subject to policy when changing passwords by setting passwordRootdnMayBypassModsChecks(5dsat).

Policy for Password Content

This section explains the policy attributes that govern password content.

Although password values are not generally returned in directory searches, an attacker could potentially gain access to the directory database. Therefore, password values are generally stored in one of the supported hashed formats that you specify using passwordStorageScheme(5dsat).

You can also enforce a check that passwords meet your definition of minimum password quality, by setting pwdCheckQuality(5dsat). The server then checks that the password does not match any of the values of the cn, givenName, mail, ou, sn, or uid attributes. The comparison of the password with any of these attributes is case-insensitive.

Additional checks are available with pwdCheckQuality(5dsat) set. You can enforce that passwords have at least a specified number of characters by setting pwdMinLength(5dsat). Furthermore, when the Strong Password Check plug-in is enabled, Directory Server checks that the password does not contain strings from the dictionary file that the plug-in uses. The server also checks that the password contains an appropriate mix of different types of characters.

You can enable strong password checking with the dsconf set-server-prop command. Use the pwd-strong-check-enabled property to turn on the plug-in, and restart the server for the change to take effect. Use the pwd-strong-check-require-charset property to specify what character sets to require in passwords. The pwd-strong-check-require-charset property takes a mask of the following values:

lower

The new password must include a lower case character.

upper

The new password must include an upper case character.

digit

The new password must include a digit.

special

The new password must include a special character.

any-two

The new password must include at least one character from each of at least two of the above mentioned character sets.

any-three

The new password must include at least one character from each of at least three of the above mentioned character sets.

The default setting for the pwd-strong-check-require-charset property is lower && upper && digit && special.

Policy for Password Expiration

This section explains the policy attributes that govern password expiration.

To ensure that users change their passwords regularly, you can configure Directory Server to have passwords expire after the passwords reach a certain age, by setting pwdMaxAge(5dsat).

Users must be informed that their passwords are going to expire. You can configure Directory Server to return a warning that the password used to bind is going to expire. Use pwdExpireWarning(5dsat) to define how long before expiration that the warning should be returned when a client binds. Notice that the client application gets the warning. The user does not get the warning directly. Client applications must notify the end user when the applications receive the warning that the password is about to expire.

You can allow users one or more tries to bind with an expired password, by setting pwdGraceAuthNLimit(5dsat). Users who failed to change their passwords in time can thus still bind to change their passwords. Be aware that, when a user binds with a grace login, the user can perform any operation. A grace login works as if the password had not expired.

Directory Server updates the operational attribute pwdChangedTime(5dsat) every time that the password on the entry is modified. As a result, if you wait to enable password expiration, user passwords that have already aged expire immediately when you enable password expiration. Use warnings and grace logins if this behavior is not what you intend.

Policy for Tracking Last Authentication Time

This section covers the use of the password policy attribute pwdKeepLastAuthTime(5dsat).

When set, pwdKeepLastAuthTime causes Directory Server to track the time of the last successful bind every time that a user authenticates. The time is recorded on the pwdLastAuthTime(5dsat) operational attribute of the user's entry.

Because this behavior adds an update for each successful bind operation, the pwdKeepLastAuthTime feature is not activated by default. You must explicitly turn the feature on to use it in your deployment.

Worksheet for Defining Password Policy

This worksheet is designed to help you define a password policy to implement either through the command-line interface or using Directory Service Control Center (DSCC). Use one worksheet for each password policy.

After you record the DN of the password policy entry, record your decisions about settings for attributes in each policy area. Also record your rationale for those settings.

When the pwdCheckQuality attribute is set to 2, the server can perform additional checks. When the Password Check plug-in is also enabled, settings for the plug-in affect what checks are performed the on values of new passwords.

Managing the Default Password Policy

The default password policy applies to all users in the directory instance who do not have a specialized policy defined. However, the default password policy does not apply to the Directory Manager. See Which Password Policy Applies for details on policy scope.

The default password policy is the one policy that you can configure using the dsconf command. You can also view default password policy by reading cn=Password Policy,cn=config.

This section shows the policy attributes for each policy area and the related dsconf server properties. It also explains how to view and change default password policy settings.

Correlation Between Password Policy Attributes and dsconf Server Properties

The following table shows the password policy attributes and related dsconf server properties for each password policy area.

The properties that correlate to pwdCheckQuality configure the Password Check plug-in. Therefore, the five properties apply to the entire server instance. The five properties thus also apply to other password policies where pwdCheckQuality: 2.

To View Default Password Policy Settings

You can view default password policy settings with the dsconf command.

You can use DSCC to perform this task. For information, see Directory Service Control Center Interface and the DSCC online help.

1. Read the default password policy configuration.

   $ dsconf get-server-prop -h host -p port | grep ^pwd- pwd-accept-hashed-pwd-enabled : N/A pwd-check-enabled : off pwd-compat-mode : DS5-compatible-mode pwd-expire-no-warning-enabled : on pwd-expire-warning-delay : 1d pwd-failure-count-interval : 10m pwd-grace-login-limit : disabled pwd-keep-last-auth-time-enabled : off pwd-lockout-duration : 1h pwd-lockout-enabled : off pwd-lockout-repl-priority-enabled : on pwd-max-age : disabled pwd-max-failure-count : 3 pwd-max-history-count : disabled pwd-min-age : disabled pwd-min-length : 6 pwd-mod-gen-length : 6 pwd-must-change-enabled : off pwd-root-dn-bypass-enabled : off pwd-safe-modify-enabled : off pwd-storage-scheme : SSHA pwd-strong-check-dictionary-path : /local/ds6/plugins/words-english-big.txt pwd-strong-check-enabled : off pwd-strong-check-require-charset : lower pwd-strong-check-require-charset : upper pwd-strong-check-require-charset : digit pwd-strong-check-require-charset : special pwd-supported-storage-scheme : CRYPT pwd-supported-storage-scheme : SHA pwd-supported-storage-scheme : SSHA pwd-supported-storage-scheme : NS-MTA-MD5 pwd-supported-storage-scheme : CLEAR pwd-user-change-enabled : on

To Change Default Password Policy Settings

You can change the default password policy by setting server properties with the dsconf command.

Before completing this procedure, read and complete the Worksheet for Defining Password Policy.

You can use DSCC to perform this task. For information, see Directory Service Control Center Interface and the DSCC online help.

1. Translate the settings from your worksheet into dsconf command property settings.

2. Use the dsconf set-server-prop command to change default password policy properties appropriately.

   For example, the following command allows the Directory Manager to violate the default policy when modifying passwords:

   $ dsconf set-server-prop -h host -p port pwd-root-dn-bypass-enabled:on

Managing Specialized Password Policies

Specialized password policies are defined in a pwdPolicy(5dsoc) entry. A policy can be defined anywhere in the directory tree, typically in a subtree that is replicated with the accounts that the policy governs. The policy has a DN of the form cn=policy name,subtree.

After defining the password policy, you assign the password policy by setting the pwdPolicySubentry(5dsat) attribute in the desired user entry.

This section covers these topics:

• Which Password Policy Applies

• To Create a Password Policy

• To Assign a Password Policy to an Individual Account

• To Assign a Password Policy Using Roles and CoS

• To Set Up a First Login Password Policy

Which Password Policy Applies

Directory Server allows you to configure multiple password policies. This section explains default password policies and specialized password policies. This section also explains which policy is enforced when multiple password policies could apply to a given account.

When you first create a Directory Server instance, that instance has a default password policy. That default password policy is expressed in the configuration entry cn=PasswordPolicy,cn=config. The default password policy applies to all accounts in the directory except for the Directory Manager.

As in all Directory Server password policies, cn=PasswordPolicy,cn=config has object class pwdPolicy(5dsoc) and object class sunPwdPolicy(5dsoc).

When you create a Directory Server instance, password policy attributes remain in Directory Server 5 compatible mode to facilitate upgrading from earlier versions. In Directory Server 5 compatible mode, Directory Server also handles password policy entries that have object class passwordPolicy(5dsoc).

After your upgrade is complete, you use the new password policy in fully featured mode, as described in Sun Java System Directory Server Enterprise Edition 6.2 Migration Guide. The administrative move is transparent to directory applications.

This chapter covers password policy configuration using the new password policy features.

You can change the default password policy to override the default settings. You can use the dsconf(1M) command to set the server properties for default password policy. Such server property names typically start with the pwd- prefix. When changing settings for such properties, you override the default password policy for the instance. Replication does not, however, copy the changes to replicas. The changes that you make to the default password policy are part of the configuration for the instance, not part of the directory data.

In addition to configuring the default password policy, you can also configure specialized password policies. A specialized password policy is defined by an entry in the directory tree. The specialized password policy entry has the same object class, pwdPolicy(5dsoc), as the default password policy, and therefore takes the same policy attributes. Because specialized password policies are regular directory entries, policy entries are replicated in the same manner as regular directory entries.

A user entry references a specialized password policy through the value of the operational attribute pwdPolicySubentry(5dsat). When referenced by a user entry, a specialized password policy overrides the default password policy for the instance. In many deployments, you assign users roles. You can configure roles to work with class of service (CoS) to determine the password policies that apply to user accounts, by setting the pwdPolicySubentry value. To override the password policy set by a role, change the pwdPolicySubentry value on that user's entry directly.

To summarize this section, initially the default password policy applies. You can change the default password policy to override the defaults. You can then create specialized password policy entries to override the default password policy. When you assign password policy with roles and CoS, you can override the CoS-assigned policy by specifying a password policy for an individual entry.

To Create a Password Policy

You create and modify specialized password policies in the same way that you create and modify any other directory entry. The following procedure demonstrates use of a text editor to write the password policy entry in LDIF. Then you use the ldapmodify command with the -a option to add the password policy entry to the directory.

You can use DSCC to perform this task. For information, see Directory Service Control Center Interface and the DSCC online help.

Before You Begin

Example data as shown here is from Example.ldif unless stated otherwise.

1. Complete a password policy worksheet for the policy you want to create.

   See Worksheet for Defining Password Policy for a sample.

2. Write a password policy entry, in LDIF, that is based on the worksheet.

   For example, the following policy entry specifies a password policy for temporary employees at Example.com, whose subtree root is dc=example,dc=com:

   dn: cn=TempPolicy,dc=example,dc=com
   objectClass: top
   objectClass: pwdPolicy
   objectClass: sunPwdPolicy
   objectClass: LDAPsubentry
   cn: TempPolicy
   pwdAttribute: userPassword
   pwdCheckQuality: 2
   pwdLockout: TRUE
   pwdLockoutDuration: 300
   pwdMaxFailure: 3
   pwdMustChange: TRUE

   In addition to the default password policy settings, the policy as shown here specifies additional behaviors. Password quality checks are enforced. Accounts are locked for five minutes, 300 seconds, after three consecutive bind failures. Passwords must be changed after the passwords are reset. After the policy is assigned to user accounts, the settings explicitly specified here override the default password policy.

3. Add the password policy entry to the directory.

   For example, the following command adds the password policy for temporary employees at Example.com under dc=example,dc=com. The password policy has been saved in a file named pwp.ldif.

   $ ldapmodify -a -D uid=kvaughan,ou=people,dc=example,dc=com -w - -f pwp.ldif Enter bind password: adding new entry cn=TempPolicy,dc=example,dc=com $ ldapsearch -D uid=kvaughan,ou=people,dc=example,dc=com -w --b dc=example,dc=com \ "(&(objectclass=ldapsubentry)(cn=temppolicy))" Enter bind password: version: 1 dn: cn=TempPolicy,dc=example,dc=com objectClass: top objectClass: pwdPolicy objectClass: LDAPsubentry cn: TempPolicy pwdCheckQuality: 2 pwdLockout: TRUE pwdLockoutDuration: 300 pwdMaxFailure: 3 pwdMustChange: TRUE $

   As shown in Example.ldif, kvaughan is an Human Resources manager who has access to modify dc=example,dc=com entries. Vaughan's bind password, as shown in Example.ldif, is bribery.

See Also

To define which user accounts are governed by the policies you define, see To Assign a Password Policy to an Individual Account or To Assign a Password Policy Using Roles and CoS.

To Assign a Password Policy to an Individual Account

This procedure assigns an existing password policy to a single user account.

To complete this procedure, you must have a specialized password policy to assign. See To Create a Password Policy.

You can use DSCC to perform this task. For information, see Directory Service Control Center Interface and the DSCC online help.

Example data shown here is from Example.ldif unless stated otherwise.

1. Add the password policy DN to the values of the pwdPolicySubentry attribute of the user entry.

   For example, the following commands assign the password policy that is defined in To Create a Password Policy to David Miller's entry, whose DN is uid=dmiller,ou=people,dc=example,dc=com:

   $ cat pwp.ldif dn: uid=dmiller,ou=people,dc=example,dc=com changetype: modify add: pwdPolicySubentry pwdPolicySubentry: cn=TempPolicy,dc=example,dc=com $ ldapmodify -D uid=kvaughan,ou=people,dc=example,dc=com -w - -f pwp.ldif Enter bind password: modifying entry uid=dmiller,ou=people,dc=example,dc=com $ ldapsearch -D uid=kvaughan,ou=people,dc=example,dc=com -w - -b dc=example,dc=com \ "(uid=dmiller)" pwdPolicySubentry Enter bind password: version: 1 dn: uid=dmiller, ou=People, dc=example,dc=com pwdPolicySubentry: cn=TempPolicy,dc=example,dc=com $

   As shown in Example.ldif, kvaughan is a Human Resources manager who has access to modify dc=example,dc=com entries. Vaughan's bind password, as shown in Example.ldif, is bribery.

To Assign a Password Policy Using Roles and CoS

This procedure assigns an existing specialized password policy to a set of users by applying roles and class of service (CoS). See Chapter 9, Directory Server Groups, Roles, and CoS for more information about roles and CoS.

To complete this procedure, you must have a specialized password policy to assign. See To Create a Password Policy.

You can use DSCC to perform this task. For information, see Directory Service Control Center Interface and the DSCC online help.

Example data shown here is from Example.ldif unless stated otherwise.

1. Create a role for the entries to be governed by the password policy.

   For example, the following commands create a filtered role for temporary employees at Example.com:

   $ cat tmp.ldif 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 $ ldapmodify -a -D uid=kvaughan,ou=people,dc=example,dc=com -w - -f tmp.ldif Enter bind password: modifying entry cn=TempFilter,ou=people,dc=example,dc=com $

   As shown in Example.ldif, kvaughan is a Human Resources manager who has access to modify dc=example,dc=com entries. Vaughan's bind password, as shown in Example.ldif, is bribery.

2. Create a class of service to generate the DN of the password policy entry.

   The DN is the value of the pwdPolicySubentry attribute of users who have the role that you created.

   For example, the following commands create a filtered role for temporary employees at Example.com. The commands assign cn=TempPolicy,dc=example,dc=com to users who have the role.

   $ cat cos.ldif 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 pwdPolicySubentry: 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: pwdPolicySubentry operational $ ldapmodify -a -D uid=kvaughan,ou=people,dc=example,dc=com -w - -f cos.ldif Enter bind password: modifying entry cn=TempFilter,ou=people,dc=example,dc=com $

   Users whose status is contractor now become subject to the password policy cn=TempPolicy,dc=example,dc=com.

To Set Up a First Login Password Policy

In many deployments, the password policy to apply for new accounts differs from the password policy to apply for established accounts. This section demonstrates a first login password policy. The policy gives users three days to use a newly created account, and set their new passwords before that account is locked. The policy is designed to work in the same way for users whose passwords have been reset.

You cannot use DSCC to perform this task. Use the command line, as described in this procedure.

1. Create a specialized password policy for newly created accounts.

   For example, add a password policy entry that sets expiration time to three days, which is 259,200 seconds. This password policy also has pwdMustChange(5dsat) set to TRUE, meaning the users much change their passwords when they first bind.

   $ cat firstLogin.ldif dn: cn=First Login,dc=example,dc=com objectClass: top objectClass: LDAPsubentry objectClass: pwdPolicy objectClass: sunPwdPolicy cn: First Login passwordStorageScheme: SSHA pwdAttribute: userPassword pwdInHistory: 0 pwdExpireWarning: 86400 pwdLockout: TRUE pwdMinLength: 6 pwdMaxFailure: 3 pwdMaxAge: 259200 pwdFailureCountInterval: 600 pwdAllowUserChange: TRUE pwdLockoutDuration: 3600 pwdMinAge: 0 pwdCheckQuality: 2 pwdMustChange: TRUE $ ldapmodify -a -D cn=admin,cn=Administrators,cn=config -w - -f firstLogin.ldif Enter bind password: adding new entry cn=First Login,dc=example,dc=com $

2. Create a role that includes all newly created accounts.

   In creating this role, set up some way to distinguish newly created accounts from established accounts.

   1. Define new accounts as accounts that have a pwdReset(5dsat) attribute set to TRUE.

      When a user's password is changed by another user, such as a password administrator, pwdReset is set to TRUE.

   2. Create the role that identifies new accounts.

      For example, the following commands create a role for accounts whose passwords have been reset.

      $ cat newRole.ldif dn: cn=First Login Role,ou=people,dc=example,dc=com objectclass: top objectclass: LDAPsubentry objectclass: nsRoleDefinition objectclass: nsComplexRoleDefinition objectclass: nsFilteredRoleDefinition cn: First Login Role nsRoleFilter: (pwdReset=TRUE) description: Role to assign password policy for new and reset accounts $ ldapmodify -a -D uid=kvaughan,ou=people,dc=example,dc=com -w - -f newRole.ldif Enter bind password: adding new entry cn=First Login Role,ou=people,dc=example,dc=com $

3. Assign the password policy for newly created accounts with class of service.

   $ cat newCoS.ldif dn: cn=First Login Template,dc=example,dc=com objectClass: top objectClass: nsContainer dn: cn="cn=First Login Role,ou=people,dc=example,dc=com", cn=First Login Template,dc=example,dc=com objectClass: top objectClass: extensibleObject objectClass: LDAPSubEntry objectClass: CoSTemplate cosPriority: 1 pwdPolicySubentry: cn=First Login,dc=example,dc=com dn: cn=First Login CoS,dc=example,dc=com objectClass: top objectClass: LDAPSubEntry objectClass: CoSSuperDefinition objectClass: CoSClassicDefinition cosTemplateDN: cn=First Login Template,dc=example,dc=com cosSpecifier: nsRole cosAttribute: pwdPolicySubentry operational $ ldapmodify -a -D uid=kvaughan,ou=people,dc=example,dc=com -f newCoS.ldif Enter bind password: adding new entry cn=First Login Template,dc=example,dc=com adding new entry cn="cn=First Login Role,ou=people,dc=example,dc=com", cn=First Login Template,dc=example,dc=com adding new entry cn=First Login CoS,dc=example,dc=com $

Example 7–1 Checking Password Policy Assignment

Add a new user that fits the role that you have added. You add the user to verify that new users are subject to the new password policy, but existing users are not.

$ cat quentin.ldif
dn: uid=qcubbins,ou=People,dc=example,dc=com
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
uid: qcubbins
givenName: Quentin
sn: Cubbins
cn: Quentin Cubbins
mail: quentin.cubbins@example.com
userPassword: ch4ngeM3!
description: New account

$ ldapmodify -a -D uid=kvaughan,ou=people,dc=example,dc=com -w - -f quentin.ldif
Enter bind password: 
adding new entry uid=qcubbins,ou=People,dc=example,dc=com

$ ldapsearch -D uid=kvaughan,ou=people,dc=example,dc=com -w - \
-b dc=example,dc=com uid=qcubbins nsrole pwdPolicySubentry
Enter bind password:
version: 1
dn: uid=qcubbins,ou=People,dc=example,dc=com
nsrole: cn=first login role,ou=people,dc=example,dc=com
pwdPolicySubentry: cn=First Login,dc=example,dc=com
$ ldapsearch -b dc=example,dc=com uid=bjensen nsrole pwdPolicySubentry
version: 1
dn: uid=bjensen, ou=People, dc=example,dc=com
$ 

Notice that Barbara Jensen's existing account is governed by the default password policy. Quentin Cubbins's new account is governed, however, by the password policy that you defined.

Modifying Passwords From the Command Line When pwdSafeModify Is TRUE

When the password policy for a user has pwdSafeModify set to TRUE, the old password must be provided with the new password to change the password. The command dsconf set-server-prop pwd-safe-modify-enabled:on has the same effect for the default password policy.

You can use the ldappasswd(1) command to change the password. This command provides support for safe password modification. This command implements RFC 3062, LDAP Password Modify Extended Operation

You can use the ldapmodify(1) command to change the password. The LDIF that you pass to the ldapmodify command in that case should be as follows:

dn: DN of user whose password you are changing
changetype: modify
delete: userPassword
userPassword: old password
-
add: userPassword
userPassword: new password

You can also use the LDAP password modify extended operation. Setting up support for the extended operation is explained in To Reset a Password With the Password Modify Extended Operation.

Resetting Expired Passwords

When password policy enforces password expiration, some users will not change their passwords in time. This section shows how you can change passwords that have expired.

Directory Server updates the operational attribute pwdChangedTime(5dsat) every time that the password on the entry is modified. As a result, if you wait to enable password expiration, user passwords that have already aged expire immediately when you enable password expiration. Use warnings and grace logins if this behavior is not what you intend.

This section includes procedures for resetting a password with the password modify extended operation and for allowing grace authentications when passwords expire.

The mechanisms described in this section are intended for use by administrators, or by applications that handle the actual user interaction with the directory. You typically rely on an application to ensure that the end user is in fact using the mechanisms in the way you intended.

To Reset a Password With the Password Modify Extended Operation

User accounts are locked when passwords expire. When you reset the password, you unlock the account. The password can be reset by another user such as an administrator. After password reset, Directory Server unlocks the user account. Directory Server provides support for RFC 3062, LDAP Password Modify Extended Operation. The extended operation enables you to allow a directory administrator or a directory application to unlock accounts through password reset.

Be cautious when allowing use of the password modify extended operation, as shown in this procedure. Limit access to administrators and applications that you trust. Do not allow passwords to travel over the network in clear text.

You cannot use DSCC to perform this task. Use the command line, as described in this procedure.

1. Give users access to a password administrator or to a password administration application.

2. Allow the password administrator access to use the password modify extended operation.

   The following commands set an ACI to allow members of a Password Managers role to use the password modify extended operation when connected over SSL:

   $ cat exop.ldif dn: oid=1.3.6.1.4.1.4203.1.11.1,cn=features,cn=config objectClass: top objectClass: directoryServerFeature oid: 1.3.6.1.4.1.4203.1.11.1 cn: Password Modify Extended Operation aci: (targetattr != "aci")(version 3.0; acl "Password Modify Extended Operation "; allow( read, search, compare, proxy ) (roledn = " ldap:///cn=Password Managers,dc=example,dc=com" and authmethod = "SSL");) $ ldapmodify -a -D cn=admin,cn=Administrators,cn=config -w - -f exop.ldif Enter bind password: adding new entry oid=1.3.6.1.4.1.4203.1.11.1,cn=features,cn=config $

   The entry under cn=features,cn=config allows you to manage access to operations that use the password modify extended operation.

3. Have the password administrator reset the user password.

   This step unlocks the user account, and can be completed with the ldappasswd(1) command.

4. (Optional) If the user must change the password, have the password administrator notify the user.

   Users must change their passwords after reset if the password policy that governs their entries includes pwdMustChange: TRUE.

To Allow Grace Authentications When Passwords Expire

This procedure describes how to give users grace authentications, allowing users to change passwords that have expired.

The grace authentications are intended to be managed by an application that handles password policy request and response controls. The procedure shows a simple example of how to use the control in an application.

You cannot use DSCC to perform this task. Use the command line, as described in this procedure.

1. Make sure that users have access to an application that uses password policy request and response controls.

   The application should ensure that users handle grace authentications properly.

2. Allow the application to use the password policy controls.

   The following commands set an ACI to allow members of a Password Managers role to use the password policy controls:

   $ cat ctrl.ldif dn: oid=1.3.6.1.4.1.42.2.27.8.5.1,cn=features,cn=config objectClass: top objectClass: directoryServerFeature oid: 1.3.6.1.4.1.42.2.27.8.5.1 cn: Password Policy Controls aci: (targetattr != "aci")(version 3.0; acl "Password Policy Controls "; allow( read, search, compare, proxy ) roledn = " ldap:///cn=Password Managers,dc=example,dc=com";) $ ldapmodify -a -D cn=admin,cn=Administrators,cn=config -w - -f ctrl.ldif Enter bind password: adding new entry oid=1.3.6.1.4.1.42.2.27.8.5.1,cn=features,cn=config $

   The entry under cn=features,cn=config has the sole purpose of allowing you to manage access to operations that use the password policy request and response controls.

3. Set pwdGraceAuthNLimit in the password policy to the number of authentications to allow after the password has expired.

4. Make sure that the application guides the end user to change the expired password promptly before grace authentications are exhausted.

Setting Account Properties

The following sections describe how to set the look-through limit, size limit, time limit and idle timeout of an account.

To Set the Look-Through Limit for an Account

1. Use the ldapmodify command to set the value of nsLookThroughLimit.

   The following command removes the look-through limit for Barbara Jensen:

   $ ldapmodify -D cn=admin,cn=Administrators,cn=config -w - Enter bind password: dn: uid=bjensen,ou=people,dc=example,dc=com changetype: modify add: nsLookThroughLimit nsLookThroughLimit: -1 ^D modifying entry uid=bjensen,ou=people,dc=example,dc=com ^D $

To Set the Size Limit for an Account

1. Use the ldapmodify command to set the value of nsSizeLimit.

   The following command removes the size limit for Barbara Jensen:

   $ ldapmodify -D cn=admin,cn=Administrators,cn=config -w - Enter bind password: dn: uid=bjensen,ou=people,dc=example,dc=com changetype: modify add: nsSizeLimit nsSizeLimit: -1 ^D modifying entry uid=bjensen,ou=people,dc=example,dc=com ^D $

To Set the Time Limit for an Account

1. Use the ldapmodify command to set the value of nsTimeLimit.

   The following command removes the time limit for Barbara Jensen:

   $ ldapmodify -D cn=admin,cn=Administrators,cn=config -w - Enter bind password: dn: uid=bjensen,ou=people,dc=example,dc=com changetype: modify add: nsTimeLimit nsTimeLimit: -1 ^D modifying entry uid=bjensen,ou=people,dc=example,dc=com ^D $

To Set the Idle Timeout for an Account

1. Use the ldapmodify command to set the value of nsIdleTimeout.

   The following command sets the idle timeout for Barbara Jensen to five minutes (300 seconds):

   $ ldapmodify -D cn=admin,cn=Administrators,cn=config -w - Enter bind password: dn: uid=bjensen,ou=people,dc=example,dc=com changetype: modify add: nsIdleTimeout nsIdleTimeout: 300 ^D modifying entry uid=bjensen,ou=people,dc=example,dc=com ^D $

Manually Locking Accounts

Directory Server allows you to configure password policy to force the lockout of accounts after a specified number of failed bind attempts. See Policy for Account Lockout for details. This section covers manual account locking and activation tools that the Directory Manager can use.

The Directory Manager can manage account lockout without using the lockout duration timer. The locked account remains locked until the password is manually reset. The Directory Manager can also render certain accounts inactive for an indefinite period of time.

This section shows how to check account status, render accounts inactive, and reactivate accounts.

To Check Account Status

Check account status as shown here.

You must bind as the Directory Manager.

You cannot use DSCC to perform this task. Use the command line, as described in this procedure.

1. Use the ns-accountstatus command to check the status the account or role.

   The following command checks Barbara Jensen's account status:

   $ ns-accountstatus -D "cn=Directory Manager" -j pwd.txt \ -I uid=bjensen,ou=people,dc=example,dc=com uid=bjensen,ou=people,dc=example,dc=com activated. $

   See the ns-accountstatus(1M) man page for details.

To Render Accounts Inactive

Render an account or a role inactive as shown here.

You must bind as the Directory Manager.

You cannot use DSCC to perform this task. Use the command line, as described in this procedure.

1. Use the ns-inactivate command to render the account or role inactive.

   The following command renders Barbara Jensen's account inactive:

   $ ns-inactivate -D "cn=Directory Manager" -j pwd.txt \ -I uid=bjensen,ou=people,dc=example,dc=com uid=bjensen,ou=people,dc=example,dc=com inactivated. $

   See the ns-inactivate(1M) man page for details.

To Reactivate Accounts

Unlock an account or a role as shown here.

You must bind as the Directory Manager.

You cannot use DSCC to perform this task. Use the command line, as described in this procedure.

1. Use the ns-activate command to reactivate the account or role.

   The following command renders Barbara Jensen's account active again:

   $ ns-activate -D "cn=Directory Manager" -j pwd.txt \ -I uid=bjensen,ou=people,dc=example,dc=com uid=bjensen,ou=people,dc=example,dc=com activated. $

   ns-activate(1M) man page for details.