Azure AD password protection

Ganesh Chauhan, Technical Support Specialist, Microsoft Azure

Azure AD Password Protection detects and blocks known weak passwords and variants, as well as additional weak terms unique to your organization. Azure AD Password Protection on-premises deployment uses the same global and custom banned password lists that are stored in Azure AD, and performs the same checks for on-premises password changes as Azure AD does for cloud-based changes. These checks are performed against on-premises Active Directory Domain Services (AD DS) domain controllers during password changes and password reset events.

Users frequently create passwords that include common local terms such as a school, sports team, or famous person. These passwords are easy to guess and vulnerable to dictionary-based attacks. Azure Active Directory (Azure AD) Password Protection offers a global and custom-banned password list to help you enforce strong passwords in your organization. A password change request fails if it matches one of the banned passwords.

Design fundamentals

Ø Domain controllers (DCs) are never required to communicate with the internet directly.

Ø On DCs, no new network ports are created.

Ø No changes to the AD DS schema are required. The existing AD DS container and service connection point schema objects are used by the software.

Ø Any AD DS domain or forest functional level that is supported can be used.

Ø Accounts are not created or required in the AD DS domains that the software protects.

Ø User clear-text passwords never leave the domain controller, not even during password validation operations.

Ø The software is not reliant on any other Azure AD features. Azure AD password hash sync (PHS), for example, is unrelated to or required for Azure AD Password Protection.

Ø Although incremental deployment is possible, the password policy is only enforced where the Domain Controller Agent (DC Agent) is installed.

Diagram of the architecture

Before deploying Azure AD Password Protection in an on-premises AD DS environment, it’s critical to understand the underlying design and function concepts. The diagram below depicts how the components of Azure AD Password Protection interact:

· The Azure AD Password Protection Proxy service is available on any domain-joined machine in the current AD DS forest. The service’s primary function is to forward password policy download requests from DCs to Azure AD and then return the responses from Azure AD to the DC.

· The password filter DLL of the DC Agent receives user password-validation requests from the operating system. The filter routes them to the DC Agent service, which is running locally on the DC.

· Azure AD Password Protection’s DC Agent service receives password-validation requests from the DC Agent’s password filter DLL. The DC Agent service processes them using the current (locally available) password policy and returns a pass or fail result.

Azure Active Directory Password Protection Works

Each Azure AD Password Protection Proxy service instance advertises itself to the forest’s DCs by creating an Active Directory serviceConnectionPoint object.

Each DC Agent service for Azure AD Password Protection creates an Active Directory serviceConnectionPoint object. This object is mostly used for reporting and diagnostics.

The DC Agent service is in charge of requesting a new password policy from Azure AD. The first step is to search the forest for proxy serviceConnectionPoint objects to find an Azure AD Password Protection Proxy service.

When an available proxy service is discovered, the DC Agent sends a password policy download request to the proxy service. The proxy service then sends the request to Azure AD and returns the response to the DC Agent service.

When the DC Agent service receives a new password policy from Azure AD, it stores it in a dedicated folder at the root of its domain sysvol folder share. The DC Agent service also monitors this folder in case newer policies replicate in from other DC Agent services in the domain.

At service startup, the DC Agent service always requests a new policy. After starting the DC Agent service, it checks the age of the current locally available policy on an hourly basis. If the policy is more than one hour old, the DC Agent, as previously described, requests a new policy from Azure AD via the proxy service. If the current policy is less than one hour old, the DC Agent will continue to use it.

When a DC receives a password change event, it uses the cached policy to determine whether the new password is accepted or rejected.

Professional Labs is the premier cloud managed service provider in Saudi Arabia. Contact us for more information
Contact Us | Professional labs (