I travel a lot in Italy, and many times I see multiple customers that are asking for the same requests. One request is the possibility to block some specific passwords in Active Directory. Unfortunately too many users have BAD habits and use the company name in the password field for example. In those cases, the Security team wants to block some easy and well known passwords.
In Active Directory you can Enable some GPO that can help you to implement strong password, like:
- Minimum Password Length
- Minimum Password Age
- Maximum password Age
- Password must meet complexity requirements
- Enforce Password History
However, with a minimum password length of 8 chars and these GPOs, we unfortunately can't avoid the use of some well known Passwords like:
"P@$$w0rd" or "Pippo01!"
Azure AD Password Protection is finally what we need to enhance the password policies in your organization. With this feature, you can use the same checks for passwords in AzureAD on your on-premises Active Directory implementation. You can enforce both the Microsoft Global Banned Passwords and Custom banned-passwords list stored in Azure AD tenant.
What are the Design Principles?
Azure AD Password Protection is based on multiple design principles available here, but I would like to emphasize some of the most important ones:
- Your DCs never talk directly with Azure.
(you need to install the Azure AD Password Protection Proxy Service) - Your DCs will be never be exposed on the internet.
- There are no ports listening on the Domain Controllers for the Azure AD Password Protection DC Agent.
- All the services of the Azure AD Password Protection (Proxy Service and DC Agent) do not require any specific user to work, they use the LOCAL SYSTEM account, but you will need a Global Admin of your tenant and a Domain Admins to register the Proxy Services and the Forest, but only one time.
- Do not require any schema update or specific DFL/FFL.
- The deployment of this solution supports the incremental deployments.
How does it work?
- A user requests a password change to a Domain Controller.
- The DC Agent Password Filter dll, receive from the OS, the password validation requests, and forward them to the Azure AD Password Protection DC Agent, installed on the DC. This Agent then validate if the password is compliance with the locally stored Azure password policy.
- The Agent on the DC every 1h locate via the SCP (Service Connection Point) in the forest the Azure AD Password Protection Proxy Service to download a fresh copy of the Azure password policy.
- The Agent on the DC receives the new version of the Azure password policy from the proxy service and stores it in the Sysvol enabling this new policy to be replicated to all other DCs in the same domain.
The Azure Password policies are stored in Sysvol as shown here:
It is not necessary that all the DCs are able to comunicate with the Azure AD Password Protection Proxy Server, if you have a very complex Active Directory environments, you can configure a minimum of one DC per domain to be able to connect to the AAD Password Protection Proxy Servers, and the other DCs will take the new policy from the Sysvol replication. However, on these DCs you will see some warning of this type:
Log Name: Microsoft-AzureADPasswordProtection-DCAgent/Admin
Source: Microsoft-AzureADPasswordProtection-DCAgent
Date: 15/05/2019 23:37:39
Event ID: 30018
Task Category: None
Level: Warning
Keywords:
User: SYSTEM
Computer: ITDC01.IT.CONTOSO.COM
Description:
One or more Azure AD Password Protection Proxy servers were found in the forest but this machine was unable to establish network connectivity to any of them.
This operation will be run periodically and may succeed in future attempts
This may be an expected and benign condition depending on how the network environment is configured.
This domain controller may be able to obtain updated password policies via sysvol replication if other domain controllers do have proxy connectivity.
How can I deploy the Azure AD Password Protection?
The following is a an example of a simple scenario to understand how-to deploy this feature:
- Since your DCs never talk directly with Azure you need at least 2 Azure AD Password Protection Proxy Server per Forest for high availability and should be placed in the Root Domain. The Azure AD Password Protection Proxy Servers must be Windows Server 2012R2 or above.
-
Download the Azure AD Password Protection software (Proxy and DC Agent):
- Be sure to have installed .NET Framework 4.7 at minimum on these Proxy Servers.
- All the server DCs and Proxy Services require the Universal C runtime for Windows.
- Install the Proxy Service (AzureADPasswordProtectionProxySetup.exe) on the two Servers, joined to the root domain:
You can also complete this via Silent installation from the command line
With the installation of the Proxy Service completed, you can open PowerShell and can see a new module, AzureADPasswordProtection, installed.
PS C:\> Get-Command -Module AzureADPasswordProtection CommandType Name ModuleName ----------- ---- ---------- Function Get-AzureADPasswordProtectionSummaryReport AzureADPasswordProtection Cmdlet Get-AzureADPasswordProtectionDCAgent AzureADPasswordProtection Cmdlet Get-AzureADPasswordProtectionProxy AzureADPasswordProtection Cmdlet Get-AzureADPasswordProtectionProxyConfiguration AzureADPasswordProtection Cmdlet Register-AzureADPasswordProtectionForest AzureADPasswordProtection Cmdlet Register-AzureADPasswordProtectionProxy AzureADPasswordProtection Cmdlet Set-AzureADPasswordProtectionProxyConfiguration AzureADPasswordProtection
You can also open the event log and can see new Event logs for the installed Service:
- All the DCs must be at least Windows Server 2012 or above. You now need to install the package "AzureADPasswordProtectionDCAgentSetup.msi":
As you can see the DC Agents installation require the reboot of the DC and also in this case if you want you can use the Silent installation with the command line. But please remember to put the /norestart parameter to avoid the immediate restart of the DC.
After the installation, on the DC you will see a new Eventlog for the agent: - By default the Azure AD Password Protection DC Agent use the TCP port 135 and the dynamic ports range to connect to the Azure AD Password Protection Proxy Servers, so this ports must be open at the network level, but if you prefer, you can configure the proxy Service to Listen on a specific ports.
Set-AzureADPasswordProtectionProxyConfiguration –StaticPort <portnumber>
This command must be executed on each proxy Server, and require the restart of the Proxy Service. - You need to register on your Azure AD Tenant the two Proxy Server with a simple PowerShell cmdlet on each proxy:
Register-AzureADPasswordProtectionProxy -AccountUpn 'admin@<yourtenant>.onmicrosoft.com'
This registration of the Proxy Service is necessary only one time, for the first authentication on the tenant. - You need to register the Forest on Azure AD so this command must be lunched from only one of the Proxy Servers:
# IF YOU ARE CONNECTED TO THE PROXY SERVER WITH ADMIN CREDENTIAL # OF THE ROOT DOMAIN, THEN YOU CAN USE THIS COMMAND: Register-AzureADPasswordProtectionForest -AccountUpn 'admin@<yourtenant>.onmicrosoft.com' # OTHERWISE YOU CAN SPECIFY THE ROOT DOMAIN CREDENTIALS: Register-AzureADPasswordProtectionForest -AccountUpn 'admin@<yourtenant>.onmicrosoft.com' -ForestCredential $(Get-Credential)
This command require the a Global Admin of the tenant and a Domain Admins of the Root Domain. - You can now connect to the https://portal.azure.com and configure the Azure AD Password Protection:
NOTE: keep in mind that when you write in the custom banned password the word "fabrikam", you are adding more than that, also the "f@br1k@m" is banned! So we made also common char substitution. The Custom password field, can contain up to 1000 words case-insensitive.
Nice to Know
- The Proxy Service of Azure AD Password Protection can work with HTTPS proxy servers in your environment, but actually the Azure AD Password Protection proxy service doesn't support the use of specific credentials for connecting to an HTTPS proxy.
- By default the Azure AD Password Protection is set to "Audit Mode" on the Tenant so, if you deploy a proxy service and install one agent on a DC (only for testing purpose), if the password match the Microsoft Global Banned Password list, the DC Agent will generate only events like this one:
Log Name: Microsoft-AzureADPasswordProtection-DCAgent/Admin
Source: Microsoft-AzureADPasswordProtection-DCAgent
Event ID: 30009
Task Category: None
Level: Information
Keywords:
User: SYSTEM
Computer: ITDC01.IT.CONTOSO.COM
Description:
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.
UserName: ITOPSTALK
FullName: ITOPSTALKOr like this, if the password match your custom password lists on the tenant:Log Name: Microsoft-AzureADPasswordProtection-DCAgent/Admin
No Password will be blocked until you will change the configuration on the Tenant from "Audit Mode" to "Enforce".
Source: Microsoft-AzureADPasswordProtection-DCAgent
Event ID: 30007
Task Category: None
Level: Information
Keywords:
User: SYSTEM
Computer: ITDC01.IT.CONTOSO.COM
Description:
The reset password for the specified user would normally have been rejected because it matches at least one of the tokens present in the 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: ITOPSTALK
FullName: ITOPSTALK - If your DCs are all 2012 or above but you are using FRS for replicating the SYSVOL, upgrade first to DFSR to use Azure AD Password Protection, because FRS is deprecated.
- Have you already two AD connect servers in your Environment? Yes? So you can install the proxy Service on this 2 Servers if you want, but start always from the one in staging mode ;).
- Azure AD Password Protection for Active Directory require the Azure AD Premium licences P1 or P2.
- Azure AD Password Protection is not a real-time policy application engine, you can have a delay in the application of the new Azure Password Policy in your on-premises AD environment.
- If you want to force a DC to download a fresh copy of the Azure Password Policy from the Proxy Service, you can restart the DC Agent.
Scenarios
Some Customers think that because Azure AD Password protection On-Premises, work with DC Agents they can deploy Agents only on a single AD Site to protect for example a Branch Office, but this is a partial deployment and it is not recommended. In this scenario a customer want to deploy DC Agents only on the NY-SITE, graphics always help to understand better:
As you can see one DC in the IT.CONTOSO.DOMAIN don't have the DC Agent, because the change password can happens on any DC, this configuration is not secure and not recommended.
If you want to implement a more secure scenario, you need to install the DC Agent on each DCs of the forest, like in this example:
As you can see here, we have secured all the entire forest by installing the DC agent on each DC in every domains.
If you want to apply the Azure AD Password Protection only to one domain in your forest, you need in any case to deploy the Proxy Services for the Forest and then deploy the DC Agent only on all the DCs in that domain to secure it, in this example HR.CONTOSO.COM. (You should not think to deploy the DC agent only on the PDC, for example):
Last but not least, remember to alert your users about the Policy password change before switch the configuration in the Tenant from "Audit mode" to "Enforce".
I hope that all this info, will help you to deploy this great feature in your Environments.
Reference
The official reference:
Enforce Azure AD password protection for Windows Server Active Directory
Azure AD Password Protection troubleshooting
Azure AD Password Protection monitoring and logging