Microsoft has finally provided a service that mitigates the single most critical password-related security risk in the enterprise today: common passwords. You should kick the tires on this new Active Directory capability today, so you can deploy it as soon as it reaches general availability.
This is a long post; if you aren’t interested in the TL;DR version (and you should be), you can jump directly to
• The common password as attack vector
• Runtime authentication flow
• Password evaluation process
• Design advantages
• Deployment steps
• Miscellaneous tidbits
The common password as attack vector
I’ve posted in this blog and spoken at Cloud Identity Summit (now Identiverse) on Microsoft’s and NIST’s recommendations on how to configure password length, expiration, and other password policies in light of their research and boots-on-the-ground experience. One of both organization’s core recommendations is the use of a banned password list, in which the simplest and most common passwords are not allowed. (And yes, I’m here to tell you some of the most common passwords are ‘password’ and ‘12345678’. I fear for the human race.)
According to Microsoft, 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. Rather, the 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.
Most large organizations use a hybrid identity architecture where passwords are managed in an on-premises Active Directory forest. And Active Directory unfortunately doesn’t have an out-of-the-box solution for banning common passwords. As a result, most organizations had no protection against common passwords.
Azure AD Password Protection is a hybrid service in public preview 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 such as “987654321” or “quertyjkl;” (for you touch typists).
Azure AD Password Protection has an Azure component, an on-premises proxy service, a DC service, and finally a custom password filter (Figure 2):
Azure AD has used an internally-generated banned password list for a while, and it also enforces adherence to longer minimum password lengths. If you enter a common password, you’ll be gently advised to try again:
Control and configuration of the password protection feature is handled in the Azure Active Directory blade of the management portal, under the new Authentication Methods section. The only item in this new section now – though I’m sure it will grow – is Password Protection (Figure 4).
Note that the service is thoughtfully configured such that if you installed on-premises components without touching the Azure controls, the password protection service will start working immediately, in audit mode, using the Azure global banned password list.
The purpose of the Azure AD Password Protection proxy service is to acquire the BPL and pass it to DCs. Acting as a stateless relay service, the proxy allows DCs to get the BPL from Azure AD without requiring internet access themselves (a touchy point in enterprise security). The proxy doesn’t poll Azure AD itself; it simply forwards the DC BPL requests to the Azure service, and forwards the resulting BPL to the requesting DC. This removes any need for the DCs themselves to have internet connectivity.
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. Both the proxy service and the Active Directory forest must be registered with Azure AD using the new AzureADPasswordProtection module. (Follow the instructions carefully.) Once registered, the proxy advertises itself to the DC with an AzureAdPasswordProtectionProxy service connection point under the computer object (Figure 5):
The DC agent package contains two components (Figure 6). The first component is the DC agent itself, which runs as AzureADPasswordProtectionDCAgent. The second is a custom password filter. Let’s look at these in reverse order.
Because the password filter is an integral piece of the DC’s security system a side effect is that the DC must be rebooted whenever the DC agent is installed or removed.
The DC agent is the heart of the on-premises service. During DC runtime operations the agent checks user password changes against the password policy for validity. In the background it ensures the DC has a current copy of the BPL obtained from Azure AD. If it doesn’t, it obtains one, processes it to create a password policy, then stores it on SYSVOL at
How the DC agents (in a production deployment, there should be one on every DC) obtain and distribute the password policy is quite elegantiv:
• One DC agent in every Active Directory site wakes up approximately once per hour to decide if its local copy of the password policy on SYSVOL needs to be refreshed.
• If the policy needs to be refreshed, or if there is no policy yet, it will request a new encrypted BPL from Azure AD via the proxy, create a password policy from it, and save it to SYSVOL.
• SYSVOL replicates this policy across all DCs in the domain via DFS-R (Figure 7).
Runtime authentication flow
The banned password policy evaluation is integrated into the standard AD password evaluation process (Figure 8):
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.
Password evaluation process
The user’s proposed password is compared against a list of about 1000 words and patterns (“asdf”, etc.). In addition, character substitutions are done on the password ($ for s, upper / lower case, etc.). Currently, a score is calculated for each password in the following mannerv:
Each character is worth a point, but any substring that matches a banned word/phrase/pattern is only worth one point in total. The minimum allowable score is 5 points. For example, “Spring” and “2018” are banned words, thus “Spring2018” is only 2 points and would not be allowed.
“Spring2018asdfj236” breaks down in the following manner:
• Spring = 1 point
• 2018 = 1 point
• asdf = 1 point
• f, j, 2, 3, 6 = 1 point each
Total = 8 points = PASS
This process allows some banned words or phrases if there are enough other random characters in the password. Note that it’s also subject to change, as Microsoft evolves its cloud-scale threat intelligence around password attacksvi.
The policy will apply to all users in the forest – there’s no back door for administrators – and apply to all password change processesvii. Normal incorrect password checking with the PDC emulator is not affected by this new capability.
This hybrid design has many advantages:
• The BPL request and update process is designed to have extremely low impact on DC operations. In a well-connected network, as few as one DC per domain per hour will request the BPL.
• The request and update process works with a wide range of network topologies. DCs don’t need internet connectivity; only the proxy needs internet access. And if necessary, the proxy only needs to connect to a single DC per domain via RPC (and the port is configurable). SYSVOL replication via DFSR will ensure the password policy gets to all DCs in the domain.
• The password check goes through normal Active Directory processes and any changes to core AD functionality are kept to a minimum. No part of the operation ever goes off the DC; for example, a password change attempt is never blocked if the DC must poll Azure for a new BPL. The actual password filter is as simple as possible.
• The software is designed in a “fail open” fashion, that is, if some component is not installed or not working (for example the DC agent is installed but the proxy isn’t installed) the password will be allowed, but an error will be logged in the DC’s event log.
• This fail open architecture makes it possible to pre-install the DC agent on a server you intend to promote to a DC.
• The DC agent runs the same password-checking code as the Azure service does.
• You don’t need to deploy it on all your DCs to test it out. In fact, that’s a good way to incrementally deploy it.
The detailed deployment steps are documented here; as this service is in preview I expect they’ll be updated regularly. At a high level, the steps are
1. Determine on what domain joined computer(s) you wish to install the proxy service, and on which DCs you wish to test. The proxy doesn’t need to go on the Azure AD Connect server or a DC; any member server (such as a server that already hosts Application Proxy connectors) will do. Remember that you should not use public previews on production servers, or at least against production users; you could promote and isolate a DC in its own site to test it against specific users.
2. Ensure the Azure AD Password Protection service is configured for Audit mode (the default) and optionally add any custom passwords to the tenant BPL.
3. Get the preview bits for the password policy proxy service and the DC agent from the download center.
4. Install the password policy proxy service.
5. On the proxy server,
a. Register the proxy service with Azure AD.
b. Register the on-premises Active Directory forest with Azure AD.
6. Install the DC agent(s).
7. Reboot the DCs.
As of this writing, information about Azure AD Password Protection service activity must be collected from the proxy server and DC event logs. There’s no integration with Azure AD Connect Health at this point in the public preview, nor is there monitoring of the proxy agent from the Azure AD blade in the proxy portal.
Event IDs in the 10000 range are generated by the password filter, while IDs in the 30000 range come from the DC agent. You’ll find (slightly) more information from the DC agent messages (Figure 9):
What kind of Azure AD license does this capability require? It breaks down in the following mannerviii:
• Cloud only accounts: Azure AD password protection w/ global banned password list: Free
• Azure AD password protection w/ custom list: Azure AD basic
• Windows Server AD integration Azure AD password protection w/ global banned password list: All synced users must have Azure AD Premium P1 licenses
• Azure AD password protection w/ custom list (what I’m describing in this post): All synced users must have Azure AD Premium P1
Again, as this is public preview it’s subject to change.
• There’s no relationship between the on-premises pieces of Azure AD Password Protection and Azure AD Connect. Thus, there’s no requirement to install the proxy on one or more Azure AD Connect servers (though they will work just fine on them).
• Because there are no changes to the client side, any rejected common password will display the standard “password did not meet complexity requirements” error on the client.
• The public preview requires Global Admin in the tenant to both configure the Azure component and install the on-premises proxy, and (of course) Domain Admin to install the software. But MFA is not supported initially for the registration, so you’ll have to take MFA off the Global Admin account you’re using to install the proxy. This will be addressed before GAix.
• If you want to test some of your own passwords against what NIST thinks are common passwords, check out the NIST Bad Passwords project on Github. Besides providing you with sample code to create your own client side banned password checker, you can test passwords for weakness.
Microsoft is aggressively moving to adopt its and NIST’s recommendations for password policies. By banning common passwords changes in Active Directory, Azure AD Password Protection closes a major area of corporate risk caused by password attacks. I strongly recommend you evaluate this service in order to deploy it once it reaches general availability.
Banning common passwords is only one part of your identity security solution, of course. Conditional access with MFA control to your corporate applications – both cloud-based and on premises – is another. As enterprise architectures move from a perimeter-based security model to an identity-based one, keeping corporate resources safe requires a broad approach that includes identity, device, and data security.