Today is Tuesday the 19th June, on Friday the 15th June I Tweeted that banned password settings had arrived in the Azure Portal.
It was certainly a popular Tweet with 98 retweets and 118 likes, I would have liked to have said it went viral but I don’t think the numbers justify that! Could Azure AD Geekery ever go viral? Having seen the new features, I started to look at the links for new documents and sad to say they were broken. Today the docs are available here and I am blogging on my first impressions…
We are all aware of how dangerous “silly” passwords are, and yet they still get used. Password entropy checks, used by some websites, can encourage their use where “Passw0rd0” is considered stronger than “adebkypt”. Banned password lists make so much sense when they are dynamically managed. Alex Simons (@Alex_A_Simons) Tweeted that Microsoft bans the top 500 most used password plus all character replacement variations, so well over 1M potential passwords are blocked. Microsoft with their ever-growing customer base, leaked credential detection and handling over a billion authentications per day (Daniel Stefaniak (PM Microsoft) @d0m3l has just sent an update, the figure is currently over 7 billion/day) are in an exemplary position to construct a global banned password list based on popular usage. To augment this list, we need the capability of adding banned passwords that are specific to our environment; company name, project names, the name of the best/worst boss ever!
When are password checks made
Whenever a password is changed or reset (Self-service password reset) in the Azure AD Access panel, the global banned password list is checked. If the custom banned password list is enabled, your list of custom banned passwords is also checked.
The banned password list is case insensitive, and the engine will consider common substitutions. If you set a banned password of XTSeminars, the engine will also ban XTSemin@rs. After updating the custom list, it may take several hours before it is applied. If we try and change our password to XTS3minars we see:
If we try and reset the password to XTS3minars via SSPR we see:
Slightly different messages, but you have to love Microsoft’s consistency…
You might be wondering what happens if an administrator changes the password via PowerShell, I tested it and found that neither the global or custom password lists are checked.
If you are using hybrid-identity and password writeback is enabled, password changes will be written back to the on-premises AD, and consequently, on-premises passwords will benefit from the banned password policy. However, if a password is changed on-premises, the policy will not apply. To enable the banned password policy for on-premises, you will need to select “Enable password protection on Windows Server Active Directory”.
Enabling the banned passwords
Since last year it has been possible to add a custom banned password list. To add our own list, we needed to create and add a template via Graph:
This template allowed the setting of the Smart Lockout parameters used with Pass-Through Authentication (PTA) and a banned password list, this functionality is now available through the UI. In the Azure portal, select the Azure AD blade and then Authentication methods:
The custom banned password list can contain up to 1000 words.
Checking passwords that are updated on premises
To check passwords that are updated on premises against the global and custom band password lists requires a number of components. The global and custom lists are always maintained in Azure AD.
With on-premises AD any DC can originate a change to a user’s password, this could be via a user changing their password or an administrator resetting a password. Regardless of who is changing the password, checking the new password against a banned password list requires having visibility of the cleartext password. The component that intercepts the password change is a Password Filter DLL that has to be registered on every DC. Some of you may well have Password Filter DLLs already installed on your DCs, the good news is that they just chain together and they are called in turn when a password is changed. They were originally designed, back in the early days of AD for validating password complexity and synchronising password changes to password management systems.
Having intercepted the password change the next job is to validate the new password against the banned password list. To do this, the list is downloaded to the on-premises AD and replicated to all DCs via Sysvol.
The components to make it all work are:
1. The Azure AD password protection proxy, this facilitates all communication between DCs and Azure AD
2. A Password Filter DLL installed on every DC (except RODCs)
o Intercepts password changes in clear text
o Forwards changes to the DC Agent, running on the same DC
3. Azure AD password protection DC Agent running on every DC (except RODCs)
o Communicates with Azure AD, via the proxy
o Communicates via RPC to the proxy
o Retrieves the banned password list (policy)
o Stores the retrieved policy in Sysvol, replicates to all DCs in the domain
o Validates the passwords intercepted by the Password Filter DLL against the policy
Requirements
o DCs must be Windows server 2012 or later
o At least 1 DC in each domain must be able to communicate with the proxy service
o DFSR must be used for Sysvol replication
Deploying
The recommendation is to start by deploying in Audit mode, this will allow attempts to use banned passwords to be logged without actually blocking their use. Once everything is running satisfactorily, and your users have been educated about the restrictions of banned passwords, the operating mode can be switched from Audit to Enforce.
The proxy must be deployed on at least one member server in the forest, for fault-tolerance and scalability it would be wise to deploy additional proxies (The public preview supports a maximum of two (2) proxy servers per forest). Remember that the Azure AD password protection DC Agent connects to Azure AD via the proxy to retrieve the policy, it then replicates the policy to all DCs in the domain via Sysvol. As Sysvol only replicates within a single domain at least one DC agent in each domain in the forest must have connectivity to a proxy.
Download the two MSIs here
o AzureADPasswordProtectionProxy.msi
o AzureADPasswordProtectionDCAgent.msi
Proxy installation and configuration
Install the proxy on a member server (you can install it on a DC for testing purposes). You will then need to register it.
Open PowerShell as an administrator:
1. Import-Module AzureADPasswordProtection
2. Get-Service AzureADPasswordProtectionProxy | fl
a. To check the service is running
3. Register-AzureADPasswordProtectionProxy
a. Registers the proxy with Azure AD
b. You will need to supply Global Administrator credentials for your tenant
c. You also need to be logged in to the server as AD administrator for the forest root domain
4. Register-AzureADPasswordProtectionForest
a. Registers the forest with the proxy and Azure AD
b. You will need to supply Global Administrator credentials for your tenant
c. You also need to be logged in to the server as AD administrator for the forest root domain
DC Agent installation and configuration
Install the agent on each DC, this will require a reboot because of the Password Filter DLL. Once installed and rebooted there is no further installation to perform.
Testing
The result of trying to change the password to Training1, remember I have “Training” in my banned password list:
And the event log reports:
"The reset password for the specified user was rejected because it matched at least one of the tokens present in the per-tenant banned password list of the current Azure password policy."
Very cool… It works!
Having a look around!
If you look in Sysvol you will see a new policy object:
C:\Windows\SYSVOL\sysvol\example.com\Policies\{4A9AB66B-4365-4C2A-996C-58ED9927332D}\AzureADPasswordProtection and below that:
Event Logs
There are three sources of events:
You can see that the policy validation engine (3007) reported that password validation failed based on the per-tenant banned password list. The change was accepted because the system is in Audit mode.
In addition to the Admin log, there are also Operational and Trace logs. Tracing is disabled by default because of the high-volume of logging that occurs when it is enabled.
That’s it for now – Please tweet me if you found the blog helpful @john_craddock and don’t forget to book a place on my Identity Masterclass 😊