Password Policies

Document created by birjo05 Employee on Nov 28, 2012
Version 1Show Document
  • View in full screen mode

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.