Deploying Azure AD Password protection for Windows Server Active Directory

  • Article

Hi,

As you will have seen from Alex Simon's announcement yet another great Azure AD public preview has landed!

"Azure AD Password Protection and Smart Lockout" will provide further protection to your organisation from weak passwords and bad actors. Despite organisations setting stringent password complexity rules, users are still setting passwords that are relatively weak but do satisfy password complexity requirements. For example:

  • Predictable combinations: e.g. "June2018!" & "CompanyName12!"
  • Common passwords with predictable formats: e.g. "Password12!"
  • Common character substitutions: e.g. "Pa$$w0rd12!"

"Azure AD Password Protection and Smart Lockout" protects by preventing users from setting their passwords to common, weak and risky ones and by preventing bad actors from trying to brute force those accounts.

This post will focus on the "Password Protection for Windows Server Active Directory" components that allow you to extend the password protection you get in Azure AD to your on-premises Active Directory. I will walk through the key features, example deployment and user experience.

To use this feature an agent is installed on to your domain controllers and a proxy agent is also installed (on the AAD Connect server in my example). The "Password Protection Proxy" proxies password policy requests from the DC's "Password Protection Agents" so your DC's aren't connecting to the internet. Link to the preview agents here.

Key Features

The key features this component provides are:

  • Protect all password set and reset operations in Azure and Windows Server Active Directory by ensuring they do not contain weak or leaked password strings.
  • Control Azure AD password protection for both Azure AD and on-premises Windows Server Active Directory from a unified control panel in Azure AD portal.

 

Deployment

Domain Controller(s) : I execute the AzureADPasswordProtectionDCAgent.msi on each of my domain controllers (can be deployed with SCCM and installed silently).

NOTE: this agent doesn't connect to the internet, all updates are done via the Password Protection Proxy.

 

 

Click "Next" and select all the defaults to complete the install.

 

 

A restart is required so plan carefully to ensure no disruption. We now move on to the installation of the Password Protection Proxy.

Password Protection Proxy: On my AAD Connect server I install the AzureADPasswordProtectionProxy.msi.

 

 

Select all the defaults to complete the install.

 

 

That's all the installations completed so its time to run a couple of PowerShell cmdlets. The cmdlets you need to run are detailed below and they are required to register the Forest and Password Protection Proxy with Azure AD\Active Directory. Some things to note:

  • For each cmdlet I was prompted for a credential for the Azure AD instance (this needs to be Global Adminstrator).
  • You also need to be logged in as a domain admin to run these cmdlets (Root Domain).
  • I ran these cmdlets from the server the Password Protection Proxy was installed on.

 

 

Lets have a look at the portal and enable Azure AD Password Protection for Windows Server Active Directory. Navigate to the Azure AD blade in the Azure Portal > Authentication methods > Password protection (Preview) and you will see the below.

 

 

I click "Yes" for "Custom banned passwords. ("Dudders2018!" is the example I will be using)

I click "Yes" for "Enable password protection on Windows Server Active Directory"

I select a mode. "Enforced" will prevent banned\custom passwords from being set. "Audit" will log when a banned\custom password has been set.

User Experience

We are going to test 2 scenarios with the Mode set to "Enforced".

  • Trying to set a password that we have defined on the "Custom banned password list"
  • Trying to set a password that Azure AD has detected as weak\risky.

NOTE: When deploying it is strongly recommended to start Password Protection in "Audit" mode. This will help you gauge the level of weak passwords being set and plan education for users accordingly.

 

 

Let's try and reset my password to "Dudders2018!"

 

 

It fails to set, displays the standard password complexity message and logs the following events in the authenticating DC.

 

 

 

Let's try and reset my password to "Password12!"

 

 

It also fails to set, displays the standard password complexity message and logs the following events in the authenticating DC.

 

 

I tried to set "June2018!" (which isn't in the custom list) as a password and that also failed as Azure AD has already defined this pattern of passwords as weak\risky.

Just to prove that this is working, I change the mode to "Audit", wait for the DC's to update the local policy and then try and reset the password to "Dudders2018!" & "June2018!". It lets the banned\weak passwords get set but the following event log is set. This could be useful when you're considering rolling out this feature to see how many users are using passwords that are considered weak or at risk.

 

 

Hope thats useful!

MD

@Dudders1