Secure passwords
Users often create weak passwords by incorporating common local words like schools, sports teams, or famous personalities, making it easy for hackers to guess through dictionary-based attacks. To promote stronger password security within your organization, Azure Active Directory (Azure AD) Password Protection offers a comprehensive list of globally and custom-made banned passwords. If a password change request matches any of these banned passwords, it will fail.
To safeguard on-premises Active Directory Domain Services (AD DS) environments, Azure AD Password Protection can be set up to work with the companies’ on-premises domain controllers. This blog outlines the steps to help you eliminate bad passwords in your environment.[1]
How can Azure Active Directory Password Protection save the day?
When a user requests a password change, the new password is transmitted to a domain controller within the organization's Active Directory Domain Services (AD DS) environment. The domain controller’s agent password filter DLL, which is a component of the Azure AD Password Protection DC Agent, then receives the password.
The password filter DLL acts as a gatekeeper, responsible for validating the new password against the organization's Azure AD password policy. It does this by referencing the policy information that has been previously downloaded and cached from the Azure AD Password Protection Proxy server. This policy includes global and custom banned password lists and other configuration settings that have been defined by the organization's administrators.
To retrieve this policy information, the password filter DLL forwards a password policy download request to the Azure AD Password Protection Proxy server. This server is responsible for communicating with Azure AD and retrieving the most up-to-date password policy information, which is then cached on the domain controller.
Once the password filter DLL has the cached password policy information, it can then compare the new password against the policy requirements to determine whether it meets the necessary criteria. If the password passes the validation checks, the password filter DLL allows the password change to proceed. If the password fails to meet the requirements, the password change request is rejected, and the user must select a new password that meets the policy requirements.
What can Azure Active Directory Password Protection not do?
Azure AD Password Protection is limited to enforcing password policies only during the process of setting or changing passwords in clear text. Once a password is accepted by Active Directory, only authentication-protocol-specific hashes of that password are stored, and the clear-text password is never persisted. Therefore, Azure AD Password Protection cannot verify the strength of existing passwords.
Therefore, to improve password security, it is important to also take the following measures:
Prohibit the use of passwords listed in large, breached password databases such as "have I been pwned?"[1]
Ensure that two accounts do not have the same password.
Ensure that users’ already existing passwords are not weak.
Azure Active Directory Password Protection only addresses the following measure:
Prohibit the use of weak passwords like "CompanyName2023” or other custom banned passwowrds.
Prohibit the use of password listed in Microsoft global banned-password list, which is undisclosed.
Azure AD Password Protection is limited to enforcing password policies only during the process of setting or changing passwords in clear text. Once a password is accepted by Active Directory, only authentication-protocol-specific hashes of that password are stored, and the clear-text password is never persisted. Therefore, Azure AD Password Protection cannot verify the strength of existing passwords.
As Azure AD Password Protection is deployed, all users and accounts will eventually adopt a password that complies to the Azure AD Password Protection policy as their existing passwords expire over time. Alternatively, the process can be expedited by manually expiring user account passwords at one time.
Accounts that have been configured with the "password never expires" setting will not be compelled to change their passwords unless their passwords are manually expired.
It's also important for organizations to educate their employees on the importance of password security and provide training on how to create strong passwords. This can include tips such as using longer passwords with a mix of uppercase and lowercase letters, numbers, and symbols, avoiding the use of common words or phrases, and using a password manager to securely store and manage passwords.
What methods can be used to identify weak and shared passwords that already exist within our environment?
There are a variety of tools and methods available to help organizations detect and eliminate bad passwords that already exist within their environment.
An approach is to use specialized software tools that can detect and identify weak passwords, shared passwords, and known compromised passwords in Active Directory. These tools can help organizations identify vulnerable passwords and take proactive measures to improve password security. Examples of such tools:
Links to the tools:
I suggest implementing Get-bADpasswords and Azure AD Password Protection at a minimum. It's best to implement the DC Agent on all Domain Controllers and set Azure AD Password Protection in audit mode, which doesn't restrict weak passwords from being set but provides a clear indication of the effect the Azure Password Policy will have on the organization. This approach allows the company to gain insight into the password quality in Active Directory, as well as the ability to enable enforcement of the password policies after confirming what the impact will be during the password set/change process.
By implementing both Get-bADpasswords and Azure AD Password Protection, you can cover both on-premises users and Azure users. Furthermore, Get-bADpasswords is capable of detecting password sharing and existing weak passwords, while Azure AD Password Protection can prevent the creation of new weak passwords.
How to ensure that only strong passwords are allowed with Azure AD Password Protection
Azure AD provides a global banned password list that is based on the ongoing analysis of Azure AD security telemetry. When a user or administrator tries to change or reset their password, the new password is checked against this list, and if there is a match, the password change request fails. The default global banned password list cannot be edited.
In addition to the global banned password list, organizations can define a custom banned password list, which is limited to a maximum of 1000 terms that works alongside the global list to enforce strong passwords in your organization. The custom list can include organizational-specific terms such as brand names, product names, locations, internal terms, abbreviations, and months/weekdays in your company's local languages.
In order to optimize the effectiveness of the custom banned password list, it's important to consider that it has a limit of 1000 terms and is not designed to block extensive lists of passwords. Therefore, organizations can enhance the benefits of this list by evaluating Microsoft's password algorithm[1] to create their own custom list. Additionally, it's worth noting that a user's password may still be accepted even if it contains a banned term, as long as the password is strong enough overall. When a newly configured password is submitted, it undergoes a series of steps to evaluate its strength and determine whether it should be accepted or rejected:
Normalization
The initial step for a new password is to undergo normalization, which enables a limited number of banned passwords to be correlated with a broader range of potentially weak passwords.
Example:
The password ‘improsec’ is banned
A user requests a password change with ‘ImPr0s3c’
Although the password 'ImPr0s3c' is not included in the banned password list, it will still go through a normalization process which converts it to 'improsec'.
The password request would be rejected by the domain controller.
The normalization process involves converting all uppercase letters to lowercase and performing common character substitutions. This technique allows a small number of banned passwords to be associated with a wider range of passwords.
2. Check if password is considered banned
The password is further evaluated for patterns or characteristics, and based on this evaluation, a score is calculated. The resulting score is then used to determine whether the password change request is accepted or rejected. For this they use two methods:
Fuzzy matching behaviour
Rejects passwords within an edit distance of 1 of a banned term.
Substring matching
Rejects passwords that contains the user’s first and last name.
3. Score Calculation
The next step is to check the user's normalized new password for any banned passwords and assign points accordingly:
One point is given for each banned password found in the password.
One point is given for each remaining character that is not part of a banned password.
A password must have at least five (5) points to be accepted.
For instance, let's assume that Improsec has "improsec" on their custom banned password list and "blank" on the global list, and a user requests their password to be "ImPr0s3cBlank12". In the first example scenario, the password will be rejected:
After normalization, the password becomes "improsecblank12".
The matching process detects two banned passwords: "improsec" and "blank".
Thus, the password is given a score of:
[improsec] + [blank] + [1] + [2] = 4 points
As the password is under five (5) points, it is rejected.
In the second example scenario, a user changes their password to "Imqr0s3cBl@nkf9!", which will get accepted:
After normalization, the password becomes "imqrosecblankf9!".
The matching process detects two banned passwords: " improsec" and "blank".
Thus, the password is given a score of:
[improsec] + [blank] + [f] + [9] + [!] = 5 points
As the password is at least five (5) points, it is accepted.
End note
In summary, Azure Active Directory Password Protection provides organizations with a powerful tool to prevent bad and weak passwords, both by blocking commonly used passwords and by allowing the creation of custom banned password lists. By using Get-bADpasswords, organizations can also identify and eliminate existing weak passwords and shared passwords, further improving security. However, it's important to keep in mind that creating a custom banned password list that covers organizational-specific terms such as brand names, product names, locations, internal terms, abbreviations, and months/weekdays in your company's local languages is crucial. Additionally, organizations should review Microsoft's password algorithm to understand how the password protection works.
In addition to implementing Azure Active Directory Password Protection, it's also crucial for organizations to have a robust on-premises password policy and fine-grained password policy in place to enforce stronger password requirements for administrators and service accounts. These policies can help prevent privileged accounts from being compromised and reduce the risk of a security breach.
While strong passwords are important, end users must also be educated on the importance of creating secure passwords, such as passphrases. In addition to creating strong passwords, it's also important for end users to use password managers to securely store their passwords. Password managers can generate and store complex, unique passwords for each account, and can make it easier for users to log in securely without having to remember multiple passwords. Even with good passwords in place and password managers, multi-factor authentication should still be enforced to provide an extra layer of protection against unauthorized access. With these measures in place, organizations can significantly improve their password security posture and reduce the risk of cyber attacks, which ensures that their sensitive data and systems are adequately protected. Additionally, regularly reviewing and updating the password policies, custom banned password list, and other security measures can help organizations stay ahead of evolving threats and keep their systems and data secure.
Resources
The information presented in this post is a compilation of advice and knowledge sharing based on my experience of implementing this at various customer sites.
The content is primarily derived from the following sources:
https://learn.microsoft.com/en-us/azure/active-directory/authentication/concept-password-ban-bad
https://github.com/improsec/Get-bADpasswords
[1] https://learn.microsoft.com/en-us/azure/active-directory/authentication/howto-password-ban-bad-on-premises-deploy
[2] https://github.com/HaveIBeenPwned/PwnedPasswordsDownloader
[3] https://learn.microsoft.com/en-us/azure/active-directory/authentication/concept-password-ban-bad#how-are-passwords-evaluated