Passwords are generally in bad shape. Users don’t like much of complex passwords and choose passwords which are too easy to guess. Even IT industry is moving to passwordless world it isn’t there yet. That said, passwords still exists in many enterprises and we cannot live without them, yet.
In this blog post, I’m going through how you can leverage Azure AD Password Protection to on-premises Active Directory. This feature was released to public preview last summer and general availability might see daylight quite soon.
How Azure Active Directory Banned Password feature should be implemented and how it works in the cloud, links below. Deployment itself is not covered in this blog post but in a nutshell you need to install:
- Azure AD password protection proxy service (2 is maximum at preview)
- Register proxy and Active Directory forest
- Domain Controller Agent
Guidance for deployment found from link below:
- Eliminate weak password in the cloud
- Eliminate weak passwords on-premises
- Deploy banned passwords feature to on-premises
How it works (from docs)
The banned password list matches passwords in the list by converting the string to lowercase and comparing to the known banned passwords within an edit distance of 1 with fuzzy matching.
Example: The word password is blocked for an organization
- A user tries to set their password to “P@ssword” that is converted to “password” and because it is a variant of password is blocked.
- An administrator attempts to set a users password to “Password123!” that converted to “password123!” and because it is a variant of password is blocked.
Each time a user resets or changes their Azure AD password it flows through this process to confirm that it is not on the banned password list. This check is included in hybrid scenarios using self-service password reset, password hash sync, and pass-through authentication.
Audit and Enforce Modes
Service has audit and enforce modes. Audit mode helps a lot to gather information from end-user passwords, are those really as bad as admin think. Probably those are but it’s better to have verified information before turning service to enforce mode where password change/reset request are rejected if password doesn’t fulfill the accepted criteria. General recommendation is to run the service in audit mode a while, for example one week before change mode to enforced.
When you are ready for enforced mode change configuration from Azure AD. In my demo environments enforced mode was not activated immediately. It took couple of hours so don’t panic if you face same situation.
Service Principal and Consent
During deployment of service the following events appear to Azure AD logs.
- Create service principal
- Grant consent to application
- When service state is changed following event is written to Azure AD Audit log.
Logging and Monitoring
Following events appears to domain controller logs during change or reset operations. When operation is successful only one event is written to DC log and when request fails, one event is coming from DC agent service and one from DC agent password filter dll.
|Status||Change||Reset / set|
|Fail (did not pass Microsoft policy)||10016, 30004||10017, 30005|
|Fail (did not pass organization policy)||10016, 30002||10017, 30003|
|Audit-only pass (failed Microsoft policy||10024, 30010||10025, 30009|
|Audit-only pass (failed org policy)||10024, 30008||10025, 30007|
How It Looks In The Cloud
When user tries password which is found from Microsoft banned password list
When user tries password which is found from custom list
Event from Azure AD logs
When user tries password which is blocked by ADDS password policy
How It Looks in the on-premises
Feature is still in preview and I would like to see customizable error messages from unsuccessful password change/reset attempts. Currently, message what end-user see remains same no matter what is causing the unsuccessful password change/reset attempt.
The reason for unsuccessful attempt can be found from event logs but naturally only by administrator.
First two pictures are events from domain controller where password change request has been blocked because it was found from Microsoft global banned password list.
The following two picture are events from domain controller where password change request has been blocked because it was found from tenant password list.
Domain Controller – under the hood
Azure AD Banned Password Protection leverages SYSVOL where it saves password policies. I have 12 GPO’s in my test environment and 13 folders in SYSVOL structure. The highlighted one is the one which is used by Password Protection
Azure AD Banned Passwords feature could be very useful to prevent usage of common and predicted passwords in organizations. It affects to all password change and reset requests including fuzzy combinations. When on-premises integration is configured passwords are evaluated against global and custom lists in every change or reset request no matter where it’s triggered. And worth mention, at least Azure AD P1 license is required at time of writing.