- 11 Nov 2024
- 7 Minutes to read
- Print
- DarkLight
Password Policy Enhancement - What's New?
- Updated on 11 Nov 2024
- 7 Minutes to read
- Print
- DarkLight
Password Policy Enhancement - What's New?
Starting with the 2023.05.0 release and continued with 2023.07.0, RapidIdentity will be implementing a series of enhancements to Password and Authentication Policies. The objective is to provide Administrators with increased flexibility and functionality when creating and assigning polcies to Users within RI, while ensuring a positive User Experience.
Redesigned Administrator Interface
From the Password Policy Manager landing page, through each screen in the Password Configuration process, a redesigned interface has been put into place to improve the user experience. The Default Password Policy is located at the top of the screen, easy to locate and edit. To create custom password policies to be applied to specific user groups in your organization, start the configuration by clicking the 'Add Policy' button. Once created, they will be listed on the Password Policy Manager page and can be arraigned in the proper order based on priority.
Password Expiration
Located on the 'General' tab, Administrators are now able to include Password Expiration when configuring a policy.
There are two settings included for Password Expiration:
- PASSWORD MAXIMUM AGE: This value determines the maximum amount of time that a password will remain valid for a user. Once this duration has elapsed, the user will be forced to reset their password according to the policy settings.
- The Default value for this is None, which signifies that the password will not expire. Leaving this value as None ensures that the currently user experience will remain in place.
- EXPIRATION WARNING: This value determines the number of days in advance that a user will be notified that their password will be expiring.
- This field will be greyed out if the Password Maximum Age is set to None. Once active, the default value for this field is 7 days.
When a User has a Password Policy that includes a Password Expiration setting, the evaluation of the age of the Password is at time of login. The last ‘changed password date’ timestamp (pwdLastSet attribute) is evaluated against the Max Password age to confirm that it is still valid. When the age of the password is longer than the Maximum Password age, the User will be forced to change their password on their next login.
If the Password Maximum Age is changed after the policy is enabled, the updated value (none to 365 days) is what is evaluated against the last ‘changed password date’. Note that in this case if a users password is already over 365 days old, they would be prompted to change their password immediately on their next login.
At the time of the 2023.07.0 release, password expiration notifications are not provided in the UI. Users will be prompted to change their password on their first login attempt after it has expired. This is a feature that will be enhanced in a future release.
Restrict Password Use
On the Restricted Passwords tab, Adminstrators now have the ability to employ a Password History to preclude users from reusing password.
The value selected for 'Passwords Remembered' determines how many previous passwords cannot be reused by a user. For example, if this value is set to 5, then a user will not be able to reuse any of their last five previous passwords.
The Default value for this field will be No Restriction, signifying that there is no limit on reusing passwords. Keeping this default value in place will result in no change for your the user experience persisting.
When configuring a Password Policy, Administrators will now see a tab for 'Account Lockout Policy'. The Account Lockout Policy gives Administators to configure granular permissions to enforce automatic locking and unlocking of Users who have unsuccessful authentication events. No longer just applying to Password Attempts, this provides a layer of security against brute force attacks for all authentication methods.
In order to support the needs of a diverse population, Administrators may need to configure a series of Password Policies with seperate criteria. Let's take a closer look at the criteria available for the Account Lockout Policy, and how it can affect a User's Experience.
Failed Attempts
The number of failed attempts selected will determine how many chances a User will be provided before triggering a lockout event. When setting this criteria, we want to be cognizant of the Users being affected by the policy. Younger Users may need a higher number, as they have a higher tendency to experience accidental password issues. Older Users and Adults can withstand a lower number, and this will provide increased protection for their accounts.
Within
This criteria is a duration of time for which the database is tracking failed attempts. Once the time period lapses, the counter for failed attempts returns to zero. This criteria works in tandem with the number of failed attempts to determine the level of stringency for the policy. Please be sure to consider these criteria together when configuring the policies to ensure they are appropriate for the Users they will affect.
Automatically Unlock After
Once a User triggers a lock of their account after the specified amount of failed attempts in the stated length of time, they will be locked for the duration of time stated in the last criteria. The duration options range from 5 minutes to 'Never'. If 'Never' is selected, this will keep the account locked until an Administrator manually unlocks the account. As we consider this criteria, we will want to balance interruption of instructional time with appropriate security settings.
The lockout timer resets every time a user attempts to log in during that time period. Admins should keep this in mind when they configure this. If a user is continuous locked out due to attempting to log in before the time period has elapsed, they can be manually unlocked in the People Module. This will reset the number of failed attempts to zero, and allow the user in immediately.
Known Effective Changes for Current Policies
Handling of Criteria for Users that fall into Multiple Policies
Previously, the prioritization of multiple policies determined which criteria would be enforced for a User in multiple policies. This has been updated to enforce the most stringent criteria assigned to a User through multiple policies.
The policy values that are considered when determining the "most strict" policy to apply are:
Location of value in Password Policy Manager | Description of Value | How Value is Evaluated and Applied | Example |
---|---|---|---|
Account Lockout Policy → Account Lockout Criteria → Lockout For | Duration of Time an Account is automatically locked out set in Account Lockout Policy Criteria | Longest Time Duration is applied to account | User falls under Policy A with lockout of 5 min and Policy B with lockout of 10 min. User will be locked out 10 minutes. |
Restricted Passwords → Restrict Password Reuse → Passwords Remembered | Number of Passwords Remembered to set Restricted Password Reuse | Highest Number of Passwords Remembered that cannot be reused will be applied to account | User falls under Policy A with Passwords Remember setting of 5 and Policy B with a setting of 10. User will be unable to reuse any of their last 10 passwords. |
General → Password Expiration → Password Maximum Age | Number of Days set for Maximum Password Age | Shortest length of time (in days) before an automatic Password Reset is triggered | User falls under Policy A with password maximum age of 30 days and Policy B with password maximum age of 60 days. User's password would expire after 30 days. |
General → Password Expiration → Expiration Warning | Number of Days set for Expiration Warning | Longest length of time (in days) will be used to warn the account holder that an automatic Password Reset is approaching | User falls under Policy A with an advanced warning period of 10 days and Policy B with an advanced warning period of 20 days. User will be informed of approaching required password reset 20 days prior. |
LDAP Lockout Attribute in Connect
If the LDAP Lockout Attribute is being used by any action sets in Connect, this will need to be updated to reflect the updated attributes. Using the new policy attributes will result in LDAP not being updated when an account is locked out.
Utilizing an Overlay with custom lockout policies
If your district utilizes an Overlay with custom lockout policies, this policy will need to be updated in RapidIdentity to continue to function as desired.