In a previous article, I mentioned that password expiration policies could be turned off entirely, as long as additional technical measures are in place to protect organizations from weak passwords, new password combinations, and those that have already been compromised. Among the recommendations cited was the enigmatic Azure AD Microsoft Entra Password Protection service, which Microsoft claims is a “cure” for these problems. Is it really effective? Let’s find out!
What is Azure AD Microsoft Entra Password Protection?
In the simplest terms, Azure AD Microsoft Entra Password Protection is just a list of forbidden passwords (global and our own) that is checked every time a user sets or resets a password. If Microsoft detects that an employee is trying to use a weak password or one that has already been part of a data leak, the operation is blocked and the company is protected from its own employees 🙂
Architectural diagram
Microsoft Entra
If you use cloud-only accounts, things are easy. The Azure AD Microsoft Entra Password Protection solution already protects your accounts by default, so you don’t need to do anything. However, you should check to see if the default settings are sufficient for you. For example, you can add your own custom banned phrases to Microsoft’s global password list.
Active Directory Domain Services (AD DS)
In this particular scenario to run Azure AD Microsoft Entra Password Protection we need additional agents on the domain controllers and at least one proxy server. The proxy server is responsible for retrieving the policies, including the forbidden password database from Azure AD Entra ID. The agent on the other hand, fetches the settings locally from the proxy server, which is quite important from a security standpoint for the domain controllers, as it eliminates the need for them to access the Internet directly.
Requirements and general remarks
When implementing Azure AD Microsoft Entra Password Protection, keep the following points in mind:
- On each domain controller that is not a Read Only Domain Controller (RODC), Password Protection DC Agent must be installed. In addition, the installer will require a reboot of the server, so you should plan this well.
- The proxy component may be installed on multiple servers to ensure high availability. According to Microsoft’s recommendations, two machines should be enough for us.
- If a disaster happens and all proxy servers stop working, then… well, everything will be fine because domain controllers with the password protection agent keep a local copy of the cloud password policy. Of course, our goal is to prevent such a scenario from happening, but a little server unavailability will not mess up our environment :winking_face:
- DC Agent requires no Internet connection, so we don’t need to expose domain controller traffic to the world.
- Proxy requires an Internet connection, but we can limit it to the necessary communication with
AzureEmtra. - If you are looking for an appropriate server to host an additional role don’t install the proxy component on a server with
Azure ADMicrosoft Entra Application Proxy. - The proxy has an auto-upgrade option, so we don’t have to worry about keeping it up to date. On the other hand, the DC Agent doesn’t, so we have to make sure to keep the agents up to date.
- Make sure you have Windows Server 2012 R2 or later, otherwise
Azure ADMicrosoft Entra Password Protection won’t work :winking_face:
All technical requirements are available in Microsoft Docs. You’ll also find a list of ports, protocols, and endpoints that your Network Administrator is sure to ask about.
License requirements
Why do the license terms have a separate paragraph? Because they are easy to miss 🙂
Conclusion: if we want to implement Azure AD Microsoft Entra Password Protection for on-premises accounts then we should have at least Azure AD Premium P1 Microsoft Entra ID P1 plan.
The notation below the table is also quite interesting:
On-premises AD DS users that aren’t synchronized to Azure AD also benefit from Azure AD Password Protection based on existing licensing for synchronized users.
This means that if the majority of your employees don’t use Microsoft 365, they will still need an Azure AD Premium Microsoft Entra ID P1/P2 license. This makes sense because Azure AD Microsoft Entra Password Protection works for the entire domain without the ability to create exceptions.
Configuration
Before installing the agent and proxy, it’s a good idea to make sure that the servers you’re working on have the latest updates (Universal C Runtime) and .NET Framework 4.7.2 installed. Both of these components are required for Azure AD Microsoft Entra Password Protection to work properly.
It’s also a good idea to make sure that the necessary network traffic has been prepared in advance and isn’t blocked. Just in case, so there are no surprises during configuration. For more information, please refer to the technical requirements.
Azure AD Microsoft Entra Password Protection proxy service
We start the configuration by installing the proxy service. You can download the installer from Microsoft Download Center and run the software installation.
After an exciting installation process, a new PowerShell module AzureADPasswordProtection should be available on our server. It’s worth checking that the module imports without errors and that the proxy service is started correctly on the server.
|
|
Now we can register our proxy server with Azure AD Microsoft Entra using the Register-AzureADPasswordProtectionProxy
command. To do this, we need Global Administrator privileges.
|
|
After successfully logging in with the Global Admin account, our server will be registered in Azure AD Entra ID. Unfortunately, we won’t get a nice success message, but we can preview the status of the proxy service with the next command.
|
|
As you can see, the proxy service has been successfully registered and is ready to use. Well, almost. We still need to register our Active Directory forest in Azure AD Entra ID once per forest. The registration process is the same as before, only the command is different.
|
|
We are now ready to install the agent on the domain controller.
Azure AD Microsoft Entra Password Protection DC agent
The installation of the DC Agent is much easier than the installation of the proxy service. Download the DC Agent installer from Microsoft Download Center and run the software installation..
After the typical installation process, you will be prompted to restart the server.
Is that all? Yes, after a reboot our agent is now fully functional and doesn’t require any additional configuration 🙂
The status of the agent can also be checked with the Test-AzureADPasswordProtectionDCAgentHealth
command.
|
|
By default Azure AD Microsoft Entra Password Protection doesn’t enforce protection after installing agents and proxies. We can change this in the Azure Entra Portal. So let’s go to the service settings and see what we can configure.
Microsoft Azure Entra admin center
Azure AD Microsoft Entra Password Protection settings can be found under Security -> Authentication methods -> Password protection
in Azure AD.
To test the service, we will select the Enforce custom list option and add our own banned phrases. By default Azure AD Microsoft Entra Password Protection works in audit mode, which means it doesn’t block banned passwords but logs such operations in the event log. We change this by configuring the Mode value to Enforced.
Save the settings and we’re done. From now on, once the settings are propagated to the domain, weak passwords will be blocked automatically.
Azure AD Microsoft Entra Password Protection tests
Enforcing password policy update
If we don’t want to wait for automatic policy updates, we can force our proxy server to download the latest policies. Of course, we can wait a few minutes or hours, but who has time for that? 🙂
Let’s log on to our test domain controller, run CMD, and restart the Password Protection Agent with the following command:
|
|
Next, we search the event log for an event with ID 30006.
Applications and Services Log > Microsoft > AzureADPasswordProtection > DCAgent > Admin
As you can see, our policy is out of AuditOnly mode and ready for testing.
Banned passwords test
Before we start testing, it’s worth looking at how Microsoft blocks ‘weak’ passwords. Understanding the password evaluation system can have a drastic effect on your results and save you hours of troubleshooting 🙂
Password scoring is described [here] ( https://learn.microsoft.com/en-us/azure/active-directory/authentication/concept-password-ban-bad#how-are-passwords-evaluated).
With short words like mine, testing can be really difficult, because if you add a new word to the “forbidden” one, the algorithm may consider the new password as safe.
Even if a user’s password contains a banned password, the password may be accepted if the overall password is otherwise strong enough. A newly configured password goes through the following steps to assess its overall strength to determine if it should be accepted or rejected
— Microsoft Docs - Eliminate bad passwords using Azure Active Directory Password Protection
The password change notifications that are displayed don’t make things any easier either. Microsoft has taken the easy way out by using existing notifications. This makes it unclear whether our password is being blocked by built-in policies or by Azure AD Microsoft Entra Password Protection….
What do these notifications look like?
Admin perspective
User perspective
How can I check if my password has been blocked by Azure AD Microsoft Entra Password Protection?
We don’t get much out of the notifications, so we need a better way to check what has blocked our password.
As it turns out, the best method is …. an event log on a domain controller with the Azure AD Microsoft Entra Password Protection agent.
The full list of IDs is available on Microsoft Docs.
As an alternative, it is possible to use PowerShell to generate statistics for the entire service.
|
|
Solution without flaws?
Now that the tests are over, it’s time to complain a little. In general, I have two reservations about the service.
Firstly, we don’t know the contents of the Global Banned Passwords list, so we have to trust that Microsoft’s own list is kept up to date and is actually protecting us. This may not be to everyone’s taste.
…Cyber-criminals also use similar strategies in their attacks to identify common weak passwords and variations. To improve security, Microsoft doesn’t publish the contents of the global banned password list…
…The global banned password list isn’t based on any third-party data sources, including compromised password lists…
— Microsoft Docs - Eliminate bad passwords using Azure Active Directory Password Protection
The second thing is that Azure AD Microsoft Entra Password Protection doesn’t block passwords that have already been set in the domain. It only works if the password is changed or reset after the service is enabled. If an employee has previously managed to set a dupa123
password, it will continue to work until the next time it is changed.
Psst!… If you’re looking for a way to find leaked passwords in your Active Directory, I’ve described it in this post.
Conclusion
Today we learned a little more about Azure AD Microsoft Entra Password Protection. The only question left is whether it is worth implementing in your organisation. In my opinion, as always, it depends.
If you have an on-premises environment and you are licensing all your employees with Azure AD Premium Entra ID P1/P2, then why not take advantage of this service? After all, it’s something you already had in your licences that could improve your company’s security.
On the other hand, if your implementation requires additional purchases, you might use my complaints as an argument to do some market research and look for third-party solutions.
The choice is yours or your IT manager’s 🙂
Additional resources
- Microsoft Docs - Plan and deploy on-premises Azure Active Directory Password Protection
- Microsoft Docs - Eliminate bad passwords using Azure Active Directory Password Protection
- Microsoft Docs -Monitor and review logs for on-premises Azure AD Password Protection environments
- Microsoft Docs - Azure AD Password Protection on-premises FAQ