Oracle® Fusion Middleware Administrator's Guide for Oracle Directory Server Enterprise Edition 11g Release 1 (11.1.1.7.0) Part Number E28972-01 |
|
|
PDF · Mobi · ePub |
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.6) and previous Directory Server versions. When you create a Directory Server 11g Release 1 (11.1.1.6) 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.
Caution:
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:
This section explains password policy settings and provides a worksheet to help you define password policies that fit your requirements.
Note:
To use the default password policy, see Managing the Default Password Policy.
When you specify a password policy in Directory Server, you either modify or create an entry that includes the object class pwdPolicy.
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.
Note:
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.
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 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 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 to specify how long Directory Server should wait between tries before cleaning out the records of failed attempts. You use pwdLockoutDuration 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 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 the Deployment Planning Guide for Oracle Directory Server Enterprise Edition.
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, 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 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 to specify how many passwords Directory Server remembers. You can also prevent users from changing their passwords too often by setting pwdMinAge.
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, 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.
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.
You can also enforce a check that passwords meet your definition of minimum password quality, by setting pwdCheckQuality. 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 set. You can enforce that passwords have at least a specified number of characters by setting pwdMinLength. 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
.
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.
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 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. 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 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 covers the use of the password policy attribute pwdKeepLastAuthTime.
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 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.
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.
Password Policy Worksheet |
---|
Password Policy Entry Distinguished Name |
|
Policy Area | Attribute | Write Your Settings Here | Write Your Rationale for Settings Here |
---|---|---|---|
Account Lockout |
|||
|
|
||
|
|
||
|
|
||
|
|
||
Password Changes |
|
|
|
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
Password Content |
|
|
|
|
|
||
Password Expiration |
|
|
|
|
|
||
|
|
||
Tracking Last Authentication Time |
|
|
Note:
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.
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.
dsconf
Server PropertiesThe following table shows the password policy attributes and related dsconf
server properties for each password policy area.
Policy Area | Policy Attribute | dsconf Server Property |
---|---|---|
Account Lockout |
|
|
|
|
|
|
|
|
|
|
|
Password Changes |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Password Content |
|
|
|
|
|
|
|
|
Password Expiration |
|
|
|
|
|
|
|
|
Tracking Last Authentication Time |
|
|
Note:
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
.
You can view default password policy settings with the dsconf
command.
You can use the web interface Directory Service Control Center (DSCC) to perform this task.
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 : SHA256
pwd-supported-storage-scheme : SHA512
pwd-supported-storage-scheme : SHA
pwd-supported-storage-scheme : SSHA
pwd-supported-storage-scheme : SSHA256
pwd-supported-storage-scheme : SSHA512
pwd-supported-storage-scheme : CLEAR
pwd-user-change-enabled : on
You can change the default password policy by setting server properties with the dsconf
command.
Note:
Before completing this procedure, read and complete the Worksheet for Defining Password Policy.
You can use the web interface Directory Service Control Center (DSCC) to perform this task.
Translate the settings from your worksheet into dsconf
command property settings.
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
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
Specialized password policies are defined in a pwdPolicy 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 attribute in the desired user entry.
This section covers these topics:
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 and object class sunPwdPolicy.
Note:
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.
After your upgrade is complete, you use the new password policy in fully featured mode, as described in the 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 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, 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. 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.
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 the web interface Directory Service Control Center (DSCC) to perform this task.
Before You Begin
Example data as shown here is from Example.ldif
unless stated otherwise.
Complete a password policy worksheet for the policy you want to create.
See Worksheet for Defining Password Policy for a sample.
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.
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.
This procedure assigns an existing password policy to a single user account.
Note:
To complete this procedure, you must have a specialized password policy to assign. See To Create a Password Policy.
You can use the web interface Directory Service Control Center (DSCC) to perform this task.
Example data shown here is from Example.ldif
unless stated otherwise.
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
.
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.
Note:
To complete this procedure, you must have a specialized password policy to assign. See To Create a Password Policy.
You can use the web interface Directory Service Control Center (DSCC) to perform this task.
Example data shown here is from Example.ldif
unless stated otherwise.
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
.
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
.
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.
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 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
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.
Define new accounts as accounts that have a pwdReset attribute set to TRUE
.
When a user's password is changed by another user, such as a password administrator, pwdReset
is set to TRUE
.
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
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 8-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
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 command to change the password. This command provides support for safe password modification. This command implements RFC 3062, LDAP Password Modify Extended Operation (http://www.ietf.org/rfc/rfc3062.txt
)
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.
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.
Note:
Directory Server updates the operational attribute pwdChangedTime 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.
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 (http://www.ietf.org/rfc/rfc3062.txt
). 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.
Give users access to a password administrator or to a password administration application.
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.
Have the password administrator reset the user password.
This step unlocks the user account, and can be completed with the ldappasswd command.
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
.
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.
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.
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.
Set pwdGraceAuthNLimit
in the password policy to the number of authentications to allow after the password has expired.
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.
The following sections describe how to set the look-through limit, size limit, time limit and idle timeout of an account.
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 $
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 $
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 $
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
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.
Check account status as shown here.
Note:
You must bind as the Directory Manager.
You cannot use DSCC to perform this task. Use the command line, as described in this procedure.
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 man page for details.
Render an account or a role inactive as shown here.
Note:
You must bind as the Directory Manager.
You cannot use DSCC to perform this task. Use the command line, as described in this procedure.
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 man page for details.
Unlock an account or a role as shown here.
Note:
You must bind as the Directory Manager.
You cannot use DSCC to perform this task. Use the command line, as described in this procedure.
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 man page for details.
Directory Server 5.2 uses a set of password policy attributes. In Directory Server 6.0, a new set of password policy attributes was introduced. The Directory Server is now able to manage both sets of password policy attributes in order to maintain compatibility. Depending on the value of pwp-compat-mode
, a server is able to replicate correctly with other servers.
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.
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.7.0) instances. A Directory Server 11g Release 1 (11.1.1.7.0) 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.7.0) instance (either directly or through another instance) must have its schema updated with 00ds6pwp.ldif
as described in Issues With the Password Policy in the 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.
This section provides details about the compatibility mode appropriate to your Directory Server deployment.
pwd-compat-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 must be modified prior to advancing the pwd-compat-mode
beyond the initial DS5-compatible-mode
.
The DS5-compatibility-mode
password policy is deprecated. You must switch to DS6-mode password policy in this version.
DS5-compatible-mode
is the default setting. If you upgrade an existing server to Directory Server 11g Release 1 (11.1.1.7) or if you create a new Directory Server 11g Release 1 (11.1.1.7) instance, the compatibility state is set to DS5-compatible-mode
.
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.7) 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
.
If you are migrating an existing replicated topology, and if at least one Directory Server 5.2 instance remains in the replication topology, then all of the Directory Server 11g Release 1 (11.1.1.7) 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
.
Any applications that depend on the old password policy attributes must be migrated to the new attributes while the Directory Server 11g Release 1 (11.1.1.7) 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
and cleaning out the old operational attributes in the entries. Use one of the following methods:
Manually Deleting DS5-Mode Password Policy Operational Attributes
Programmatically Running DS5-Mode Password Policy Operational Attributes in DS6-Mode
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.7) 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.7) 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.7) 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.7) instance in DS5-compatible-mode
and one in DS6-migration-mode
, then those are the only two variants allowed: no legacy Directory Server instances or Directory Server 11g Release 1 (11.1.1.7) instances in DS6-mode
are allowed.
Table 8-1 Directory Server Password Policy Mode Interoperability
Directory Server 5.2 | Directory Server 11g Release 1 (11.1.1.x) in DS5-compatible-mode |
Directory Server 11g Release 1 (11.1.1.x) in DS6-migration-mode |
Directory Server 11g Release 1 (11.1.1.x) in DS6-mode |
|
---|---|---|---|---|
Directory Server 5.2 |
X |
X |
||
Directory Server 11g Release 1 (11.1.1.6) in |
X |
X |
X |
|
Directory Server 11g Release 1 (11.1.1.6) in |
X |
X |
X |
|
Directory Server 11g Release 1 (11.1.1.6) in |
X |
X |
If the server is in DS6-migration-mode,
you can run the rewrite
command with the convert-pwp-opattr-to-DS6
flag as an alternative to manually cleaning up the password policy attributes as described in Section 8.8.2.3.1, "Manually Deleting DS5-Mode Password Policy Operational Attributes." However, the request is rejected if the server is in DS5-compatible-mode
or in DS6-mode
When the convert-pwp-opattr-to-DS6
flag is set to on,
the server permits all DS5-mode
password policy attributes, based on their Internet Draft (ID) equivalents, to run in DS6-mode
.
To set the convert-pwp-opattr-to-DS6
flag, run the following command on each server that is already in DS6-migration-mode
in the topology:
$ dsconf rewrite -f convert-pwp-opattr-to-DS6=on
Alternatively, you can run the following command off-line:
$ dsadm rewrite -f convert-pwp-opattr-to-DS6=on /my/instance/path o=mysuffix.com
After the server migration is successfully completed, you can safely switch to DS6-mode
whenever you are ready to make that swtich.
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:
A user is authenticated and changing the password of his or her own account.
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>
Note:
The ldapmodify
commands from other products might use a different flag, or might not support the proxied authorization control at all.