Temporary Password Rules password policy


Overview


One of the more popular options to increase authentication security is to use a temporary password. Such passwords are typically used for a unique registration. The purpose of this document is to describe a Temporary Password Rules support in 389-ds password policy with the following constraint:

Use cases


A user account inherit from a password policy that supports Temporary Password Rules. The administrator sets a registration password (userpassword) and communicates that registration password to the end user. Then the end user can authenticate with its user account using the registration password. The number of attempts to authenticate is limited and/or the period of time the registration password is valid.

An administrator wants to specify a same period of registration for a set of accounts. This although it is not possible to reset, at the exact same time, the registration password of all account.

Major configuration options and enablement


The password policy contains new configuration attributes:

By default TPR setting are disabled and no limit (#use / expiration / validity) is enforced

If passwordMustChange is enabled in the password policy of a user, Directory Server enforces the temporary password rules conditions after an administrator updates the userPassword attribute of that user.

dsctl supports new settings for global password policy (pwpolicy)

# configure global password policy to support temporary password rules such as
# a reset password is valid for 3 attempts, can be used 60sec after reset
# and expire 3600sec after reset
dsconf localhost pwpolicy set --pwptprmaxuse 3 --pwptprdelayexpireat 3600 --pwptprdelayvalidfrom 60

# read the configured values of global password policy
dsconf localhost pwpolicy get
Global Password Policy: cn=config
------------------------------------
...
passwordTPRMaxUse: 3
passwordTPRDelayExpireAt: 3600
passwordTPRDelayValidFrom: 60

# update the global policy to expire reset password after 10min
dsconf localhost pwpolicy set --pwptprdelayexpireat 600

dsctl supports new settings for local password policy (localpwp)

# configure a local password policy for 'demo_user' entry to support
# temporary password rules such as a reset password is valid for 5 attempts, can be used 5sec after reset
# and expire 1/2h after reset
dsconf localhost localpwp adduser --pwptprmaxuse 5 --pwptprdelayexpireat 1800 --pwptprdelayvalidfrom 5 "uid=demo_user,ou=people,dc=example,dc=com"

# read the configured values from the local password policy
dsconf localhost localpwp get uid=demo_user,ou=people,dc=example,dc=com
Local User Policy Policy for "uid=demo_user,ou=people,dc=example,dc=com": cn=cn\3DnsPwPolicyEntry_user\2Cuid\3Ddemo_user\2Cou\3Dpeople\2Cdc\3Dexample\2Cdc\3Dcom,cn=nsPwPolicyContainer,ou=people,dc=example,dc=com
------------------------------------
passwordTPRMaxUse: 5
passwordTPRDelayExpireAt: 1800
passwordTPRDelayValidFrom: 5

# update the policy to allow 10 uses of the reset password
dsconf localhost localpwp set --pwptprmaxuse 10 uid=demo_user,ou=people,dc=example,dc=com

Design


Implementation

During a bind (do_bind), similarly to account lockout policy, TPR policy should be enforced against the target entry. If TPR limits are overpass then bind returns LDAP_CONSTRAINT_VIOLATION. A difference with account lockout policy is that there is no delay (password policy ‘passwordLockoutDuration’) to unlock the account. If TPR limits have been overpassed, the account can no longer successfully bind until adminstrator assignes a new TPR registration password.

When the ‘userpassword’ is updated (update_pw_info) by an administrator and it exists a TPR policy, then the server flags that the entry has a TPR password with ‘pwdTPRReset: TRUE’. In addition it updates ‘pwdTPRExpTime’ and ‘pwdTPRUseCount’ according the password policy.

When the ‘userpassword’ is updated (update_pw_info) by a regular user, if ‘pwdTPRReset: TRUE’ then ‘pwdTPRExpTime’, ‘pwdTPRUseCount’ are removed.

Once ‘pwdTPRExpTime’ is set, it is enforced during further bind but does not need to be updated during enforcement. In the opposite ‘pwdTPRUseCount’ needs to be udpated on each bind. When a non admin user binds (need_new_pwd), the server increases ‘pwdTPRUseCount’. When bind fails (do_bind or send_ldap_results_ext ?), the server checks if the account has a TPR related attribute ‘pwdTPRUseCount’ and increase it.

TPR policy

TPR policy is set in the password policy with passwordTPRMaxUse, passwordTPRDelayExpireAt and passwordTPRDelayValidFrom. The password policy can be global (‘cn=config’) or local (‘pwdpolicysubentry’). The TPR policy trigger is that the administrator sets a temporary password that, once bound, the user must change. As a consequence the TPR policy also requires passwordMustChange: on. The password policy may look like:

dn: cn="cn=nsPwPolicyEntry,uid=jdoe,ou=people,dc=example,dc=com",
     cn=nsPwPolicyContainer,ou=people,dc=example,dc=com
objectclass: top
objectclass: extensibleObject
objectclass: ldapsubentry
objectclass: passwordpolicy
passwordMustChange: on
passwordTPRMaxUse: 3
passwordTPRDelayExpireAt: 3600
passwordTPRDelayValidFrom: 600


dn: uid=mark,dc=example,dc=com
userpassword: xxx
pwdTPRReset: true
pwdTPRUseCount: 0
pwdTPRValidFrom: 20210325103000Z
pwdTPRExpireAt: 20210325110000Z

With the account using this policy, the user can bind 3 times maximum. The bind being successful or not. The user has a window of 50 minutes to complete his registration. After the administrator set the ‘userpassword’, the user must wait 10 minutes before attempting a first bind and the user must bind within one hour.

After or before these limits any bind, using this account, will fail.

update of temporary password attribute

Reseting the password account also sets the TPR attributes ‘pwdTPRValidFrom’ and ‘pwdTPRExpireAt’ based on the current time. To allow a set of accounts to have the same values of ‘pwdTPRValidFrom’ and/or ‘pwdTPRExpireAt’. Those attributes, that are operational , are modifiable (no NO_USER_MODIFICATION in the schema). So an administrator having the rights to update those attributes can overwrite the computed values.

Updatable TPR attributes are: ‘pwdTPRUseCount’, ‘pwdTPRValidFrom’ and ‘pwdTPRExpireAt’

Schema Changes

The password policy (‘passwordPolicy’) offers new TPR releated attributes:

A user entry may contains TPR related operational attributes:

External Impact


Origin


https://bugzilla.redhat.com/show_bug.cgi?id=1626633

Author


tbordaz@redhat.com

Last modified on 2 April 2024