Azure AD password protection

Users are prevented from picking commonly used passwords

Azure AD Password Protection is part of Azure Active Directory and helps prevent users from picking poor/easily guessable/compromised passwords. Microsoft maintain a “global banned passwords” list which stores passwords which are “deemed too common”. Obviously this list is not published, but by using Azure AD Password Protection you can have password changes run against it for both cloud and on-premises users. You can also create a custom banned password list, of up to 1000 entries, containing easily guessable things about your organisation, e.g. product names.

When a password change is processed, the service will “normalise” the password (which in essence would be taking it to lower case, swapping out any common substitutions, e.g. Pa$$w0rd -> password), and then checking the resulting string against the banned password lists. If it matches the user will get an error telling them to pick something more difficult to guess.

The only thing I don’t like about this at the moment – and hopefully is something that will be worked on in a future update – is that it’s all or nothing. At work we give staff a much more strict password policy than pupils, so it would be nice to be able to do the same here.

So before we look at how to set this up, let’s have a quick look at licensing – everyone’s favourite topic(!). The licence requirement varies depending on whether you are protecting cloud or AD-synced users, and whether you want to use the custom banned password list or not.

  Global Password List Custom Password List
Cloud Only Azure AD Free Azure AD Basic or
Azure AD P1 or P2*
Cloud and AD-synced Azure AD P1 or P2 Azure AD P1 or P2

There’s conflicting information about the licensing requirements for the custom password list for cloud users – Microsoft Docs says Azure P1/P2, the MD-101 Exam book says Azure AD Basic.

Protecting Cloud Users

Azure AD Password Protection is already enabled for cloud users using the global password list, and it can’t be disabled, however we can configure lockout thresholds and set up the custom password list from the Azure Portal > Azure AD > Security > Authentication methods > Password protection blade.

The custom password list allows you to enter up to 1000 items, each with a minimum 4 and maximum 16 characters. Due to the way the system normalises passwords you’d just want to put key words in here such as “Contoso”, “Tailspin” etc rather than adding things like “C0nt0s0!1”.

Azure AD Password Protection

You’ll notice there’s an option for Mode – Enforced or Audit. This applies to Windows Server Active Directory only and you can’t toggle the cloud user password protection on or off.

Protecting Active Directory (and Azure AD Connect) users

The protection for on-premise users logging on to a traditional Windows Server Active Directory account (and those users whose accounts are synced using Azure AD Connect) is achieved by installing a proxy service on a member server (which allows your DCs to access the Azure AD Password Policy service), and an agent and password filter DLLs on the domain controllers.

The installers for these can be found at the download centre. There’s two installers – the Proxy Setup (EXE) and the DC Agent (MSI). Install the Proxy service on a member server and the DC agent on your domain controllers. Unfortunately, as this involves altering the password filter DLLs, it will force you to reboot the domain controllers. You will need domain admin rights to the forest root domain as the forest is registered with Azure AD Password Protection rather than individual domains.

Once installed, you’ll need to register the proxy and the forest with Azure AD. It installs a PowerShell module, so open PowerShell and run the following:

Register-AzureADPasswordProtectionProxy -AccountUpn 'katyadmin@katystech.onmicrosoft.com' -AuthenticateUsingDeviceCode
Register-AzureADPasswordProtectionForest -AccountUpn 'katyadmin@katystech.onmicrosoft.com' -AuthenticateUsingDeviceCode

The -AuthenticateUsingDeviceCode switch is optional, if you skip this you’ll need to have Internet Explorer Enhanced Security mode turned off, or a decent browser installed, on the server for the login prompt to work. Using this switch you get a code to type into a browser on your desktop machine. If you’re installing onto Server Core you’ve no choice but to use this really as there’s no browser to show the login prompt.

There’s nothing to configure on the domain controllers so once the proxy and forest have been registered, you just need to enable the feature in the Azure Portal > Azure AD > Security > Authentication methods > Password protection blade. 

In Audit mode, password changes will carry on as normal but you’ll find entries in the event log on the domain controllers saying whether the password would have been rejected or not. The log is in Applications and Services Logs > Microsoft > AzureADPasswordProtection > DCAgent > Admin.

Event log showing that my password would have been rejected if it weren’t in Audit mode.

Audit mode is useful to see the kind of volume of poor passwords being used, in advance of informing everyone that you are making the password policy more strict. It won’t show you what passwords people are attempting to use but will give you an idea of which users are the biggest culprits.

A full list of event log entries associated with Azure AD Password Protection can be found in the Microsoft Docs.

When the policy is set to Enforce and you attempt to set a password which is not permitted by the Azure AD Password Protection you just get the generic “Password does not meet the password policy requirements” error:

The error shown when you change an AD account password to something not permitted by the policy

Further Reading:

Leave a Reply

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.