Deploying On-premises Microsoft Entra Password Protection for Enhanced Security

 

Introduction

In today's digital landscape, users often choose weak passwords, making their accounts susceptible to brute-force and dictionary-based attacks. These passwords might include names of local sports teams, schools, or popular figures, all of which are easy to guess. To mitigate this vulnerability, Microsoft Entra Password Protection enforces a global and custom list of banned passwords. When a user tries to set a password that matches an entry on this list, the change request fails, ensuring only strong passwords are allowed.

For organizations with on-premises environments, deploying Microsoft Entra Password Protection can add a critical layer of security to Active Directory Domain Services (AD DS). This setup blocks weak or easily guessable passwords and allows administrators to customize the banned password list with terms relevant to their organization. This blog will guide you through the design principles, architecture, and deployment process for implementing Microsoft Entra Password Protection in an on-premises environment.

Design Principles

Microsoft Entra Password Protection is built with key design principles to ensure robust security:

• No Internet Dependency for Domain Controllers (DCs): DCs do not require direct internet access.
• No Additional Network Ports: No new network ports need to be opened on DCs.
• Schema Integrity: It doesn’t require schema modifications; it uses existing AD DS objects.
• Compatibility: Any AD DS domain or forest functional level is supported.
• Security: No user passwords in plain text ever leave the DC, ensuring data privacy.
• Independence from Other Entra Features: It does not depend on features like Microsoft Entra Password Hash Sync (PHS).
• Incremental Deployment: Password policies apply only where the DC Agent is installed, allowing phased deployments.

Architecture and Components

The following are core components of Microsoft Entra Password Protection in an on-premises AD DS environment:

1. Password Protection Proxy Service: This runs on any domain-joined machine in the AD DS forest and forwards password policy requests from DCs to Microsoft Entra ID.
2. DC Agent and Password Filter DLL: The Password Filter DLL receives user password validation requests, forwarding them to the DC Agent service running locally on the DC, which then processes requests using the local password policy.
3. Service Connection Point Objects: Both Proxy and DC Agents create these objects in Active Directory for communication, reporting, and diagnostics.

Image Source: Microsoft

How Microsoft Entra Password Protection Works

Microsoft Entra Password Protection enforces password strength by integrating a global banned password list with a customizable list specific to your organization. This feature is designed to detect and block weak passwords, including variations that are easy to guess. Here’s a breakdown of how Microsoft Entra Password Protection operates within your on-premises Active Directory Domain Services (AD DS) environment.

1. Policy Download and Storage

When a new password policy is available, the DC Agent initiates a request for the policy from an available Proxy service within the AD DS forest. This proxy then forwards the request to Microsoft Entra ID, retrieves the updated policy, and sends it back to the DC Agent. Upon receiving the policy, the DC Agent securely stores it in the sysvol folder of the domain, making it readily accessible for password validations.

2. Policy Validation Process

During password change or reset events, the DC Agent validates the new password against the locally stored policy. This validation process involves checking the password against both the global banned password list and any organization-specific terms defined in the custom banned password list. If the password matches any banned terms or weak patterns, the request to change the password fails, prompting the user to choose a stronger password.

3. Detection of Weak Passwords and Variants

When a password is submitted, Microsoft Entra Password Protection goes through a series of steps to detect weak or easily guessable passwords:

• Normalization: The password is normalized by converting uppercase letters to lowercase and substituting characters like "@" for "a" and "$" for "s" to identify variants of banned terms.
• Fuzzy Matching: The system uses fuzzy matching, meaning it can detect minor variations of banned terms, even if the password doesn’t exactly match an entry in the banned lists. For example, a password with a one-character difference from a banned term, such as “passw0rd” instead of “password,” would still be flagged as weak.
• Substring Matching: Certain substrings, like user names or tenant names (for cloud scenarios), are flagged if they appear in the password, further reducing the likelihood of easily guessable passwords.

Note: Substring matching is only enforced for names, and other terms, that are at least four characters long.

4. Scoring System

