Azure AD Password Protection: The Cloud Security Service your Active Directory Needs Now

Updated: Azure AD Password Protection became generally available April 2^nd, 2019. The service is largely the same as I presented in this post, with the following updates:

• The two proxy limit has been lifted.
• When registering the proxy and the Active Directory forest, 3 authentication modes are now available. Two of them support MFA so it’s not necessary to have a Global Admin account without MFA.
• The banned password evaluation algorithm has been updated. See “How are passwords evaluated” in Microsoft documentation. Note: this algorithm may change at any time, without notice or update to the documentation.
• Licensing has been simplified: All users synced with Azure AD must have Azure AD Premium P1 or P2. With this requirement satisfied, all Active Directory users are licensed for this service.
• Preview customers must update agents; Public Preview agents will stop working after July 1, 2019.
• My Microsoft sources tell me that, with a little up front communication, users are not finding the new rejection of common passwords with the standard “Your password does not meet complexity requirements” message as confusing as they thought it would.
• Start deploying!

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
• Architecture
• Runtime authentication flow
• Password evaluation process
• Design advantages
• Deployment steps
• Monitoring
• Licensing
• 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, 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).

Architecture

Azure AD Password Protection has an Azure component, an on-premises proxy service, a DC service, and finally a custom password filter (Figure 1):

The purposes of this architecture are to 1) use Azure’s global banned password list (GBPL) to protect Azure AD accounts from using common passwords, 2) allow Azure administrators to create a custom banned password list that augments the GBPL, and 3) protect Active Directory accounts from common passwords by providing a on-premises service that uses the consolidated banned password list.

Azure
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:

The password protection service (Figure 3) 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ⁱ.

Why doesn’t the service check for more than 1000 common passwords? This might be practical for Azure, but not for on premises servers. In the password evaluation process, the user’s password is compared to not just the 1000+ banned passwords, but to potentially thousands of variations of each. That’s a lot of passwords to compare against. If the password list held 1 million passwords, that could be billions of password variationsⁱⁱ for your DCs to check – and they would grind to a halt under the load.

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).

In addition to the Azure-generated global banned password list (GBPL), Azure AD Password Protection provides for a tenant wide view of banned passwords to be used (TBPL). For example, a financial services company may want to ban passwords such as “mortgage” or “insurance” in addition to Azure’s globally determined common passwords. (In the figure, I’ve added car companies to the custom list.) This consolidated list is what is used on premises.

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.

Proxy service

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):

DC agent

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.

An AD password filter is a custom DLL that allows you to extend the basic functionality of a password validity check. The Azure AD Password Protection customer password filter is as simple as possible; all it does is forward the password request to the DC agent and collect the accept or deny response from the agent.

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

C:WindowsSYSVOLsysvolPolicies{4A9AB66B-4365-4C2A-996C-58ED9927332D}AzureADPasswordProtection.

How the DC agents (in a production deployment, there should be one on every DC) obtain and distribute the password policy is quite elegant^iv:

• 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).

At most, one DC per site may request the BPL, but it will probably be far fewer – a little as once per hour per domain. Why? Because of DFS-R’s efficient replication of the policy via SYSVOL. In a decently-connected network, an updated policy will have replicated around to all DCs before other agents wake up, and thus they will have a current policy and won’t need to request a new BPL from Azure. This architecture also ensures that DCs in locked-down environments will still get the password policy because SYSVOL replication is an essential part of DC functionality.

Runtime authentication flow

The banned password policy evaluation is integrated into the standard AD password evaluation process (Figure 8):

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.

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 manner^v:

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 attacks^vi.

The policy will apply to all users in the forest – there’s no back door for administrators – and apply to all password change processes^vii. Normal incorrect password checking with the PDC emulator is not affected by this new capability.

Design advantages

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.

Deployment steps

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.

Monitoring

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):

The DC agent has its own performance counters in Perfmon under Azure AD Password Protection (Figure 10):

You can also use the Get-AzureADPasswordProtectionSummaryReport PowerShell cmdlet to get a summary view of password change activity.

Licensing

What kind of Azure AD license does this capability require? It breaks down in the following manner^viii:

• 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.

Miscellaneous tidbits

• 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 GA^ix.
• 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.

_______________________________________

Resources

ⁱhttps://twitter.com/Alex_A_Simons/status/1009490805369655296

ⁱⁱhttps://twitter.com/Alex_A_Simons/status/1009500870872973312

ⁱⁱⁱhttps://twitter.com/Alex_A_Simons/status/1009923402998562816

^ivhttps://techcommunity.microsoft.com/t5/Azure-Active-Directory-AMA/BPL-polling-frequency/m-p/210417/highlight/false#M45

^vhttps://techcommunity.microsoft.com/t5/Azure-Active-Directory-AMA/Point-scoring-system/m-p/210405/thread-id/38#M50

^vi https://techcommunity.microsoft.com/t5/Azure-Active-Directory-AMA/Point-scoring-system/m-p/210405/thread-id/38#M50

^viihttps://techcommunity.microsoft.com/t5/Azure-Active-Directory-AMA/bd-p/AzureActiveDirectoryAMA

^viiihttps://techcommunity.microsoft.com/t5/Azure-Active-Directory-AMA/The-licensing-basics/m-p/210378#U210378

^ixhttps://twitter.com/Alex_A_Simons/status/1009490805369655296