According to Verizon DBIR, hacked passwords cause the most of the data breaches and that, for obvious reasons regular users (and sometimes even administrators) easy to remember passwords, and they reuse the same passwords or closely related ones over and over again.

Most users think if they have chosen a password that meets a complexity requirement (P@$$w0rd1! sounds familiar right?) they’re safe, which is exactly wrong: usually the pattern used to create a  “safe” password by the user is always the same:

  • Start with a capital letter
  • Last character is a digit or punctuation
  • Use of common words (like sport teams, music bands) or work related words (like name of products, brands) or personal (like name of children)
  • Special characters substitutions like “$” for “s”.

and, even if they change their password periodically, probably the last digit (+1) will be the only change.

Attacks against common passwords using “password spray” attacks have risen dramatically in the last few months. They’re extremely hard to defend against with conventional security tools because the attacker doesn’t hammer a single account with multiple passwords (brute force attack). Rather, they will use a few common passwords to attack multiple accounts. Each account is attempted only a few times, and perhaps with a long interval in between attempts to avoid triggering alerts.

The best way to protect against these attacks is to simply not have common passwords, align with the latest NIST guidelines and enable (whenever is possible) Multi-Factor Authentication.

Azure Active Directory was always offering a banned password system when user change their password: Azure AD Password Protection.

Azure AD Password Protection is powered directly by Microsoft which regularly updates the database of banned passwords by learning from billions of authentications and analysis of leaked credentials across the web: this service is turned on by default for password set and reset actions for Azure AD Premium users.

The missing piece in this solution is the hybrid configuration: if you are using AD Connect to sync your AD on-prem accounts in Azure, the password policy used (whatever authentication method is in place – Pass Sync, Pass-thought or ADFS) is probably the old AD on-prem GPO when the password is changed locally on the computer.

Starting from June 19th this is not a problem anymore: Azure AD Protection is now a hybrid service that provides protection against common passwords for both Azure AD organizational accounts and on-premises Windows Server Active Directory accounts. It prevents users and administrators from changing or resetting their passwords to simple, easily crackable passwords wherever the password is changed and stored.



Azure AD Password Protection has the following components:

  • an Azure component
  • an on-premises proxy service
  • a DC service
  • a custom password filter.

As explained, the goals of this architecture are to:

  • Use Azure’s global banned password list (GBPL) to protect Azure AD accounts from using common passwords
  • Allow Azure administrators to create a custom banned password list
  • Protect Active Directory accounts from common passwords by providing a on-premises service that uses the consolidated banned password list.

The Password Protection Service uses Azure threat intelligence for a global view of banned passwords. The list is compiled from passwords in leaked credentials lists plus the analysis the Azure threat intelligence system performs upon the 20 million account takeover attempts it catches daily . This list doesn’t contain every common password ever found, just the 1000 most common being actively used in attacks. In the password evaluation process, the user’s password is compared to not just the 1000 most used banned passwords, but also on the thousands of variations of each. In addition to the Azure-generated global banned password list, Azure AD Password Protection provides for a tenant wide view of custom banned passwords to be used. For example, a travel services company may want to ban passwords such as “London” or “Switzerland” in addition to Azure’s globally determined common passwords : this consolidated list is what is used on premises.

Azure AD Password Protection Proxy service is to acquire the list and pass it to DCs. Acting as a stateless relay service, the proxy allows DCs to get the list from Azure AD without requiring internet access themselves. this makes Security Officers quiet happy. The proxy service can be installed on any domain joined server. In this preview, it can be installed on one or two servers to provide fault tolerance; this limit is expected to be lifted before GA.

The DC Agent package contains two components. The first component is the DC agent itself, the second is a custom password filter. The AD password filter is a custom DLL that extends the basic functionality of a password validity check of the domain controller forwarding the password request to the DC agent and collect the accept or deny response from the agent.


The Password Evaluation Process

The banned password policy evaluation is integrated into the standard AD password evaluation process.

  1. The user tries to set a new password, and their local DC handles the request.
  2. On the DC, the request is processed by the custom password filter which passes the password to the DC agent.
  3. The DC agent compares the proposed password to the password on SYSVOL and approves or rejects it.
  4. The success or failure is returned to the user.

The evaluation of the password is quite simple: Each character in the password is worth of 1 point, but every banned word (or its variation) is considered just 1 point instead of the sum of each character. The minimum acceptable score is 5.

Let’s have an example: if your custom list includes the words “London” and “2018” and the user password to test is “L0ndoN2018!” the score is.

  • L0ndoN – Variation of a banned password – 1 point
  • 2018 – matching a banned password – 1 point
  • ! – single char – 1 point

Total = 3 points < 5 points required = FAIL.


Requirements for Implementation

To implement this solution some pre-requirements have to be meet:

  • Synced users must have at least an Azure AD Premium P1 license (if you have EMS E3 or M365 E3 you are fine)
  • You must have at least one Windows Server 2012 or later domain controller in the proxy domain.
  • Your SYSVOL should be replicated using DFS-R and not FRS (this need to be checked because domains coming from Windows 2003 forest and domain level could be impacted)
  • The solution requires the registration of the proxy at Forest Domain Level it means that in complex AD environments this should be planned correctly
  • Azure AD Password Protection Proxy must be installed on a domain joined computer (AD Connect is a good candidate for this) – more than one Proxy should be present for HA.
  • All domain controller in the domain (including remote sites) should be able to reach at least on AAD Password Protection Proxy.
  • All the domain controllers in the domain must have the DC Agent installed to have consistency.


In the next blog of the serie we will explain how to implement the solution.

Comments are closed.