Microsoft Entra Password Protection employs a scoring system that evaluates the password’s strength by assigning points for each character that doesn’t match banned terms. A password must meet a minimum threshold of five points to be accepted. If banned terms reduce the score below this threshold, the password change request is denied, and the user is prompted to create a stronger password.

Key Considerations and Features

• Tenant-Specific Policies: Policies are specific to each Microsoft Entra tenant and combine both global and custom banned-password lists.
• Secure Communication: DC Agent communicates with the Proxy service via RPC over TCP without listening on any network port.
• Audit and Enforce Modes: Start deployments in Audit mode to monitor password policies without enforcement. Switch to Enforce mode once fully tested.
• Existing Passwords: Microsoft Entra Password Protection only evaluates passwords during reset events. Existing passwords are not affected.
• High Availability: Multiple Proxy servers ensure high availability. Cached policies on DC Agents allow continued enforcement even if all Proxy servers are temporarily unavailable.

License Requirements for Microsoft Entra Password Protection

• Cloud-only Users
• Global Banned Password List: Requires Microsoft Entra ID Free
• Custom Banned Password List: Requires Microsoft Entra ID P1 or P2
• Users Synchronized from On-premises AD DS
• Both Global and Custom Banned Password Lists require Microsoft Entra ID P1 or P2

Deployment Requirements

1. Software Prerequisites: All machines need the Universal C Runtime and .NET 4.7.2.
2. Domain Registration: Register the Windows Server AD forest with Microsoft Entra ID using an account with domain administrator privileges.
3. Network Configuration: Ensure network connectivity between the DC and Proxy service, with necessary RPC and TLS settings.
4. Distributed File System Replication (DFSR): Only domains using DFSR for sysvol replication can deploy the DC Agent.

Proxy Service Requirements:

• Operating System: Windows Server 2012 R2 or later.
• Network Access: Configure outbound TLS 1.2 HTTP traffic and Machines hosting the Microsoft Entra Password Protection Proxy service must be configured to allow domain controllers to log on to the proxy. This access is managed through the "Access this computer from the network" privilege assignment.
• All machines where the Microsoft Entra Password Protection Proxy service will be installed must have network access to the following endpoints:
• https://login.microsoftonline.com - For authentication requests
• https://enterpriseregistration.windows.net - For Microsoft Entra Password Protection functionality
• https://autoupdate.msappproxy.net - For Microsoft Entra Password Protection auto-upgrade functionality

Note: Deploying the Microsoft Entra Password Protection Proxy service is mandatory for Microsoft Entra Password Protection, even if the domain controller has direct outbound internet connectivity.

Microsoft Entra Connect Agent Updater: If using an HTTP proxy, follow recommended guidelines to ensure the Agent Updater functions correctly.

Important Notice:

The Microsoft Entra Password Protection Proxy and the Microsoft Entra Application Proxy install different versions of the Microsoft Entra Connect Agent Updater service. These versions are incompatible if installed on the same machine. Installing both proxies side by side will prevent the Agent Updater service from connecting to Azure for software updates. Therefore, you should avoid installing Microsoft Entra Password Protection Proxy and Application Proxy on the same server.

Multiple Forest Considerations: Deploying Microsoft Entra Password Protection across multiple forests requires no additional steps. Each forest is configured independently, and each Proxy supports only the domain controllers within its own forest. The software operates independently across forests, with no awareness of other forests' configurations, even with Active Directory trust settings.

Microsoft Entra Password Protection for on-premises Deployment Steps

1. Audit Mode Deployment: Deploy the Proxy and DC agents in Audit mode, allowing administrators to monitor impact.
2. Evaluate Operational Readiness: Confirm that operational processes support strong passwords and educate users on security policies.
3. Full Deployment and Enforce Mode: Once validated, move to Enforce mode to apply the password policy fully.
4. Monitoring and Maintenance: Regularly monitor password policy compliance through event logs and assess the impact on the domain controller environment.

Configuring Microsoft Entra Password Protection

To set up Microsoft Entra Password Protection for on-premises Active Directory, follow the steps below and ensure all prerequisites are met before enabling the service.

