Azure AD Password Policy – Complete Guide

Azure AD Password policies help you to secure your Microsoft 365 tenant. The policy defines how strong a password must be when they expire, and how many logins attempts a user can do before they are locked out.

With cloud-only accounts, you can’t change the password policy. But when you have a local domain-joined Windows server then you can use local policies to overwrite the Azure AD policy.

In this article, we are going to take a look at the default Azure AD Password Policy. And how you can install and use the Active Directory Administrative Tools to create a custom policy.

Default Azure AD Password Policy

Microsoft has a pre-defined password policy that is used for all cloud-only Office 365 accounts. Cloud-only means that you create and manage your user accounts from the Microsoft 365 Admin Center. The other option is a hybrid environment, where you synchronize your user accounts between Office 365 and your local domain controller.

The Aure Active Directory Password Policy requirements are:

Password lengthMinimum 8 characters – max 256
Password complexityThree out of the four following:
– lowercase character
– uppercase character
– number
– symbol
Allow characters– A – Z
– a – z
– 0 – 9
– @ # $ % ^ & * – _ ! + = [ ] { } | \ : ‘ , . ? / ` ~ ” ( ) ; < >
– blank space
Password expiresNot (can be changed)
Password expiry duration90 days (only when password expiry is enabled)
Password expiry duration notification14 days before the password expires
Password historyLast password can’t be used again
Password reset historyLast password can be used when the user has forgotten the password.
Lockout threshold10 (the account is locked after 10 failed login attempts)
Lockout duration60 seconds
azure ad password policy

Most part of the password policy can’t be changed when using cloud-only accounts. You can only enable password expiration and change the duration. If you have an Azure AD Premium plan in your Office 365 license then have a couple of more options when it comes to password protection.


Using password expiration is not recommened. It will result in users that use predicatable password, and it doesn’t give any security benefits. When password are stolen after a succesfull phishing attempt they are almost always used immidiately by cybercriminals.

Enable Azure AD Password Expiration

By default, password expiration is disabled in Office 365. But even though it’s not recommended, you can still enable password expiration for your tenant. There are no license requirements for this, you only need to have access to the Microsoft 365 admin center.

  1. Open Microsoft 365 Admin Center
  2. Open Settings > Org settings
  3. Click on the Security & Privacy tab
  4. Open the Password Expiration Policy
azure ad password policy
  1. Enable “Set user passwords to expire after a number of days”
  2. Optionally, change the number of days before the password expires and the notification.
  3. Click Save to apply the settings

Using PowerShell to set the Password Policy

We can also use PowerShell to enable password expiration in Microsoft 365. For this we are going to need the Msol module in PowerShell, make sure that you have installed it.

To enable the password expiration we will need to set the validityperiod and notificationdays of the password policy:

# Connect to Msol services

# Set and enable the password expiration policy
Set-MsolPasswordPolicy -DomainName -ValidityPeriod 180 -NotificationDays 30

Azure Password Protection

Azure Password Protection helps to keep your accounts safe. It determines after how many failed login attempts an account locks out and it allows you to create a custom banned password list. Words added to the custom banned password list can’t be used in the password that users create.


You can use this Microsoft 365 overview to check if your license has an Azure AD Premium plan.

To change the Azure AD Password Protection settings we will need to open the Azure AD portal:

  1. Go to
  2. Open the Azure Active Directory
  3. Click on Security > Authentication Methods >Password Protection
Azure AD Password Protection
Azure AD Password Protection
  1. Here you can change the lockout threshold, which defines after how many attempts the account is locked out
  2. The lock duration defines how long the user account is locked in seconds
  3. To use a custom banned password list, enable the Enfore custom list setting and define the words that you want to ban.

Change Azure AD Password Policy

It’s not possible to change the Azure AD Password policy if you only have cloud-based user accounts. There is however an option to change the password policy, but for that, you will need a local server, that is synced with Azure AD. Because Azure Active Directory will follow the password policy of your local domain controller.

Before we continue, in the example below I already have set up a domain controller that is synced with Azure AD.

  1. On your domain controller open Active Directory Administrative Center
  2. Click on your local domain
  3. Open the Password Settings Container in the System container
  1. On the right side, click on New and select Password Settings
  1. We can now change the password policy. Make sure you set the precedence to 1 to override the default password policy.


The account lockout settings only applies the the local domain and not to the Azure AD. This means that the default Azure AD lockout settings will be used for failed sign-ins in Office 365.
Change Password Policy
Change Password Policy
  1. Under Directly Applies to click on Add
  2. Select a Group to apply the policy to. I have chosen all Domain Users here
Apply Password Policy to a Group
Apply Password Policy to a Group
  1. Click ok to save and apply the password policy

The password policy will automatically be synced to Azure AD.

Wrapping Up

The default Azure AD password policy that is used for Office 365 cloud-only accounts is strong enough for most use-cases. If you really need to change the minimum password length then your only option is to use a local domain controller and use Azure AD Sync to synchronize the policy settings.

If you have any questions just drop a comment below.

