How to set up password policies in Azure AD Password Protection

If you are like most IT administrators, you have long had a mandate to change passwords on a regular basis. You’ve mandated a minimum length of passwords. Yet your users still select guessable passwords. As noted in the Windows 10 1903 security baseline policies, password policies that mandate frequent password changes actually encourages poor password selection.

Your policies should encourage good passwords and block bad ones. One way you can implement this is with Azure AD Password Protection. You’ll need, of course, Azure Active Directory synchronized with your existing AD infrastructure.

First, sign into the Microsoft Azure portal with a global administrator account. Next browse to Azure Active Directory and then to the Authentication methods blade, where you’ll see Password protection, as shown:

Susan Bradley

You may want to enable a custom banned password list that includes the listing of known commonly used passwords to ensure that they are not used in your network.

To integrate the Azure password protection into your on-premises network, set up the infrastructure on your existing domain. These are the requirements you need to meet:

• All domain controllers that get the Domain Controller (DC) Agent service for Azure AD password protection installed must run Windows Server 2012 or later. You don’t need 2012 as the AD domain or forest level is at a 2012 level. No minimum domain functional level or forest functional level is required.
• All machines that get the DC agent service installed must have .NET 4.5 (or higher) installed.
• All machines that get the proxy service for Azure AD password protection installed must run Windows Server 2012 R2 or later. You must have the proxy service installed even if the server has direct access to the internet.
• All machines where the Azure AD Password Protection Proxy service will be installed must have .NET 4.7 installed. If .NET 4.7 isn’t installed, download and run the installer.
• All machines, including domain controllers, that get Azure AD password protection components installed must have the Universal C Runtime installed. You can download the runtime from the Update for Universal C Runtime in Windows website.
• Network connectivity must exist between at least one domain controller in each domain and at least one server that hosts the proxy service for password protection. This connectivity must allow the domain controller to access RPC endpoint mapper port 135 and the RPC server port on the proxy service. By default, the RPC server port is a dynamic RPC port, but it can be configured to use a static port.
• All machines that host the proxy service must have network access to the following URLs:
• https://login.microsoftonline.com (authentication requests)
• https://enterpriseregistration.windows.net (Azure AD password          protection functionality)
• All machines that host the proxy service for password protection must be configured to allow outbound TLS 1.2 HTTP traffic.
• A global administrator account is mandated to register the proxy service for password protection and forest with Azure AD.
• You must have an account that has Active Directory domain administrator privileges in the forest root domain to register the Windows Server Active Directory forest with Azure AD.
• Any Active Directory domain that runs the DC Agent service software must use Distributed File System Replication (DFSR) for System Volume (SYSVOL) replication.
• 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.

When you set up Azure AD password policies, keep in mind the following design foundations:

• It is not intended that domain controllers never have to communicate directly with the internet, thus the mandate for the use of the proxy service.
• No new network ports are opened on domain controllers.
• No AD schema changes are required. The software uses the existing AD container and serviceConnectionPoint schema objects.
• No minimum AD domain or forest functional level (DFL/FFL) is required.
• The software doesn’t create or require accounts in the AD domains that it protects.
• User clear-text passwords never leave the DC, either during password validation operations or at any other time.
• The software is not dependent on other Azure AD features. For example, Azure AD password hash sync is not related and is not required for Azure AD password protection to function.
• Incremental deployment is supported. However, the password policy is only enforced where the DC Agent is installed.

You may consider adding the ability to check your AD passwords against a database of known password breaches and hash values to ensure that password reuse doesn’t make your network more insecure. You can even set up the ability to check for breached passwords on your existing domain. You will need to hook into the “HaveIbeenpwned” external database of hacked passwords to test your users’ passwords. While this introduces some risk, the benefit of ensuring that end users don’t reuse passwords or use easily guessable passwords is immense.

Take the time to review your password strategy. Add external databases that ensures that end users don’t reuse passwords. All this will ensure that you won’t suffer an attack where the attacker just “guessed” their way into your network.