Note: Once Microsoft Entra Password Protection is deployed and enabled, it applies uniformly to all users, providing equal security benefits across the organization. This includes protecting accounts that are not synchronized via Azure AD Connect..

1. Download Required Software

For deploying Microsoft Entra Password Protection on-premises, you’ll need two installers:

• Microsoft Entra Password Protection DC Agent (AzureADPasswordProtectionDCAgentSetup.msi)
• Microsoft Entra Password Protection Proxy (AzureADPasswordProtectionProxySetup.exe)

Both installers are available on the Microsoft Download Center.

After the download is complete, you can proceed with the installation.

2. Installing and Configuring the Microsoft Entra Password Protection Proxy Service

The Microsoft Entra Password Protection proxy service is usually installed on a member server within your on-premises AD DS environment. Once installed, the proxy communicates with Microsoft Entra ID to maintain copies of both the global and custom banned password lists for your tenant. Follow these guidelines when selecting and configuring servers for the proxy service:

• Single Forest Limitation: Each proxy service instance supports password policies for only one forest. The server must be joined to a domain within that forest.
• Flexible Domain Placement: You can install the proxy in root or child domains, or both.
• Network Connectivity Requirement: Ensure at least one domain controller in each domain of the forest can connect to a proxy server.
• Testing on Domain Controllers: While you can run the proxy service on a domain controller for testing, this configuration requires internet connectivity and may pose a security risk. It’s recommended for testing only.
• Redundancy for Reliability: For high availability, deploy at least two proxy servers per forest.
• Restrictions on Read-only Domain Controllers: The proxy service cannot run on a read-only domain controller.
• Uninstallation: If needed, you can remove the proxy service using "Add or remove programs" without manually cleaning up any proxy-maintained state.

To install the Microsoft Entra Password Protection proxy service, follow these steps:

1. Run the Installer

Launch the AzureADPasswordProtectionProxySetup.exe installer to begin the setup.

Note: The Windows Firewall service must be active during the installation. If it’s disabled, temporarily enable it to prevent installation errors. Once installed, the proxy service has no dependency on Windows Firewall.

If you’re using a third-party firewall, configure it to meet deployment requirements, including allowing inbound access to port 135 and the proxy RPC server port.

2. PowerShell Module Setup

The installation includes a PowerShell module (AzureADPasswordProtection). Open PowerShell as an administrator and load the module:

Import-Module AzureADPasswordProtection

Use the 64-bit version of PowerShell for full compatibility.

3. Verify Proxy Service Status

Confirm the proxy service is running with the following command:

Get-Service AzureADPasswordProtectionProxy | fl

The service should display a "Running" status.

4.Register the Proxy with Microsoft Entra ID

The proxy needs to be registered with Microsoft Entra ID using the Register-AzureADPasswordProtectionProxy cmdlet. This requires Global Administrator credentials initially; subsequent registrations may use Security Administrator credentials.

For the registration you can use any of the two authentication modes:

        Interactive Authentication:

Register-AzureADPasswordProtectionProxy -AccountUpn 'yourglobaladmin@yourdomain.com'

Or You can use Device-code Authentication

Register-AzureADPasswordProtectionProxy -AccountUpn 'yourglobaladmin@yourdomain.com' -AuthenticateUsingDeviceCode

Note: Follow the link provided in the prompt to complete authentication in a browser.

5.Register on-premise AD Forest with Entra

To establish communication between your on-premises Active Directory forest and Azure, you need to register the forest using the following command 

Register-AzureADPasswordProtectionForest -AccountUpn "'yourglobaladmin@yourdomain.com'"  

6.Verify Proxy Service Health

Run the following command to confirm the Proxy Health status:

Test-AzureADPasswordProtectionProxyHealth -TestAll

If all test results show as "Passed," your setup is in good condition.

The Microsoft Entra Password Protection Proxy service supports automatic upgrades via the Microsoft Entra Connect Agent Updater, which installs alongside the proxy service. Automatic upgrade is enabled by default but can be managed using the Set-AzureADPasswordProtectionProxyConfiguration cmdlet by adding parameters like -StaticPort <Portnumber> -AutoUpgradeEnabled  <$True, $False>  , 

