| Identity Management GuideChapter 12. Policy: Defining Password PoliciesAll users must have a password which they use to authenticate to the Kerberos domain. Identity Management defines and enforces rules about password complexity, password histories, and account lockouts in order to maintain security. IdM, by default, does not expose passwords to clients, even hashed passwords, for system security. 12.1. About Password Policies and Policy AttributesA password policy sets certain standards for passwords, such as the password complexity and the rules for changing passwords. A password policy minimizes the inherent risk of using passwords by ensuring that they meet adequate complexity standards to thwart brute force attacks and they are changed frequently enough to mitigate the risk of someone revealing or discovering a password. There are three main configuration areas that are defined within the password policy: The IdM password policy is enforced jointly by the KDC and the LDAP server. While the password policy is set in the LDAP directory and is based on 389 Directory Server password policy attributes, the policy is ultimately constrained by the KDC password policy framework. The KDC policy is less flexible than the 389 Directory Server policy framework, so the IdM password policy can only implement password policy elements supported in the KDC. Any other policy settings made within the 389 Directory Server are not visible or enforced in Identity Management. Password policies are assigned either globally or to groups in IdM, not to individual users. The password policy is assigned a weight, so that if a user belongs to multiple groups with different password policies, the policy with the highest priority will take precedence. Table 12.1. Password Policy Settings | Configuration Property | Command-Line Option | Description |
|---|
| Options for both the UI and CLI | | Minimum Password Lifetime | --minlife | Sets the minimum period of time, in hours, that a user's password must be in effect before the user can change it. This can prevent a user from changing a password and then immediately changing it to the original value. The default value is one hour. | | Maximum Password Lifetime | --maxlife | Sets the maximum period of time, in days, that a user's password can be in effect before it must be changed. The default value is 90 days. | | Minimum Number of Character Classes | --minclasses | Sets the minimum number of different classes, or types, of character that must exist in a password before it is considered valid. For example, setting this value to 3 requires that any password must have characters from at least three categories in order to be approved. The default value is zero (0), meaning there are no required classes. There are six character classes: Upper-case characters Lower-case characters Digits Special characters (for example, punctuation) 8-bit characters (characters whose decimal code starts at 128 or below) Number of repeated characters This weights in the opposite direction, so that if you have too many repeated characters you will not meet the quorum to satisfy the "level" expressed by krbPwdMinDiffChars.
| | Minimum Length of Password | --minlength | Sets the minimum number of characters for a password. The default value is eight characters. | | Password History | --history | Sets the number of previous passwords that are stored and which a user is prevented from using. For example, if this is set to ten, IdM prevents a user from reusing any of their previous ten passwords. The default value is zero (0), which disables password history. Even with the password history set to zero, users cannot reuse a current password. | | Options for the CLI only | | Priority | --priority | Sets the priority which determines which policy is in effect. The lower the number, the higher priority. Although this priority is required when the policy is first created in the UI, it cannot be reset in the UI. It can only be reset using the CLI. | | Maximum Consecutive Failures | --maxfail | Specifies the maximum number of consecutive failures to input the correct password before the user's account is locked. | | Fail Interval | --failinterval | Specifies the period (in seconds) after which the failure count will be reset. | | Lockout Time | --lockouttime | Specifies the period (in seconds) for which a lockout is enforced. |
12.2. Viewing Password PoliciesThere can be multiple password policies configured in IdM. There is always a global policy, which is created with the server. Additional policies can be created for groups in IdM. The UI lists all of the group password policies and the global policy on the Password Policies page. Using the CLI, both global and group-level password policies can be viewed using the pwpolicy-show command. The CLI can also display the password policy in effect for a user. 12.2.1. Viewing the Global Password PolicyThe global password policy is created with the server. This applies to every user until a group-level password policy supersedes it. Table 12.2. Default Global Password Policy | Attribute | Value |
|---|
| Max lifetime | 90 (days) | | Min lifetime | 1 (hour) | | History size | 0 (unset) | | Character classes | 0 (unset) | | Min length | 8 | | Max failures | 6 | | Failure reset interval | 60 | | Lockout duration | 600 |
12.2.1.1. With the Web UIClick the Policy tab, and then click the Password Policies subtab. All of the policies in the UI are listed by group. The global password policy is defined by the global_policy group. Click the group link. The global policy is displayed.
12.2.1.2. With the Command LineTo view the global policy, simply run the pwpolicy-show command with no arguments: $ ipa pwpolicy-show Group: global_policy Max lifetime (days): 90 Min lifetime (hours): 1 History size: 0 Character classes: 0 Min length: 8 Max failures: 6 Failure reset interval: 60 Lockout duration: 600 12.2.2. Viewing Group-Level Password Policies12.2.2.1. With the Web UIClick the Policy tab, and then click the Password Policies subtab. All of the policies in the UI are listed by group. Click the name of the group which is assigned the policy. The group policy is displayed.
12.2.2.2. With the Command LineFor a group-level password policy, specify the group name with the command: $ ipa pwpolicy-show examplegroup Group: global_policy Max lifetime (days): 90 Min lifetime (hours): 1 History size: 3 Character classes: 4 Min length: 8 Max failures: 3 Failure reset interval: 15 Lockout duration: 150 12.2.3. Viewing the Password Policy in Effect for a UserA user may belong to multiple groups, each with their own separate password policies. These policies are not additive. Only one policy is in effect at a time and it applies to all password policy attributes. To see which policy is in effect for a specific user, the pwpolicy-show command can be run for a specific user. The results also show which group policy is in effect for that user. $ ipa pwpolicy-show --user=jsmith Group: admins Max lifetime (days): 90 Min lifetime (hours): 1 History size: 0 Character classes: 0 Min length: 8 Max failures: 6 Failure reset interval: 60 Lockout duration: 600 12.3. Creating and Editing Password PoliciesA password policy can be selective; it may only define certain elements. A global password policy sets defaults that are used for every user entry, unless a group policy takes priority. A global policy always exists, so there is no reason to add a global password policy. Group-level policies override the global policies and offer specific policies that only apply to group members. Password policies are not cumulative. Either a group policy or the global policy is in effect for a user or group, but not both simultaneously. Group-level policies do not exist by default, so they must be created manually. It is not possible to set a password policy for a non-existent group. 12.3.1. Creating Password Policies in the Web UIClick the Policy tab, and then click the Password Policies subtab. All of the policies in the UI are listed by group. The global password policy is defined by the global_policy group. Click the group link. Click the Add link at the top. In the pop-up box, select the group for which to create the password policy. Set the priority of the policy. The higher the number, the lower the priority. Only one password policy is in effect for a user, and that is the highest priority policy. The priority cannot be changed in the UI once the policy is created. Click the Add and Edit button so that the policy form immediately opens. Set the policy fields. Leaving a field blank means that attribute is not added the password policy configuration. Max lifetime sets the maximum amount of time, in days, that a password is valid before a user must reset it. Min lifetime sets the minimum amount of time, in hours, that a password must remain in effect before a user is permitted to change it. This prevents a user from attempting to change a password back immediately to an older password or from cycling through the password history. History size sets how many previous passwords are stored. A user cannot re-use a password that is still in the password history. Character classes sets the different categories of character that must be used in the password. For example, a character class can be a number, special character, or capital; the complete list of categories is in Table 12.1, "Password Policy Settings". This is part of setting the complexity requirements. Min length sets how many characters must be in a password. This is part of setting the complexity requirements.
12.3.2. Creating Password Policies with the Command LinePassword policies are added with the pwpolicy-add command. $ ipa pwpolicy-add groupName --attribute-value For example: $ ipa pwpolicy-add exampleGroup --minlife=7 --maxlife=49 --history= --priority=1 Group: exampleGroupMax lifetime (days): 49Min lifetime (hours): 7Priority: 1 Setting an attribute to a blank value effectively removes that attribute from the password policy. 12.3.3. Editing Password Policies with the Command LineAs with most IdM entries, a password policy is edited by using a *-mod command, pwpolicy-mod, and then the policy name. However, there is one difference with editing password policies: there is a global policy which always exists. Editing a group-level password policy is slightly different than editing the global password policy. Editing a group-level password policy follows the standard syntax of *-mod commands. It uses the pwpolicy-mod command, the name of the policy entry, and the attributes to change. For example: [jsmith@ipaserver ~]$ ipa pwpolicy-mod exampleGroup --lockouttime=300 --history=5 --minlength=8 To edit the global password policy, use the pwpolicy-mod command with the attributes to change, but without specifying a password policy name. For example: [jsmith@ipaserver ~]$ ipa pwpolicy-mod --lockouttime=300 --history=5 --minlength=8 12.4. Managing Password Expiration LimitsPassword policies are applied at the time a password is changed. So, when a password is set, it conforms to the password policy in effect at that time. If the password policy is changed later, that change is not applied, retroactively, to the password. With password expiration periods, there are two attributes that are related: Changing the password expiration time in the password policy does not affect the expiration date for a user, until the user password is changed. If the password expiration date needs to be changed immediately, it can be changed by editing the user entry. To force the expiration date to change, reset the krbPasswordExpiration attribute value for the user. This can be done using the IdM CLI with the --setattr option: [bjensen@ipaserver ~]$ kinit[bjensen@ipaserver ~]$ ipa user-mod jsmith --setattr=krbPasswordExpiration=20121231011529Z If the new expiration date should be applied to multiple entries, it may be simpler to use ldapmodify and edit multiple entries simultaneously through an LDIF file in the -f option. For example, editing a single entry (with a modify statement similar to the LDIF file in -f): [bjensen@ipaserver ~]$ ldapmodify -Y GSSAPI -h ipaserver.example.com -p 389 -vvdn: uid=jsmith,cn=users,cn=accounts,dc=example,dc=comchangetype: modifyreplace: krbpasswordexpirationkrbpasswordexpiration: 20140202203734Z- If an administrator resets a password, it expires the previous password and forces the user to update the password. When the user updates the password, it automatically uses the new password policies, including a new expiration date. 12.5. Changing the Priority of Group Password PoliciesA user may belong to multiple groups, each with different password policies. Since only one policy can be in effect for a user, there has to be a method to assign precedence to policies. That is done through priority. The highest priority is zero (0). The lower the number, the higher the priority. This is set initially when the password policy is created. It can be modified after the policy is created by resetting the --priority option. $ ipa pwpolicy-mod examplegroup --priority=10 When a user belongs to multiple groups, the group password policy with the lowest number has the priority. The password policy priority cannot be changed in the UI after it is created. 12.6. Setting Account Lockout PoliciesA brute force attack occurs when a malefactor attempts to guess a password by simply slamming the server with multiple login attempts. An account lockout policy prevents brute force attacks by blocking an account from logging into the system after a certain number of login failures - even if the correct password is subsequently entered. These attributes are available in the password policy form when a group-level password policy is created or when any password policy (including the global password policy) is edited. Click the Policy tab, and then click the Password Policies subtab. Click the name of the policy to edit. Set the account lockout attribute values. There are three parts to the account lockout policy: The number of failed login attempts before the account is locked (Max Failures). The time after a failed login attempt before the counter resets (Failure reset interval). Since mistakes do happen honestly, the count of failed attempts is not kept forever; it naturally lapses after a certain amount of time. This is in seconds. How long an account is locked after the max number of failures is reached (Lockout duration). This is in seconds.
There are three parts to the account lockout policy: The number of failed login attempts before the account is locked (--maxfail). How long an account is locked after the max number of failures is reached (--lockouttime). This is in seconds. The time after a failed login attempt before the counter resets (--failinterval). Since mistakes do happen honestly, the count of failed attempts is not kept forever; it naturally lapses after a certain amount of time. This is in seconds.
These account lockout attributes can all be set when a password policy is created with pwpolicy-add or added later using pwpolicy-mod. For example: [jsmith@ipaserver ~]$ kinit admin[jsmith@ipaserver ~]$ ipa pwpolicy-mod examplegroup --maxfail=4 --lockouttime=600 --failinterval=30 12.7. Enabling a Password Change DialogThere may be situations when a user exists in Identity Management but does not have a valid Kerberos ticket, meaning he cannot authenticate to the IdM domain. This is possible for new users or for users whose domain passwords have expired. Much like enabling password authentication in the web UI, it is possible to enable password-based authentication to the client. This opens up a password change dialog box to allow the user to reset the expired password. The password change dialog is enabled by using OpenSSH's challenge-response authentication. The challenge-response dialog is optional. In many environments, it is not necessary because SSSD can handle changing expired passwords by invoking the required PAM modules. However, using the challenge-response option in OpenSSH makes it possible to do password changes directly in PAM and to support full PAM conversations. This is not enabled by default, but it can be enabled by editing the OpenSSH configuration. Open the /etc/ssh/sshd_config file. Set ChallengeResponseAuthentication to yes.
|
| |
