Understanding and configuring Azure AD Password Policy

Most IT admins are taught that a password policy consists of the requirements for the complexity and how frequently a password has to be changed. That’s so 1990’s. It’s time to get modern with password policies using Azure Active Directory (Azure AD).

Even in this era of multi-factor authentication, a password is still the foundation of security in your network. As we move beyond that and into passwordless logon, we need to modernize our approach to passwords policies and educate our users in order to set companies on the path toward this future. Recognizing that many regulations haven’t updated to support these modern methods, we have to walk the line of adopting modern approaches to identity management and compliance. For now, this means that we’re stuck with passwords and therefore we need a password management policy.

Microsoft often gets a bad rap for not deploying a secure by default environment but in the case of passwords this is definitely not the case. But be careful what you’ve asked for, the password policy isn’t actually something that can be changed in Azure AD. Instead, what we will do is augment and secure user identities beyond the minimum standard that has been set for us.

Azure AD’s password policy

Azure AD creates its own password policy. It’s a secure by default item and we can’t change it. Using a quick PowerShell cmdlet, we can check to see that it exists. In the example below, we see that passwords are valid essentially forever and we’ll get a 30-day notification on any expiration.

For the details of the policy, we have to go to the documentation. In the chart below we see exactly what the Azure AD password policy consists of.

By comparing the PowerShell results to this policy, we see that our password expiration date is effectively never, and the notification date has been expanded from 14 to 30. The later has no meaning after the former has been set. This change can be quickly and easily made in the Microsoft 365 admin console under Settings/Security & Privacy/Password Policy.

Why would you want a password to never expire? It’s because users just iterate the passwords which makes them less secure over time. Instead, we need to get modern and build some guard rails around passwords. The existence of a policy that we can’t change doesn’t mean that we’re stuck with it! We can augment it to add more security and modernity to our network.

Creating a modern Azure AD password policy

A word about licensing. In order to gain access to the item that follows, you need to operating with Azure AD P1, P2 or have Microsoft 365 Business Premium licenses. Essentially, you can’t be using Azure AD free edition.

The first thing that we’re going to do is to enable Microsoft’s banned password list. This is yet another policy that we can’t change or even see, but we can use it and we can augment it.

Azure AD’s banned password list is based on Microsoft’s own telemetry data collected from all Azure AD users. That’s a big sample set from which Microsoft builds the global banned password list. This list is not visible, nor is it optional. All Azure AD users are subject to it.

We do however have the option to add our own selection of words to it. Up to 1000 words can be added. Microsoft has added AI smarts to this list, so you don’t have to come up with every possible variant of a password. For example, in the list below, harbor is the company name and by just entering harbor, Harbor, harb0r, harbor!, and other common variants will also be blocked.

To configure your lockout threshold, lockout direction and custom banned password list, in your Azure AD portal, navigate into Security, then Authentication Methods and then Password Protection.

In addition to an automatic banned password list based on telemetry, Microsoft also uses its telemetry data to protect accounts against password spray attacks. An attack like this throws the most common passwords at an array of accounts in the domain and hopes to find one with a weak common password that has been missed. Microsoft tracks these attempts and blocks those passwords from being used as part of this same policy.

Next Steps

The next step is password management is to start moving towards making the password irrelevant. We can do that by implementing conditional access policies that determine what access is provided based on the identity you present and that take much more knowledge than a password can provide. The next logical step is to move from password management to identity management.

All we do is support IT professionals. Microsoft 365 technical assistance, Super Secret News, Security community, MSP Legislation community, Intune, Defender and Lighthouse community, Peer groups, Kits, papers, Business consulting and more. https://www.thirdtier.net

Leave a comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.