the current setting viewable via Get-AzureADPasswordProtectionProxyConfiguration. 

Enabling automatic upgrades is recommended to ensure critical security updates are applied.

To check the installed software version of all proxy servers, use the Get-AzureADPasswordProtectionProxy cmdlet.

For manual upgrades, download the latest AzureADPasswordProtectionProxySetup.exe from the Microsoft Download Center and run it directly. This in-place upgrade requires no uninstallation or reboot.

3.Installing and Configuring the Microsoft Entra Password Protection DC Agent Service

Before installing the Microsoft Entra Password Protection DC agent, ensure that Microsoft Entra Password Protection is configured in Audit mode.

1. Sign in to the Microsoft Entra admin center with Authentication Administrator permissions.
2. Go to Protection > Authentication methods > Password protection.
3. Set Enable password protection on Windows Server Active Directory to Yes.
4. Set the Mode to Audit initially for monitoring purposes.

Operating Modes

• Audit Mode: This "what-if" mode logs password violations without enforcing them, allowing administrators to assess impact.
• Enforced Mode: This mode blocks insecure passwords based on policy. Users will receive error messages similar to traditional password complexity errors if their password is rejected, guiding them to select secure alternatives.

Note: Microsoft Entra Password Protection doesn’t control the specific error message displayed when a weak password is blocked, so users may see various system-generated messages depending on the scenario.

Installation

Run the AzureADPasswordProtectionDCAgentSetup.msi package to install the DC agent service. A system restart is required to activate or remove the password filter DLL, as this is necessary for proper loading and unloading.

Activation

After the DC agent software is installed and the domain controller is restarted, the setup is complete. No additional configuration is needed. Password changes on the domain controller will be validated against the banned password lists configured in Microsoft Entra ID.

Tip: You can install the DC agent on a machine that isn’t yet a domain controller. The service will remain inactive until the machine is promoted to a domain controller.

Upgrading the DC Agent

For upgrades, download the latest AzureADPasswordProtectionDCAgentSetup.msi from the Microsoft Download Center and run it directly. This in-place upgrade doesn’t require uninstalling the previous version, but a reboot is necessary.

Checking the Installed Version

To check the software version of installed DC agents, use the following PowerShell cmdlet:

Get-AzureADPasswordProtectionDCAgent

Verify that the DC agent is healthy

To check the Password Protection DC Agent health status, use the following PowerShell cmdlet

Test-AzureADPasswordProtectionDCAgentHealth -TestAll

Monitoring and Reporting After Deploying Microsoft Entra Password Protection

After deploying Microsoft Entra Password Protection, it’s essential to monitor and report on its activity. This overview explains various monitoring techniques, event logs, and PowerShell cmdlets for tracking the use and performance of Microsoft Entra Password Protection.

Monitoring and Reporting Methods

Monitoring is done primarily through event log messages and PowerShell cmdlets. Both the DC agent and proxy services log events in the Windows Event Log. However, only the proxy server supports PowerShell cmdlets through the AzureADPasswordProtection module.

DC Agent Event Logging

Each domain controller with the DC agent installed logs password validation results and status messages to local event logs, located at:

• Applications and Services Logs > Microsoft > AzureADPasswordProtection > DCAgent > Admin
• Applications and Services Logs > Microsoft > AzureADPasswordProtection > DCAgent > Operational
• Applications and Services Logs > Microsoft > AzureADPasswordProtection > DCAgent > Trace (off by default)

The Admin log is the primary source for monitoring the behavior of the software.

Event ID ranges:

• Password Filter DLL: 10000-19999
• Service Hosting Process: 20000-29999
• Policy Validation Logic: 30000-39999

Password Validation Events in the Admin Log

The DC agent logs events for each password validation attempt, providing details on:

• Whether a password was being set or changed
• Validation success or failure
• Reason for failure (global policy, organizational policy, or both)
• Mode (Audit only or Enforced)

For a successful validation, one event is logged from the password filter DLL. For a failed validation, two events are logged, one from the service and one from the password filter DLL.

