Microsoft released a new feature in Azure called Azure Active Directory password protection. It tackles one of the major security issues in any authentication directory environment, namely passwords that appear to meet complexity requirements but are in actuality weak.
Natively, Active Directory does not validate the passwords being entered. Although we can force complexity, we still have problems of users changing their passwords to ones that are still easily guessed. Some users just replace letters with special characters. A good example: Let’s say that in the past my default password was anderson1234, now with complexity being increased in Active Directory policies, I could get away with @nd3rS0n1234 just fine, but at the end of the day, it is still easy to be guessed.
Password protection feature design
When taking advantage of the Password Protection feature in your Active Directory, the solution requires two pieces of software: Azure AD Password Protection Proxy service, which is going to be responsible for downloading the policies from Azure Active Directory and cache such information to be consumed by the Active Directory domain controllers, and the Azure AD Password Protection Agent service that is installed on the domain controller and every hour communicates with the Azure AD Password Protection Proxy to retrieve the latest policies.
The entire solution is depicted in the image below (provided by Microsoft documentation) and summarizes the entire process. The Azure AD Password Protection Proxy Service is the one responsible for communicating with Azure Active Directory and retrieve and cache the Password Protection Policy, and the domain controllers will have the Azure AD Password Protection between the LSASS and the Active Directory Database, and that component will be the one allowing or not allowing a password to go through.
Some important points about this feature that I found out during the testing phase:
- No schema upgrades required in your Active Directory.
- When using a custom banned password list, you will require at least Azure Premium P1 license.
- When using hybrid environments, the minimum license requirement is Azure Premium P1.
- All domain controllers should have the agent installed to ensure consistency.
Configuring password protection service in Microsoft Azure
The configuration of this feature is a piece of cake. Logged on Azure Portal, click on Azure Active Directory, click on Authentication Methods located in the Security section.
The new blade will have the entire password protection (preview) feature. Yes! It is that simple! The Custom smart lockout feature requires just two settings: the threshold (how many failed login attempts before locking out), which by default is 10, and how long the lockout will be.
However, our focus in this is the Custom banned password section, where for the sake of the functionality we are going to enable a custom list and add some words that make sense to our company. Since all our users are from the Watchmen universe, it makes sense to add some keywords related to that in our list.
Since we want to take advantage of this feature in our Active Directory on-premises, make sure to enable it by selecting Yes in the Enable password protection on Windows Server Active Directory.
One last detail is how we want to use the feature. The recommendation is to use Audit and see the results first, see how it works, and after having good results, then we can turn the feature on by selecting Enforced.
Installing and configuring Azure AD password protection proxy service
The first step is to download both pieces of software required to be installed on-premises. One of them is going to be installed on the domain controllers and the other on a member server designated as Azure AD Password Protection Proxy service. You can download the software here.
Logged on to the member server that will be our Azure AD password protection proxy server, we need to execute the AzureADPasswordProtectionProxy.msi and accept the license agreements and that is it. The installation process does not require any additional configuration.
As a result of the installation process, a new service called Azure AD Password Protection Proxy is going to be created on the server and it should be running as depicted in the image below.
The entire software installation will be under the folder C:\Program Files\Azure AD Password Protection Proxy folder, and we need to run a couple of cmdlets to register this current server in the Azure AD and in the current forest.
Before going any further, we need to make sure that the path where the software was installed is part of your current environment, and that is the reason that we check the value of the environment variable PSModulePath before trying to import the module that was added to the server during the installation process.
It is much easier to run these PowerShell cmdlets below as Domain Administrator and use an account as Global Administrator in the credentials. The initial portion of the script below is shown in the image below.
$env:PSModulePath Import-Module AzureADPasswordProtection $Azurecred = Get-Credential Register-AzureADPasswordProtectionProxy -AzureCredential $Azurecred Register-AzureADPasswordProtectionForest -AzureCredential $Azurecred
A service connection point will be created on the machine that is designated as Azure AD Password Protection Proxy service, and we can check this out using ADSIEdit.msc.
Installing Azure AD password protection agent on a domain controller
The installation of the domain controller agent is much easier than the proxy server, but it requires a restart of the server as part of the process. Make sure to schedule a restart after deploying the agent.
Just execute the AzureADPasswordProtectionDCAgent.msi and use default settings — be careful with the last screen because it will ask for the restart of the server.
Because we will have more than a single domain controller using the policies from the proxy server, a folder is created in the SYSVOL\<domain>\Policies with the password policies retrieved from Azure AD. The agent on the domain controller will check for any updates on that location.
Testing the password protection feature
Now that we have the infrastructure deployed, we can start testing our environment with our user Walter Kovacs (also known as Rorschach in the Watchmen universe!). And because he is a superhero, he thinks that he is protected from bad guys, so he tries to type in W@tchmen and because we are in Audit mode he will be able to change the password just fine.
Note: By default, your current domain policy will have an age policy of one day, which means that a test account created today will fail to change their password. Keep that in mind when testing.
How can we monitor the behavior of the Azure AD password protection feature? That is easy. Logged on the domain controller, open Event Viewer, and navigate to Applications and Services Logs\Microsoft\AzureADPasswordProtection\DCAgent\Admin double click on the entries on the right side.
The error message is descriptive and also informs if the password would have been rejected by either Microsoft Global or per-tenant banned password, and that will give an idea how much consideration your end users are having when creating complex passwords.
That’s it for the Azure AD password protection feature. It is relatively easy to deploy and easier to configure, but keep in mind that we are covering a preview feature and some changes may happen before the product is final.
Featured image: Shutterstock
Can these password protection accessible via Graph API or PowerShell?