Password Protection with Azure AD and ‘Common Passwords’

The problem with password protection

Passwords can be troublesome, and this often comes down to the opposing needs and expectations held by the people setting the passwords, and the people managing them. IT and SecOps teams want complex passwords, and typically enforce policies to ensure that newly created passwords meet a certain character limit and range. The user, who is typically in charge of setting their password, will invariably opt for a password they can remember, and configure it to meet the confines of the password policy.

So, what’s the end result?

The user will opt for the easiest, most convenient way to stay within this restriction. They’ll set a password that passes the requirements of the complexity policy but ensures that it is easy for them to remember. When it comes to changing the password, (every 30 days, for example) in all likelihood the newly created password will be highly similar to the last one! Hackers and malicious actors know all this – it’s just human behaviour. These restrictions and subsequent reactions mean that passwords are typically confined to a much more limited scope of possible options than IT and SecOps intended – all to the benefit of the hacker!

There are numerous changes happening in the cloud to work towards a password-free environment – all for the benefit of IT, SecOps and the end user, but whilst passwords are still in use, moving the balance of security towards the user is what IT and SecOps should be looking for.

To attempt to improve the above situation we are going to look at Password Protection from Azure AD. This feature takes Microsoft’s view of common passwords and ensures that these common passwords (and variants of them) cannot be used as a password for cloud and on-premises services.

Password Protection from Azure AD

For Azure AD accounts, that is cloud accounts, this feature is already enabled, and you cannot set a password that is considered common. But for your Active Directory, this same service can be enabled in a few steps, and we will cover these steps here.

1. First, obtain the correct licence – on-premises password protection requires Azure AD P1 licences, which are available standalone or as part of Enterprise Mobility and Security E3. They are not part of Office 365 E3 or E5 licences. You need one licence per user with an account on-premises.
2. You download and install the Password Protection Proxy software to a server (or two) of your choice on-premises. This software is woken up each hour, at which time it goes and downloads the latest config and blocked password list. The information that is downloaded is saved to the SYSVOL folder within your forest. This information is then automatically replicated to all your domain controllers.
3. Next, you download and install the Password Protection Agent on each domain controller. You can start on a few domain controllers, knowing that password resets and changes on those domain controllers are the only ones protected. For full company-wide coverage, the agent will need to be installed on all the domain controllers in your forest.
4. Before the configuration will work, you need to register the proxy endpoints so that the agent software on the domain controllers can cause them to wake up and check if more than one hour has gone by since the last download, and if so, to download the latest settings and common password list.
5. Finally, the agent is a password filter on the domain controller, so that all password changes are passed to the agent and the agent verifies if the password change or reset is allowed. For this agent to be registered as a password filter, the domain controller will need to be rebooted.

With this configuration in place, you will get Microsoft’s commonly known password list downloaded to your domain controllers (via the proxy application, and via SYSVOL). However, the password protection agent will not enforce these changes. This is because the default configuration in Azure AD is audit mode only. Your event log records all password changes and resets, it will also show whether the user or IT changes to the password would have failed if you were in enforce mode. This allows you to see the impact of this password protection policy before you move to enforce mode.

The Microsoft common password list is a list of 500 passwords that Microsoft has seen used in malicious login attempts to accounts in their authentication platform. The agent will check all password changes and resets against this list and will look for common variations on this list as well. For example, the Microsoft list will contain “password”, so “P@ssw0rd” and “Pa55word!” etc. are all variations on this theme, and are also blocked. The inclusion of variations means that although the Microsoft list is currently the top 500 passwords, there is actually password protection for over a million variations of the most commonly known, used and hacked passwords.

The settings for this service in Azure AD are very simple. You can enforce your own list of passwords that should be blocked (or words that, if included in a password, will be considered a weak combination of letters). For example, office locations, business functions, company name etc. are all good for this list.

Enforce ‘common passwords’ protection

Finally, once you have informed your users and service desks that common passwords will be blocked, you can change the mode to ‘Audit’ to ‘Enforced’, and within a few hours, your users will not be able to set common passwords.

Every password attempt is scored by the agent, and a low scoring password is not allowed. A word on the list or your custom list gets a score of one, but words not on the list are considered by their individual characters. For example, a password including an office location and sequential numbers, such as ‘London123’ would be a bad password, but say we don’t have an office in Paris, ‘Paris!5914’ would be a better password (as Paris is a random word as far as my password is concerned). So a random word, unless on the list, would score one point for each letter, but a word on the list scores a single point. You currently need to exceed five points to have your password change accepted.