Microsoft Entra ID password policy rejects password in Audit Mode

When Microsoft Entra ID rejects a password, it logs Event ID 10025 and Event ID 30009.when i used P@ssw0rd as user account password.

Event ID 10025 The reset password for the specified user would normally have been rejected because it did not comply with the current Azure password policy. The current Azure password policy is configured for audit-only mode so the password was accepted. Please see the correlated event log message for more details.

Event ID 30009 The reset password for the specified user would normally have been rejected because it matches at least one of the tokens present in the Microsoft global banned password list of the current Azure password policy. The current Azure password policy is configured for audit-only mode so the password was accepted.

Microsoft Entra password policy accepts password in Audit Mode

When Microsoft Entra ID validates a password as compliant, it logs Event ID 10015

Event ID 10015 The reset password for the specified user was validated as compliant with the current Azure password policy.

PowerShell Reporting for Password Validation

Use the Get-AzureADPasswordProtectionSummaryReport cmdlet to generate a summary report on password validation activities. You can scope the report using the following parameters:

• –Forest (default if no parameter is specified)
• –Domain
• –DomainController

Note: If only one domain controller has the DC agent installed, this cmdlet will read events from that DC only. To retrieve events across multiple DCs, install the DC agent on each one.

The cmdlet queries the Admin event log and summarizes password validation outcomes based on event counts.

Enforce Microsoft Entra Password Protection

Enforced mode is the final operational setting for Microsoft Entra Password Protection. Like audit mode, the DC agent service evaluates each incoming password against the active policy. However, in enforced mode, any password deemed insecure by the policy is actively rejected.

When a password is rejected in enforced mode, the end user will see an error message similar to those used in traditional on-premises password complexity enforcement. For instance, at the Windows logon or password change screen, a user might encounter a message such as:

"Unable to update the password. The value provided for the new password does not meet the length, complexity, or history requirements of the domain."

This message is one example and can vary depending on the software or specific scenario attempting to set the insecure password.

Users may need guidance from IT staff to understand the new password requirements and to select secure passwords accordingly.

Sign in to the Microsoft Entra admin center and go to Protection > Authentication methods > Password protection. Set the mode to Enforce, then click Save. Additionally, add some custom banned passwords to the list for testing purposes

Note: When set to Enforce, users will be blocked from using banned passwords, and each attempt will be logged.

Important: To apply the changes immediately, restart the Microsoft Entra Password Protection DC Agent on all Domain Controllers.

Restarting Azure AD Password Protection DC Agent

Policy Enforcement status Logged

Validating AD Password Change using Active directory Users and Computers

As an admin, I will use the Active Directory Users and Computers console to change a user's password to Contoso@1234 and observe the error message that appears.

Please note that the name Contoso has already been added to the custom banned password list in Entra ID.

Error screen appeared and its telling that 

Active Directory Domain Services

Windows cannot complete the password change for Alex Thomas because: The password does not meet the password policy requirements. Check the minimum password length, password complexity and password history requirements.

In the Event Viewer, Event Log ID 10017 and Event Log ID 30027 have been triggered:

• Event ID 10017: The attempted password reset for the specified user was rejected as it did not comply with the current Azure password policy. Refer to the correlated event log message for further details.
  
  
  
• Event ID 30027: The password reset was rejected because the chosen password matched multiple entries in the combined Microsoft global and per-tenant banned password list under the current Azure password policy.

End -User Password Reset experience from Windows 10/11 PC 

Next, we’ll test the end-user password reset experience on a Windows 10/11 PC. Log in as the user, then press Ctrl + Alt + Delete and select the Change Password option

Conclusion

Deploying Microsoft Entra Password Protection on-premises significantly strengthens your organization’s security by enforcing strong password policies and blocking weak, easily guessed passwords. With customizable banned password lists and robust monitoring tools, this solution ensures that user credentials are better protected against common attacks. Starting with audit mode allows you to assess the policy’s impact, while enforced mode provides firm security across your AD DS environment. By implementing these protections, your organization can confidently reduce the risk of unauthorized access and improve overall password hygiene.