Improving the security of user authentication has always been a top priority for many organizations and one of the products I’ve been working with which has become very popular is Microsoft’s Azure AD Password Protection. For those who are not familiar with this Microsoft offering, this product essentially allows you to leverage the password protection Azure provides to cloud accounts to be extended to your on-premise Active Directory. The following are some highlights of the product:
- Global banned passwords list > Microsoft has compiled and continue to maintain a list of passwords that their security team has deemed to be a security risk rom real-world security telemetry on actual password spray attacks. This list is not disclosed to the public because it would render it ineffective.
- Custom banned password list > Organizations can use this feature to ban passwords they deem to be a security risk. These passwords are generally company and product names, location, and other words that can be easily guessed because it relates to the company in some way or another. Note that there is a 16 character limit.
- Advanced password evaluation > Microsoft outlines the method they use to evaluate the strength of a password (https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-password-ban-bad) that includes normalization and banned lists. A score is calculated based on the formula outlined in the document I provided and I would say that it is a great method.
- Augments on-premise Active Directory password policy > Azure AD Password Protection (and its 8 character limit) does not replace the on-premise password policy but rather extends it. The on-premise password policy configuration will be enforced for users.
- Reduced dependency on Azure > Azure AD password hash sync is not a requirement and the on-premise domain controllers do not need to constantly connect to Azure through the proxy service for password checks as the policy is downloaded locally every hour. In the event that registered proxy servers are not available, the Azure AD Password Protection DC agents continue to enforce their cached password policy.
- Domain controllers does not need to maintain a persistent connection to Azure > The domain controllers rely on the Azure AD Password Protection Proxy Service to retrieve the password policy so there is no requirement to open additional outbound access.
- Audit mode > You can’t actually turn Azure AD Password Protection for a subset of your on-premise Active Directory but you are provided with an audit mode that logs whether a password would have been accepted or rejected. I typically use this with a group of pilot users during the test phase.
There are an abundance of documentation provided from Microsoft that I found useful when I need refresh my memory so I will list them here:
Enforce Azure AD password protection for Windows Server Active Directory – How Azure AD Password Protection works
https://docs.microsoft.com/bs-latn-ba/azure/active-directory/authentication/concept-password-ban-bad-on-premises
Plan and deploy on-premises Azure Active Directory Password Protection – Deployment guide
https://docs.microsoft.com/bs-latn-ba/azure/active-directory/authentication/howto-password-ban-bad-on-premises-deploy
Eliminate bad passwords in your organization – How passwords are evaluated and how global and custom banned password lists work
https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-password-ban-bad
Enable on-premises Azure Active Directory Password Protection – Enabling and disabling the password policy for testing and production
https://docs.microsoft.com/bs-latn-ba/azure/active-directory/authentication/howto-password-ban-bad-on-premises-operations
Password Guidance – Some of the information is a bit dated as the publication was written in May 2016 but the concepts are still useful
https://www.microsoft.com/en-us/research/publication/password-guidance/
With all the information provided above, let’s proceed with the deployment.
Environment Prerequisites
- The installers for the proxy and DC agent are available to be downloaded without a login and can be retrieved at the following URL: https://www.microsoft.com/en-us/download/details.aspx?id=57071
- Azure AD Premium P1 license licenses are required for the organization
- You can deploy both the Azure AD Password Protection Proxy Server and DC Agent directly on a domain controller for testing but this is not recommended, instead, have at least 1 x Azure AD Password Protection Proxy Server residing on a member server in the domain and the DC Agent installed on all the domain controllers
- Multiple forests are supported but if each Azure AD Password Protection Proxy Server can only support one forest and its domain controller
- Do not install the Azure AD Password Protection Proxy Server on a RODC as it is not supported
- Load balancers are not necessary as the Azure AD Password Protection DC agent uses a simple round-robin-style algorithm when deciding which proxy server to call
- All of the servers, including the domain controllers, need to have the Universal C Runtime installed
- The Key Distribution Service must be enabled on all domain controllers in the domain that run Windows Server 2012. By default, this service is enabled via manual trigger start
- Network connectivity over RPC endpoint mapper port 135 and the RPC server port must exist between at least one domain controller in each domain and at least one server that hosts the proxy service
- All servers that have the Azure AD Password Protection Proxy service installed must have network access to the following endpoints:
- https://login.microsoftonline.com – Authentication requests
- https://enterpriseregistration.windows.net – Azure AD Password Protection functionality
Azure AD Password Protection DC agent Requirements
- The install requires a server reboot
- Operating system must be Windows Server 2012 or later
- Domain and forest functional does not need to be Windows Server 2012
- .NET 4.5 must be installed
- The domain controllers should be using Distributed File System Replication (DFSR) for sysvol replication
Azure AD Password Protection proxy service Requirements
- The install does not require a server reboot
- Operating system must be Windows Server 2012 or later
- .NET 4.5 must be installed
- Must be configured to grant domain controllers the ability to log on to the proxy service (this ability is controlled via the “Access this computer from the network” privilege assignment)
- Outbound TLS 1.2 HTTP traffic allowed
- A Global Administrator account will be used to register the proxy service and forest with Azure AD
- Network access must be enabled for the set of ports and URLs specified here: https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/application-proxy-add-on-premises-application#prepare-your-on-premises-environment
- HTTP proxy is supported but additional configuration must be performed (this post will not demonstrate the configuration)
Microsoft Azure AD Connect Agent Updater prerequisites Requirements
The Microsoft Azure AD Connect Agent Updater service is installed along with the Azure AD Password Protection Proxy service. In the event where any of the following applies, further configuration would be required:
- If your environment uses an HTTP proxy server, follow the guidelines specified here: https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/application-proxy-configure-connectors-with-proxy-servers
- The Microsoft Azure AD Connect Agent Updater service also requires the TLS 1.2 steps specified here: https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/application-proxy-add-on-premises-application#tls-requirements
Configure Azure AD Password Protection
Enable the Azure AD Password Protection service by logging into https://portal.azure.com and navigating to Azure Active Directory > Security > Authentication Methods > Password Protection and configure the following:
Enable password protection on Windows Server Active Directory: Yes
Mode: Audit
Deploying the Azure AD Password Protection Proxy service
Begin by verifying that .NET 4.5 or later is installed by executing the following cmdlet:
Get-ItemProperty -Path “HKLM:SOFTWAREMicrosoftNET Framework SetupNDPv4Full” | Format-List
Compare the version number with the following table to verify that a supported version is installed:
Verify that the Windows Firewall service is running:
Proceed to install the Azure AD Password Protection Proxy service onto the proxy server:
Launch PowerShell and execute the following cmdlet to verify that the proxy service has been installed:
Import-Module AzureADPasswordProtection
Get-Service AzureADPasswordProtectionProxy | FL
Proceed to register the proxy service with the following cmdlet:
Register-AzureADPasswordProtectionProxy -AccountUPN ‘<yourGlobalAdministrator@onmicrosoft.com>’
**Note that I’ve had two deployments where an error thrown but the second try completes:
Proceed to register the on-premises Active Directory forest with the following cmdlet:
Register-AzureADPasswordProtectionForest -AccountUpn ‘<yourGlobalAdministrator@onmicrosoft.com>’
You can verify the registration by reviewing the Audit Logs entries in the Azure portal:
Target: AADPasswordProtectionProxy
**Note that if there is an HTTP proxy in the environment for machines to reach the internet then there are extra steps required to be performed. The environment in this example does not have a HTTP proxy so I will not be demonstrating the process.
Deploying the Azure AD Password Protection DC Agent
Begin by verifying that DFSR is used to replicate the sysvol folder by executing the following cmdlet:
Get-ItemProperty -Path “HKLM:SYSTEMCurrentControlSetServicesDFSRParametersSysVolsMigrating SysVols” | Format-List
The Local State value should be 3. The following is where the parameter and value is stored in the registry:
Verify that .NET 4.5 or later is installed by executing the following cmdlet:
Get-ItemProperty -Path “HKLM:SOFTWAREMicrosoftNET Framework SetupNDPv4Full” | Format-List
Compare the version number with the following table to verify that a supported version is installed:
Ensure that the Kerberos Key Distribution Center service is started:
Verify that the Windows Firewall service is running:
Proceed to install the Azure AD Password Protection DC Agent onto the Domain Controller server:
Proceed to restart the domain controller:
Once the domain controller has been successfully restarted, verify that the Azure AD Password Protection DC Agent service has started:
Proceed by launching the Event Viewer then navigate to Applications and Services Logs > Microsoft > AzureADPasswordProtection > DCAgent > Admin and verify that the following event ID is logged indicating that the agent is successfully enforcing the Azure password policy:
Source: DCAgent
Event ID: 30006
Level: Information
User: System
The service is now enforcing the following Azure password policy.
Enabled: 1
AuditOnly: 1
Global policy date: 2019-11-03T00:00:00.000000000Z
Tenant policy date: 2020-02-20T22:35:50.188026500Z
Enforce tenant policy: 1
Review the Operational log and verify that the following event is logged:
Source: DCAgent
Event ID: 10000
Level: Information
User: System
The password filter dll has successfully loaded and initialized.
You should also see the following event logged indicating the agent has starting:
Source: DCAgent
Event ID: 20000
Level: Information
User: System
The Azure AD Password Protection DC Agent service is starting.
The following event will verify that the agent has started:
The Azure AD Password Protection DC Agent service has successfully started.
The following event will also be logged indicating that the specified certificate is used to authenticate with Azure:
The following forest certificate credential is being used for authentication to Azure.
Forest certificate thumbprint: FC5E044348BB950D3B3B515F5B39830B532E1C1D
Forest certificate NotBefore: 2020-02-20T21:30:21.000000000Z
Forest certificate NotAfter: 2021-02-20T09:25:17.000000000Z
Forest certificate object DN: CN=1192827B-F3E2-4B12-95A7-2070859A5C23,CN=Forest Certs,CN=Azure AD Password Protection,CN=Services,CN=Configuration,DC=corp,DC=domain,DC=com
Test Azure AD Password Protection
Prepare a test plan with multiple passwords to test and verify that the expected outcome is achieved. The following is an event that would be logged if the password is not expected to be accepted but is allowed because audit mode is configured:
Source: DCAgent
Event ID: 30029
Level: Information
User: System
The reset password for the specified user would normally have been rejected because it matched multiple tokens in the combined Microsoft global and per-tenant 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.
UserName: testuser
FullName: Test User
The following is an event that would be logged if the password is accepted because it is compliant with the Azure password policy:
Source: DCAgent
Event ID: 10015
Level: Information
User: System
The reset password for the specified user was validated as compliant with the current Azure password policy.
UserName: testuser
FullName: Test User
The following is an event that would be logged if the user of a custom banned password is detected:
Source: DCAgent
Event ID: 30003
Level: Information
User: System
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.
UserName: username
FullName: username
Enforcing Azure AD Password Protection
When testing of the password policy with pilot users is complete, proceed and switch the Mode from Audit to Enforced:
—————————————————————————————————————————-
Other notable items
It is important to note that you should leverage your on-premise password policies to enforce a minimum password length as Azure defaults to 8 characters. I always suggest to use the Password Settings Object (PSO) instead of the Default Domain Policy GPO because of the added flexibility and there have been environments where modifying the Default Domain Policy GPO did not enforce the configured minimum password length I wanted.
As mentioned earlier, there is a 16 character limit for banned passwords:
The following Azure AD Password Protection object will be created in the Configuration container after a successful deployment of Azure AD Password Protection:
