Azure AD Password Protection – the needle in the haystack that you’ve been looking for!

What is Azure Password Protection?

Azure AD password protection is a feature that enhances password policies in an organisation. On-premises deployment of password protection uses both the global and custom banned-password lists that are stored in Azure AD. It does the same checks on-premises as Azure AD does for cloud-based changes. These checks are performed during password changes and password reset scenarios.

So, why do I need it?

Well, the utopia for authentication nowadays, is definitely passwordless. Think Windows Hello For Business. Think Authenticator apps. Think FIDO2 keys.

But we all know, that for some, the dream of a passwordless workplace is simply that… a dream. At least for the time being.

So, the majority of enterprises still have a reliance on passwords. Passwords are a hackers dream. Especially when you consider that users passwords are usually childrens names, favourite sports teams, employer, partners names etc – all which can be found on social media or guessed by a hacker with a little bit of knowledge.

The initial step for users should be guidance on passwords. Microsoft’s guidance document can be found here: https://www.microsoft.com/en-us/research/publication/password-guidance/

However, this does not and will not alleviate bad passwords.

Azure Password Protection to the rescue!

Azure Password Protection protects your organisation by detecting and blocking known weak passwords and their variants, as well as optionally blocking additional weak terms that are specific to your organisation.

We will soon get onto the actual deployment of Azure Password Protection, but first we will take a look at the password lists that the service uses to determine if a password is bad or weak.

Global Banned Password List

Microsoft sees over 10 million username/password pair attacks every day. This gives them a unique vantage point to understand the role of passwords in account takeover.

By constantly analysing Azure AD security telemetry data, Microsoft are looking for commonly used weak or compromised passwords, or more specifically, the weak base terms that often are used as the basis for weak passwords.

When such weak terms are found, they are added to the global banned password list. The contents of the global banned password list are not based on any external data source. The global banned password list is based entirely on the ongoing results of Azure AD security telemetry and analysis.

Whenever a new password is changed or reset for any user in any tenant in Azure AD, the current version of the global banned password list is used as the key input when validating the strength of the password. This validation results in much stronger passwords for all Azure AD customers.

Can I see what’s on the Global Banned Password List?

No, because this would be like the Holy Grail to cyber criminals (or hackers!) So for this reason, Microsoft does not publish the list.

Custom Banned Password List

Microsoft allows you to go one step further and add custom terms to a banned password list. These terms can be anything you want, but should be things such as:

  • Brand Names
  • Product Names
  • Locations (Office locations etc)
  • Company specific terms or abbreviations

Once these terms are added to the custom list, up to a maximum of 1000 terms, they are combined with the Global Banned Password List during password validation.

Do I need to add every variation of a term to the list?

No! There is a matching algorithm that works in the background to do this piece of work for you.

An example is the following:

A company called ‘Sheep’ based in ‘Liverpool’ makes a product called ‘Wool’ (I know, I know – I’m not that creative! 🙂 )

Ideally, we want to ensure that all variants of the company name, location and product are banned from being used as passwords. If we had to use every variation, the list would look something like this:

Sheep
5heep
Sh33p
5h33p
Sheep!
Sheep?
Sheep1
Sheep2
Sheep2

Wool
Woo1
W00l
W001
W0ol
Wo0l
W0o1
Wo01

Liverpool
L1verpool
Liv3rpool
L1v3rpool
L1v3rp00l
L1v3rp001
Liv3rp00l

And so on… and before you know it, you’ve hit your 1000 term limit and haven’t covered all the required variations!

Fear not! This article explains the matching algorithm: https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-password-ban-bad#how-are-passwords-evaluated

But needless to say, all your custom password list would need to contain to cover all variations would be:

Sheep
Wool
Liverpool

The algorithm would handle the rest.

Great! How do I get all of this lovely protection working?

So firstly, the good news! For Azure AD accounts (i.e. Cloud Only) this is enabled by default, using the global banned password list.

Try and reset a cloud account password to “Password01” and you’ll see the following:

Staying with AzureAD accounts, let’s look at how to implement a Custom Banned Password List too.

The Password Protection settings are accessed by choosing the following:

Azure Portal > Azure Active Directory > Security > Authentication Methods > Password Protection

You’ll be presented with this screen:

Select ‘Yes’ to enable ‘Enforce custom list’ and the text entry field will become editable.

Hovering over the information icon shows the following:

You can then add your custom terms to this list as described earlier and above. My custom banned password list would look like this:

Choose ‘Save’ and next time a user changes or resets their password, the new password will be validated and checked against both the global banned password list AND the custom banned password list. Any variation of a password based on the three terms above; sheep, wool or liverpool would not be accepted as a valid password.

OK, so how do I enable this amazing feature to protect my on-premise Active Directory passwords?

You can see from the earlier screenshot, that within the Azure Portal there are two options which can be enabled for ‘Windows Server Active Directory

