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 11g Release 1 (11.1.1) and previous Directory Server versions. When you create a Directory Server 11g Release 1 (11.1.1) 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.

The DS5–compatibility-mode password policy is deprecated. You must switch to DS6–mode password policy in this version.

For more information about setting the password compatibility mode, see Password Policy Compatibility.

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 Policy Compatibility

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.

Password policies measure password length by the number of bytes, so a password containing multi-byte characters can meet password-length policy even if the password contains fewer characters than the policy's specified minimum. For example, a 7-character password with one 2-byte character satisfies a password policy with password minimum length set to 8.

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 Oracle Fusion Middleware Deployment Planning Guide for Oracle Directory Server Enterprise Edition.

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 -v -i \ -w password-file | grep ^pwd-

   The password-file contains the password of directory manager.

   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 : instance-path/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

   The following command enables the policy that requires changing the password after a reset:

   # dsconf set-server-prop -p 20390 pwd-must-change-enabled:on

Preventing Binds With No Password

Directory Server prevents authentication with a null password. All non-anonymous binds must therefore specify a password to bind to the directory. Otherwise, Directory Server returns an authentication error, LDAP_INAPPROPRIATE_AUTH.

You can disable this feature by setting the server property require-bind-pwd-enabled to off using the dsconf set-server-prop command.

The default value of the Require Bind on Authentication feature is on. Check this by using the following command:

# dsconf get-server-prop -p 20390 -w /tmp/.pwd-file require-bind-pwd-enabled
require-bind-pwd-enabled  :  on

Authenticating with a null password results in the following error message:

# ldapsearch -D cn=altrootdn -w '' -p 20390 -b cn=config 'objectclass=*' dn
ldap_simple_bind: Inappropriate authentication
ldap_simple_bind: additional info: binds with a dn require a password

Note that this feature does not block anonymous binds:

# ldapsearch -p 20390 -b cn=config 'objectclass=*' dn
version: 1
dn: cn=SNMP,cn=config

Disable this feature by setting it to off:

# dsconf set-server-prop -p 20390 -w /tmp/.pwd-file require-bind-pwd-enabled:off
# dsconf get-server-prop -p 20390 -w /tmp/.pwd-file require-bind-pwd-enabled
require-bind-pwd-enabled  :  off

This time authenticating with a null password succeeds:

# ldapsearch -D cn=altrootdn -w '' -p 20390 -b cn=config 'objectclass=*' dn
version: 1
dn: cn=SNMP,cn=config

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 Oracle Fusion Middleware Upgrade and Migration Guide for Oracle Directory Server Enterprise Edition. 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.

   ---

   Note –

   The global password policy must set pwdMustChange(5dsat) to TRUE, that is, users must change their passwords when they first bind.

   $ dsconf set-server-prop -p port-no pwd-must-change-enabled:true

   ---

   $ 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.

Check the applied password policy settings by typing the following command:

# ldapsearch -D "cn=directory manager" -w - -b "cn=Password Policy,cn=config" -s base \
'(&(objectClass=ldapsubentry)(cn=Password Policy))'

version: 1
dn: cn=Password Policy,cn=config
objectClass: top
objectClass: ldapsubentry
objectClass: pwdPolicy
objectClass: sunPwdPolicy
objectClass: passwordPolicy
cn: Password Policy
pwdAttribute: userPassword
passwordStorageScheme: SSHA
passwordChange: on
pwdAllowUserChange: TRUE
pwdSafeModify: FALSE
passwordRootdnMayBypassModsChecks: off
passwordNonRootMayResetUserpwd: on
passwordInHistory: 0
pwdInHistory: 0
passwordMinAge: 0
pwdMinAge: 0
passwordCheckSyntax: off
pwdCheckQuality: 0
passwordMinLength: 6
pwdMinLength: 6
passwordMustChange: on  
pwdMustChange: TRUE 
passwordExp: off
passwordMaxAge: 0
pwdMaxAge: 0
passwordWarning: 86400
pwdExpireWarning: 86400
passwordExpireWithoutWarning: on
pwdGraceAuthNLimit: 0
pwdKeepLastAuthTime: FALSE
passwordLockout: off
pwdLockout: FALSE
passwordMaxFailure: 3
pwdMaxFailure: 3
passwordResetFailureCount: 600
pwdFailureCountInterval: 600
pwdIsLockoutPrioritized: TRUE
passwordUnlock: on
passwordLockoutDuration: 3600
pwdLockoutDuration: 3600

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

The following command lets Barbara Jensen change her own user password, connecting over simple authentication:

$ ./ldappasswd -h host -D uid=bjensen,ou=people,dc=example,dc=com \
-j old.pwd -T new.pwd -t old.pwd uid=bjensen,ou=people,dc=example,dc=com    