32 thoughts on “Azure AD Password Policy – Complete Guide”

  1. Hi, Good article. A question. Could you add some notes and feedback regarding the following option for the Hybrid (synced) environment On-Premises AD and Azure AD: “Get-MsolDirSyncFeatures -> System.Runtime.Serialization.ExtensionDataObject EnforceCloudPasswordPolicyForPasswordSyncedUsers” ?

  2. Is a new password policy enforced right away? Meaning, will all targeted users have to reset their password right away if it doesn’t meet the new complexity?

    Ideally, we would like to let the user passwords expire before they have to reset and meet the new complexity requirements.


  3. As per the new requirement we’ve to configure a password policy which will meet below (all) requirements.
    1. Min 1 uppercase letter
    2. Min 1 Lowercase letter
    3. Min 1 Special Character
    4. Min 1 Number
    5. Max number of repeated characters allowed 2 (AA, bb, cc etc. is allowed)
    5. Min Length 8 Characters

    How can we achieve this? We’ve hybrid environment wherein users are getting synced from on-prem AD to Azure Entra

  4. Hello thanks for this great article. We have a On-Prem AD where we sync users to Azure AD (or Entra if you like) All devices are Azure AD Joined and not connected in any way to our On-Prem AD, So users use their Azure AD ID to log on to their devices. Will it work to create a Local AD policy? or are we stuck with the cloud settings?

    • That is a good question. I think you are stuck with cloud settings, because the user account doesn’t exist in the local AD. But I am unsure about it, maybe the password policy will just replicated to Azure Ad..

      • Thanks, the users are in our local ad. but to logon they user their full email not domain\username to login to the machine

  5. There is no such thing as this “The password policy will automatically be synced to Azure AD”

    Please provide source for this.

    Microsoft doesn’t sync password policies.

  6. We have a hybrid environment, locally users are set to 180 password expiry, but in o365 it is set to never expire.

    If I leave AD to say 180 days, and change in o365 to 180 days, I assume that will make it so they expire at the same time as O365/Azure can see the password change?

    For some accounts, we have it set to never expire. Will that still pass through or will the o365 settings apply instead?

    The main issue we have is people who WFH don’t get a password expiry notification, they just get locked out as in local AD, it sets their password as expired.


  7. So I have checked “Password must meet complexity requirements” but what are the requirements and where do I set them ?


  8. How does this work when you convert the domain from federated to managed and use Password Hash Sync ? does the on prem FGPP still take precedence?

    • When the user changes the password, the writeback will attempt to change the on-prem password. But if it doesn’t match the FGPP then the write-back and password change should fail.

  9. We have an on prem DC and we are able to control password policies there for our users. We are trying to move to non expiring passwords and want to make sure users are at a minimum of 14 characters. So we set that for minimum length and then select user to force change at next logon. our users are all using Intune managed devices and when they logon they get a 15 second notification they must change passwords and then it goes away. Is there anyway to make that stay on?

    What has happened to a few test users is they get distracted forget to change password and then there system locks and they are unable to login anymore.

  10. Hi Rudy,
    About session of “Change Azure AD Password Policy”, Would you let me know where reference officical document form microsoft. Thanks

  11. So I have completed the steps above (thanks for the guidance on it)

    Currently in testing, so scope was set to 1 user. I do see it listed for the user when checking on local ad powershell,

    But when completing the SSPR on 365 the minimum length isnt being applied, Any ideas?

    Policy onprem set to min 14 char, But on SSPR I can set lower than that

  12. Hi,
    How we can test this policy from user device? For example , as an admin I implemented the password policy for all users but know I want to see the proof from user device. How can I do that.
    If anyone can help me that would really helpfull.

  13. Hi everyone

    I am an O365 user and wanted to deploy the custom password policy. I had contacted my partner and Microsoft and ended up purchasing the AAD Domain Services component.

    I dont have an on-prem AD and tried to set up the custom password policy – it simply does not work !!!!!

    Can anyone guide me on this issue

  14. Great article…using your sample/example of 180 days for max pwd age, how can i verify this is SYNCED via PHS and verify this value on the AZ tenant…? What attribute can i examine…? thanks in Advance

      • Thanks for your prompt reply Rudy…
        Yes, I tested Get-MsolPasswordPolicy and it remain unaffected, it was the same one as before adding FGPP scope(s) on the on-premise Domain controller.

        See this example….EmmaC has a FGPP of two days….and it was blocked on login for the on-premise domain.

        Get-ADFineGrainedPasswordPolicy -Filter * | Format-Table Name, AppliesTo, MaxPasswordAge, Description –AutoSize

        Name AppliesTo MaxPasswordAge Description
        —- ——— ————– ———–
        2day {CN=Emma Chan (2d),OU=SyncMe,DC=PWDDEMO,DC=org} 2.00:00:00

        If I go to AZ user tenant properties, I still see

        Get-AzureADUser -ObjectId $user1 |fl Display*, Password*,

        DisplayName : Emma Chan (2d)
        PasswordPolicies : DisablePasswordExpiration

        So, what is the secret sauce to ensure the FGPP is getting sync or transferred to the AZ tenant. I have AD Cloud sync running via PHS. Note this is not AD Connect, but Cloud Sync. I think this should not matter…?

        On a different note, I found this article that says I need Azure Active Domain Directory service to make this work…? Do u concur…? My client rather not have to load another service to enable FGPP on the Azure tenant.

        Thanks in advance

  15. So I was testing around as we just installed the Azure AD Protection proxy and agent. From my testing it seems like there’s no need to create a new password policy on prem in the passwords settings container. Seems like the proxy itself is enforcing our on prem GPO policy. I tested by using less than 9 characters our policy requires 10. No matter what random numbers/letters I threw at it, I would always get an error of not meeting requirements

  16. “Because Azure Active Directory will follow the password policy of your local domain controller.”
    Could you please site source for this?

Leave a Comment