However, unfortunately, it’s not just as simple as enabling these options. There are a few pre-requisites that need to be in place before Azure Password Protection will be used on premise.

  1. Each Domain Controller in the forest needs to have the Azure AD Password Protection DC Agent installed
  2. The Azure AD Password Proxy service needs to be installed on a server within the domain
Installing the Azure AD Password Protection DC Agent

1. Download the software from here: https://www.microsoft.com/en-us/download/details.aspx?id=57071

2. You will need the following file; AzureADPasswordProtectionDCAgentSetup.msi

3. This is a very simple install

4. However, please be aware, that this will require a restart of each domain controller. This is because the password filter DLLs are only loaded or unloaded by a restart

Installing the Azure AD Password Protection Proxy Service.

1. Microsoft do not recommend installing this service on your domain controllers, as this needs internet access. However, for testing, its fine to install on your DC.

2. Again, download the software from the following location: https://www.microsoft.com/en-us/download/details.aspx?id=57071

3. You will need the following file; AzureADPasswordProtectionProxySetup.exe

4. Again, its a simple installation process with one caveat – The Windows Firewall service needs to be enabled and running in order for the installation to complete. If Windows Firewall is configured to not run, then the workaround is to enable before the installation and then disable again:

5. This installation does not require a reboot.

The Azure AD Password Protection Proxy Service can also be installed silently (via ConfigMgr?) using the following command:
AzureADPasswordProtectionProxySetup.exe /quiet

6. The service includes a Powershell Module which can be imported by running this:

Import-Module AzureADPasswordProtection

7. We can the check the status of the service with the following command:

Get-Service AzureADPasswordProtectionProxy | fl

(This should return a status of “Running”)

Registration of the proxy service

The service is now running, but does not have a connection to Azure AD. We will need to register with Azure AD:

Register-AzureADPasswordProtectionProxy -AccountUpn ‘yourglobaladmin@yourtenant.onmicrosoft.com’

(This is using the interactive authentication mode. This mode supports MFA)

The running of this command requires the following permissions:

  • Global Administrator for the Azure tenant
  • Domain Administrator for the on premise domain
  • Local Administrator for the machine

You will be prompted to authenticate your Azure AD tenant:

The registration will not return any window indicating success, it will simply disappear. On initial registration, there may be a delay before the Powershell command completes, this is normal. Unless a failure message is returned, then the delay can be ignored.

Registration of the forest

We now need to register the on-premise forest and allow it to communicate with Azure AD:

Register-AzureADPasswordProtectionForest -AccountUpn ‘yourglobaladmin@yourtenant.onmicrosoft.com’

(This is using the interactive authentication mode. This mode supports MFA)

The running of this command requires the following permissions:

  • Global Administrator for the Azure tenant
  • Enterprise Administrator for the on premise domain
  • Local Administrator for the machine

You will be prompted to authenticate your Azure AD tenant:

This image has an empty alt attribute; its file name is image-9.png

The registration will not return any window indicating success, it will simply disappear. On initial registration, there may be a delay before the Powershell command completes, this is normal. Unless a failure message is returned, then the delay can be ignored.

Do I use Audit or Enforced mode?

Earlier we seen the options in the Azure Portal for this:

This image has an empty alt attribute; its file name is image-4.png

We can see that there are two different modes; Enforce and Audit. Audit is selected by default.

The only difference between these two modes is that ‘Enforced’ blocks bad passwords where ‘Audit’ allows the bad password, but logs an entry to indicate that it’s been set.

Microsoft recommends that initially Password Protection is enabled in Audit mode. This will give a good insight into how many bad passwords are being used. This should be used in conjunction with a password policy and regular comms to the users to advise on acceptable passwords.

Enforce mode is the final configuration. Its in this mode that passwords start getting rejected and users need to come up with new passwords.

When a password is rejected in Enforced mode, the users will see an error similar to the following:

Unable to update the password. The value provided for the new password does not meet the length, complexity, or history requirements of the domain.

This is just one example of an error which will be shown to the end user. The error messages can be difference depending on the software or scenario in which a bad password is attempting to be set.

How does it actually work?

This diagram shows the high level architecture of Password Protection in a HA mode with dual Password Protection Proxy Servers installed:

How Azure AD password protection components work together

Each Azure AD Password Protection Proxy service instance advertises itself to the domain controllers in the forest by creating a serviceConnectionPoint object in Active Directory.

Each DC Agent service for password protection also creates a serviceConnectionPoint object in Active Directory. This object is used primarily for reporting and diagnostics.

The DC Agents are responsible for requesting a new or updated password policies. However, the DC Agents DO NOT access the internet. The first look for an available password protection proxy service, and send a request. The password protection proxy service then sends a request to Azure AD for an updated policy which, once received, then forwards on to the DC Agents.

The DC agents check hourly for a new policy, if the current list is older than an hour then the above process will take place.

The password policy is a combination of both the global banned password list and the custom banned password list for the respective tenant.

Azure AD Password Protection is not a replacement for Active Directory password policies (or any third party), and all policies must agree before a password is allowed to be set.