ldappasswd: password successfully changed

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.

   ---

   Caution –

   The DS5–compatibility-mode password policy is deprecated. You must switch to DS6–mode password policy in this version.

   ---

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 account is explicitly activated. 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 dsutil account-status command to check the status the account or role.

   The following command checks Barbara Jensen's account status:

   $ dsutil account-status -p port-number -w pwd.txt \ uid=bjensen,ou=people,dc=example,dc=com uid=bjensen,ou=people,dc=example,dc=com activated.

   See the dsutil(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 dsutil account-inactivate command to render the account or role inactive.

   The following command renders Barbara Jensen's account inactive:

   $ dsutil account-inactivate -p port-number -w pwd.txt \ uid=bjensen,ou=people,dc=example,dc=com uid=bjensen,ou=people,dc=example,dc=com inactivated. $

   See the dsutil(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 dsutil account-activate command to reactivate the account or role.

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

   $ dsutil account-activate -p port-number -w pwd.txt \ uid=bjensen,ou=people,dc=example,dc=com uid=bjensen,ou=people,dc=example,dc=com activated.

   dsutil(1M) man page for details.

Password Policy Compatibility

For migration purposes, the new password policy maintains compatibility with previous Directory Server versions by implementing a compatibility mode. The compatibility mode determines whether password policy attributes are handled as old attributes or new attributes, where old refers to Directory Server 5.2 password policy attributes.

This section contains information to help you set the compatibility mode and to decide which mode is appropriate for your deployment.

Setting the Compatibility Mode

The compatibility mode can be read using dsconf command as follows:

$ dsconf get-server-prop pwd-compat-mode

The pwd-compat-mode property can have one of the following values:

DS5-compatible-mode

The purpose of DS5-compatible-mode is to allow an existing replicated topology to be migrated from Directory Server 5.2 instances to Directory Server 11g Release 1 (11.1.1) instances. A Directory Server 11g Release 1 (11.1.1) instance in DS5-compatible-mode accepts updates containing either old or new password policy attributes, and produces updates containing both sets of attributes. Updates can arrive from an LDAP client or from replication, and changes are produced locally as a result of password policy evaluation (for example, as a result of a failed authentication or a password change). Note that any version 5.2 instance consuming replicated updates produced by a version 11g Release 1 (11.1.1) instance (either directly or through another instance) must have its schema updated with 00ds6pwp.ldif as described in Issues With the Password Policy in Oracle Fusion Middleware Upgrade and Migration Guide for Oracle Directory Server Enterprise Edition. While the Directory Server 5.2 instance will ignore any new attributes during password policy processing, when an entry containing the new attributes is modified at that instance, without the schema update, the schema check will fail when the modified entry is written.

DS6-migration-mode

DS6-migration-mode is an intermediate step between DS5-compatible-mode and DS6-mode, All policy decisions are based on the new password policy attributes and the old (Directory Server 5.2) password policy attributes are removed from the server's data. Since the number of policy configuration entries is small, the old password policy configuration attributes are cleaned from all policy entries as soon as the instance is advanced to DS6-migration-mode. However, the cleanup of a user entry is deferred until the entry is modified as part of normal password policy processing during a password modify operation. This approach allows the cleanup to proceed gradually, so as to not degrade the server's performance. The modifications necessary to remove any old policy attributes are not replicated so that they do not interfere with the operation of instances still in DS5-compatible-mode.

DS6-mode

A Directory Server instance in DS6-mode uses only new policy attributes in computing password policy decisions. Any old password policy attributes remaining in an entry are ignored.

The compatibility mode is set using the dsconf command as follows:

$ dsconf pwd-compat new-mode

The new-mode action takes one of the following values:

to-DS6-migration-mode

Change to DS6-migration-mode from DS5-compatible-mode.

Once the change is made, only DS6-migration-mode and DS6-mode are available.

to-DS6-mode

Change to DS6-mode from DS6-migration-mode.

Once the change is made, only DS6-mode is available.

The server state can move only towards stricter compliance with the new password policy specifications.

The DS5–compatibility-mode password policy is deprecated. You must switch to DS6–mode password policy in this version.

Guidelines for Choosing a Compatibility Mode

The pwd-compat-mode setting affects the internal server operation and is largely isolated from the password policy behavior seen by an LDAP client. In particular, the pwd-compat-mode setting does not affect the range of server responses to an LDAP client authentication (bind).

The configuration and operational attributes used to implement the password policy depend on the pwd-compat-mode setting. Therefore, an LDAP application that accesses the old (Directory Server 5.2) attributes will need to be modified prior to advancing the pwd-compat-mode beyond the initial DS5-compatible-mode.

DS5-compatible-mode is the default setting. If you upgrade an existing server to Directory Server 11g Release 1 (11.1.1) or if you create a new Directory Server 11g Release 1 (11.1.1) instance, the compatibility state is set to DS5-compatible-mode.

This section provides details about the compatibility mode appropriate to your Directory Server deployment.

New Directory Server 11g Release 1 (11.1.1) Deployment

If you install a standalone Directory Server instance or are deploying a new replicated topology, set the compatibility mode to DS6-mode to immediately take advantage of the features available in the new password policy implementation. Since a new Directory Server 11g Release 1 (11.1.1) instance is created with the compatibility mode set to DS5-compatible-mode, you will need to remember to advance the instance to DS6-mode before installing it into a replicated topology whose instances are already set to DS6-mode.

Migrating a Deployment to Directory Server 11g Release 1 (11.1.1)

If you are migrating an existing replicated topology, as long as at least one Directory Server 5.2 instance remains in the replication topology, all of the Directory Server 11g Release 1 (11.1.1) instances must be set to DS5-compatible-mode.

Once a replicated topology has been completely migrated (in DS5-compatible-mode), you can consider advancing from maintaining compatibility with the old password policy to using the new password policy exclusively. Moving from DS5-compatible-mode to DS6-mode occurs in two phases, which includes an intermediate stage in DS6-migration-mode. First, the Directory Server 11g Release 1 (11.1.1) instances must be left in DS5-compatible-mode for an entire password expiration cycle so that the user entries are populated with the new pwdChangedTime attribute. Any applications that depend on the old password policy attributes must also be migrated to the new attributes while the Directory Server 11g Release 1 (11.1.1) instances are in DS5-compatible-mode, since the old attributes are no longer available in DS6-migration-mode. At this point, the instances comprising the replicated topology can be advanced to DS6-migration-mode.

The second phase consists of running all instances of the replicated topology in the intermediate DS6-migration-mode to clean out the old operational attributes in the entries. This cleanup must occur before advancing from DS6-migration-mode to DS6-mode. Otherwise, the stale attributes will remain in the entries. To mitigate the overhead of cleaning the old password policy operational attributes, the Directory Server 11g Release 1 (11.1.1) instance only removes the attributes in conjunction with a password modify. Thus a simple approach to the cleanup, assuming the password expiration feature is enabled, is to leave the Directory Server 11g Release 1 (11.1.1) instances in DS6-migration-mode for an entire password expiration cycle. Finally, once the old password policy attributes have been cleaned from the entries, the instances can be moved to DS6-mode. Remember that the new Directory Server 11g Release 1 (11.1.1) instance is created and set to DS5-compatible-mode. You will need to remember to advance the instance to DS6-mode before installing it into a replicated topology whose instances are already at DS6-mode.

The following table shows the allowed combinations of Directory Server versions and password policy compatibility modes. Note that at most two variations are allowed in a replicated topology at any time. For example, if a topology contains a Directory Server 11g Release 1 (11.1.1) instance in DS5-compatible-mode and one in DS6-migration-mode, then those are the only two variants allowed: no legacy Directory Serverinstances or Directory Server 11g Release 1 (11.1.1) instances in DS6-mode are allowed.

Administrative Password Reset Classification

Password policy features such as must-change-on-reset (pwd-must- change-enabled) and administrative bypass of password quality checks (pwd-root-dn-bypass-enabled) depend on classifying the modification of the userPassword attribute as either a self-change or an administrative reset.

In Directory Server 5.2, by default, only the Directory Manager can perform an administrative reset of a user's password. Any other password change is considered as a self-change. Directory Server 5.2p4 introduced the password policy configuration attribute passwordNonRootMayResetUserpwd that, when enabled, limits the userPassword modify operations that are considered as a self-change to the following two cases:

1. A user is authenticated and changing the password of his or her own account.

2. An administrator changes the password, but the LDAP Proxied Authorization Control (http://www.ietf.org/rfc/rfc4370.txt) is set for the userPassword modify operation, and the proxied user DN is the target of the modify operation.

Any other password change is considered as an administrative reset. This feature eliminates the requirement of using Directory Manager for routine password administration, while the simple other-than- self (password change made by any other user but not by self) test avoids the complexity of a separate scheme to identify administrative users.

In this version, Directory Server evaluates password changes similar to Directory Server 5.2 with passwordNonRootMayResetUserPassword enabled. That is, Directory Server considers a password change as an administrative reset except for a user changing his or her own password, or when the proxied authorization control is used. Even though the passwordNonRootMayResetUserpwd attribute can be present in a Directory Server password policy configuration entry when the instance is in Directory Server 5.2 compatible mode, the attribute can not be modified and the feature is always enabled.

If your Directory Server 5.2 based LDAP application uses an administrative account other than Directory Manager to change a password on behalf of a user (that is, the change should be a self-change), when the application is used with Directory Server 7.0, the change will be considered as an administrative reset. You can restore the original behavior by using the LDAP Proxied Authorization Control (http://www.ietf.org/rfc/rfc4370.txt) with the userPassword modify operation. The proxied authorization control handles the operation as if it is invoked by the proxied user. The control is available in the LDAP C SDK (https://wiki.mozilla.org/LDAP_C_SDK) and LDAP SDK for Java (http://www.mozilla.org/directory/javasdk.html), and the ldapmodify command. Invoke the proxied authorization control using the ldapmodify command as follows:

$ ldapmodify -D <administrative-user-DN > -Y <proxied-user-DN>

The ldapmodify commands from other products might use a different flag, or might not support the proxied authorization control at all.