Password Policies
We may define an account as a user entry with a password. Then password policy is the collection of features to manage accounts. Password policy is enabled with the command
set password-policy = true;
Note that, as of SP10, password policy commands cannot be typed at the console, they must be included in a file which may be 'source'd interactively or, in the usual way, accessed at startup through the .dxi file.
Password Quality
One aspect of password policy is password quality.The aim here is to ensure that all passwords have a certain minimum quality. We may quantify the term quality by looking at the commands which relate to it.
set password-alpha = <number-chars>;
set password-alpha-num = <number-chars>;
set password-lowercase = <number-chars>;
set password-non-alpha = <number-chars>;
set password-non-alpha-num = <number-chars>;
set password-numeric = <number-chars>;
set password-uppercase = <number-chars>;
set password-max-repetition = <number-chars>; # maximum number of times a character may be repeated
set password-min-length-repeated-substring = <length-substring>;
set password-max-substring-repetition = <number-repetitions>;
set password-username-substring = true|false;
# define a list of attributes from the user's entry whose values cannot appear in the password
set password-substring-attrs = <attribute-list>;
set password-history = <number-passwords>;
Any of these may be turned off by setting parameter to 0 (except password-substring-attrs).
Password Currency
We may want to put limits on access to an account. Accounts may be in one of four states:
Active - this is the only state in which logins are allowed
Expired - the password has not been changed recently
Suspended - the user has tried unsuccessfully to login a number of times, or the user has not logged in recently
Locked - an administrator has locked the account
# the account will expire if the password is not changed
set password-age = <number-days>;
# the password cannot be changed again if it has been changed recently
set password-min-age = <number-days>;
# allow users to login with an expired password but needs the LDAP password control
set password-grace-logins = <number-logins>;
# add dxPwdIgnoreExpired with the value true to the entry and the password will not expire
set password-allow-ignore-expired = true;
# account will be suspended after this time
set password-last-use = <number-days>;
# the account will be suspended after this many unsuccessful attrempts to login
set password-retries = <number-retries>;
# the account will move from suspended to active after this many seconds
set password-max-suspension = <number-seconds>;
# add dxPwdIgnoreSuspended to the entry and it will never be suspended
set password-allow-ignore-suspended = true;
Password Administration
An administrator is able to vary the password policy in a number of ways.
To reactivate an account, simply change the user's password. Because the administrator is not the account owner, the state of the account is reset. Normally, an administrator can set a user's password to any string. To ensure that this password actually meets the minimum quality set by the policy applying to that account, use the following command.
set password-enforce-quality-on-reset = true;
An administrator can lock an account by adding the dxPwdLocked attribute to the account (user's entry). This facility needs to be enabled, though, as follows.
set password-allow-locking = true;
Password Proxy
If all authentication is done using a single login, password policy can still be enforced as if it were the account owner authenticating. This can be achieved with
set password-proxy-user = DN;
Interaction with LDAP Clients
When using an LDAP client aware of the LDAP password policy control (Behera draft), the DSA may return status information to the client. This facility is enabled with
set password-mimic-netscape-response-controls = true;
Now, we can enable two behaviours. Firstly, an LDAP client can prompt the user to change their password after a password reset. This is anabled with
set password-force-change = true;
Secondly, we can warn the user when their password is about to expire
set password-age-warning-period = true;
Default Values for Password Policy
set password-policy = true;
set password-retries = 3;
set password-min-length = 6;
set password-min-length-repeated-substring = 2;
This is the configuration equivalent to having only one password-policy configuration command, namely
set password-policy = true;
These defaults can be overridden by entering the three commands with different parameters.
Multiple Password Policies (New in 12.0 SP10)
It is now possible to set up multiple password policies. The default password policy is called Default. Without special action, password policy configuration commands apply to the default password policy. Therefore, SP10 can read the configuration of previous versions of DXgrid and behave in the expected manner.
To create other password policies we need the command
set target-password-policy = <string>, <precedence>;
This command establishes a new password policy called <string>. (<precedence>, a positive integer, is currently ignored.) This new password policy when created inherits the default password policy. However, further password policy commands will modify this password policy and not the default password policy.
An exception to this rule is that the following commands apply to all password policies.
set password-force-change = true;
set password-allow-locking = true;
set password-allow-ignore-expired = true;
set password-allow-ignore-suspended = true;
Multiple Password Policies Example
set password-policy = true;
set password-retries = 2;
set password-min-length = 8;
set password-alpha = 3;
set password-numeric = 2;
set password-non-alpha-num = 1;
set password-lowercase = 1;
set password-uppercase = 1;
set password-username-substring = true;
set password-substring-attr = title;
set password-history = 10;
set password-age = 60;
#
# new password policy which inherits the settings above
# set target-password-policy = <policy-name>, <precedence>;
# 'precedence' (1 = low) is included only for future enhancements
set target-password-policy = admin, 1;
# account won't be suspended
set password-retries = 0;
# password won't expire if dxPwdIgnoreExpired is added to the account (user entry)
set password-allow-ignore-expired = true;
We now have multiple password policies, including a default password policy. To use them, you add the dxPwdPolicy attribute to an account (a user entry) with the value of the name of a password policy. This password policy will then be applied when authenticating (LDAP bind request) and changing the password. If the policy named in the attribute is not defined, or the account does not contain this attribute, the default password policy is used.
To prevent users from changing the value of this attribute in their entry, it should be protected by access control. For example
set protected-items = { user-subtree = <o OzCorp><ou users> subtree = <o OzCorp><ou users> dxPwdPolicy };
Binding Through an Alias
Binding through an alias is not allowed in either the X.500 standards nor in the LDAP RFCs. However, some installations require the feature. It can be enabled with
set dereference-alias-on-bind = true;
When using this feature in conjunction with password policy, all password operations will take place on the real entry. So the password will be updated in the real entry and the password policy attributes will be updated here also.
The alias entry may point to an entry in another DSA ( a cross-DSA alias). To enable the password policy attributes to be updated in this case, we need the DSA trust flag trust-dsa-triggered-operations. This needs to be set on the DSA processing the request, that is, the one with the alias entry, not the one with the real entry.
Password History
When turning on password history, you should be aware of the resources required, particularly if using a large hash like salted SHA-512. To store a SHA-512 hash in the password history attribute will require 102 bytes in the DXgrid file. So, if you use a password storage method of ssha512 and a password history of 10, and supposing you have 1 million users, then you will need an extra gigabyte in the DXgrid file. It would be pointless to index the password history, but if you are indexing all attributes then the password history will use up an extra gigabyte of memory. Generally speaking, the password history may double your file and memory requirements.
Note, though, that a smaller hash like SHA-1 requires only a third the resources that SSHA-512 requires. Policy should dictate which hash you use, but you should be mindful of the extra resources that may be needed.