Your password policy in Azure AD works a little differently compared to what you may be used to in on-premises Active Directory, as there is no direct control over complexity requirements. However, similar to Active Directory, the password policy is still enables you to define password length and lockout conditions, as well as providing additional features, including custom banned password lists.
In this tutorial, I am going to show you how to modify and increase the security of your password policy in Azure Active Directory.
What is the default Azure AD password policy?
The default password policy that is applied to all cloud-based user accounts cannot be modified beyond the editable options that I will walk you through in this tutorial. Below you can see the default settings for the built-in Azure AD password policy.
| Property | Requirements |
|---|---|
| Characters allowed | A – Z a – z 0 – 9 @ # $ % ^ & * – _ ! + = [ ] { } | \ : ‘ , . ? / ` ~ ” ( ) ; < > Blank space |
| Characters not allowed | Unicode characters |
| Password restrictions | A minimum of 8 characters and a maximum of 256 characters. Requires three out of four of the following: – Lowercase characters – Uppercase characters – Numbers (0-9) – Symbols (see the previous password restrictions) |
| Password expiry duration (Maximum password age) | Default value: 90 days. If the tenant was created after 2021, it has no default expiration value. You can check current policy with Get-MsolPasswordPolicy. The value is configurable by using the Set-MsolPasswordPolicy cmdlet from the Azure Active Directory Module for Windows PowerShell. |
| Password expiry (Let passwords never expire) | Default value: false (indicates that passwords have an expiration date). The value can be configured for individual user accounts by using the Set-MsolUser cmdlet. |
| Password change history | The last password can’t be used again when the user changes a password. |
| Password reset history | The last password can be used again when the user resets a forgotten password. |
By default, the settings applied above are not relevant for accounts synced to Azure Active Directory via Azure AD Connect as the password policy from your on-premise directory takes precedence. However, you can enforce the Azure AD Connect password policy to take effect… Check out my tutorial to Sync your Azure AD Password Policy with On-premise AD.
How to change password expiration in Azure AD
To change the password expiration for all users in Azure AD. Go to the Microsoft 365 admin center > Settings > Org Settings > Security & privacy > Password expiration policy. Here you can set passwords to never expire or define an expiration period.
To prevent the use of simple or predictable passwords, it is recommended that passwords are set to never expire and that you encourage or guide your users to set a secure password that is only used for Azure AD. Doing this as well as implementing basic security controls such as Multi-factor authentication is a lot more secure than enabling password expiration. If you want to know how to enforce Multi-factor authentication across your organisation, check out my tutorial on How to create a Conditional Access policy in Azure Active Directory.
Enable Password Protection in Azure AD
Password Protection in Azure AD provides additional security and control over your user’s password settings and lockout conditions. The features are quick and easy to configure and can provide effective management to prevent easy-to-guess passwords.
To access the Password Protection features in Azure AD, select Azure Active Directory > Security.
Under the Manage heading, select Authentication methods.
Then select Password Protection.
On the Password Protection page, you have the option to configure the Lockout threshold, which determines how many failed login attempts are failed until the account changes to the locked status. The Lockout duration determines how long your account will stay in the locked status and you have the option to implement a Custom banned password list to prevent easily guessable passwords.
Although I will not cover Password protection for WIndows Server Active Directory in this tutorial, to enable this you will require the Azure AD Password Protection DC agent or Azure AD Password Protection Proxy installed on a domain controller.
What happens when you implement a banned password list?
A Custom banned password list is a simple way to effectively block users from setting simple and easy-to-guess passwords, such as their name, the company name or similar variations of both. The Custom banned password list only allows up to 1000 list items so it is important to use this effectively.
When you enforce password protection, including your banned password list, if a user already has a password that is listed there will be no impact to that user, they can carry on working without interruption. However if a user then goes to change their password to one that is listed in the banned password list, they will be presented with the following error.
Create an effective Custom banned password list
Due to the password limit within the Custom banned password list, it is important that you define your list effectively, instead of just copying and pasting someone else’s from the internet. The passwords within your list should relate in some way to your staff or organisation, some examples include:
- Company name
- Company or staff locations
- Building or office name
- Specific terms, slogans or dialogue used by the company
- Names of products or services that the company provide
Normalization
When passwords in the list are evaluated, a normalization process occurs to detect if the entered password is found in the list. This means that variants of passwords within the list are also automatically detected and blocked.
For example, if you had the phrase ourcloudnetwork in the banned password list and someone used the password 0urC10udN3w0rk, it would be automatically blocked. This hugely expands the coverage provided by the banned password list in Azure AD.
Character substitutions can be found in the below table.
| Original letter | Substituted letter |
|---|---|
| 0 | o |
| 1 | l |
| $ | s |
| @ | a |
Fuzzy matching
A process called Fuzzy matching is also used to identify if a password should be allowed or banned. It does this by evaluating if the normalized password is found on the banned password list based on a character variance of 1.
For example, if the phrase ourcloudnetwork is listed in the banned password list, each of the following passwords would also be banned:
- 0urC10udN3w0rp – last letter ‘k’ has been replaced with a ‘p’
- 0urC10udN3w0rk6 – ‘6’ has been appended to the end.
- TurC10udN3w0rk – first character ‘0’ has been replaced with ‘T’
- 0urC10udN3w0r – final letter ‘k’ has been removed
- L0urC10udN3w0rk – ‘L’ has been appended to the beginning
Substring matching
Substring matching is used on the normalized password to detect if either the user’s first name, last name or the tenant name is found in the password, regardless if that information is found in the Custom banned password list.
For example, my name is Daniel Bradley in Azure Active Directory, if I try to reset my password to D@ni31network5, once it is normalized it becomes Danielnetwork5 and the password would be blocked from being used.
Conclusion
Modifying your password settings and implementing password protection is often overlooked when migrating to cloud-only or when you have been ‘getting by’ leaving the defaults in place. If you have Azure AD Premium P1 or P2 I highly recommend you take a look at your Password Protection settings in Azure AD and increase your password security now. These are high impact changes with zero interruption to production.
