Unit 6: Deploy and Manage Password Protection

Why Password Protection

Users often choose weak passwords based on:

• Common local words (school, team, celebrity).
• Simple patterns.

Microsoft Entra Password Protection enforces stronger passwords by using:

• A global banned password list (Microsoft-maintained).
• A custom banned password list (organization-defined).

If a requested password matches banned patterns, the change request fails.

Design Principles

Microsoft Entra Password Protection is designed so that:

• Domain controllers never need to talk directly to the internet.
• No new network ports are opened on DCs.
• No AD DS schema changes are required.
• No minimum forest or domain functional levels are required.
• No extra accounts are created in AD DS for protection.
• Clear-text passwords never leave the DC.
• It is independent from other Entra features (for example, PHS is not required).
• It supports incremental deployment and enforces policy only on DCs with the DC Agent installed.

🔄 Policy Retrieval and Enforcement Flow

• Microsoft Entra Password Protection uses a proxy-based architecture to enforce cloud-managed password policies in on-premises Active Directory.
• A member server (not a domain controller) is configured with the Password Protection Proxy Service.
• This proxy authenticates to Microsoft Entra ID and downloads the banned password policy (including both global and custom banned password lists).
• The policy is cached locally on the proxy server.
• Domain controllers (DCs) with the Password Protection DC Agent installed:
• Pull the policy from the proxy server, not from the internet.
• Enforce the policy locally during password change or reset operations.
• This architecture ensures that DCs remain isolated from direct internet access, while still benefiting from cloud-based password intelligence.

✅ This design enables secure, incremental deployment of password protection in hybrid or on-prem AD environments, without requiring PHS, PTA, or schema changes.

How On-Premises Password Protection Works

Components:

• Password Protection Proxy service.
• Password Protection DC agent.

🔄 Flow Explained Step-by-Step

• Each proxy service instance publishes a serviceConnectionPoint (SCP) in AD so DCs can discover it.
• The Password Protection Proxy Service registers itself in Active Directory by creating an SCP object.
• This SCP acts like a directory listing, allowing DCs to find the proxy without hardcoded addresses.
• Each DC agent also creates an SCP for reporting and diagnostics.
• Every DC Agent also publishes its own SCP.
• This helps with monitoring, diagnostics, and confirming which DCs are enforcing password protection.
• DC agent locates a proxy service by querying proxy SCPs.
• When a DC Agent starts up, it queries AD to find available proxy SCPs.
• This is how it knows where to request policy updates—no manual configuration needed.
• DC agent requests the latest password policy from the proxy.
• The DC Agent sends a request to the proxy asking for the current banned password policy.
• This includes both Microsoft’s global list and your custom banned terms.
• Proxy requests the policy from Microsoft Entra and returns it to the DC agent.
• If the proxy doesn’t have the latest policy cached, it fetches it from Entra ID.
• Then it returns the policy to the requesting DC Agent.
• DC agent stores the policy in a dedicated folder in SYSVOL.
• The policy is saved in SYSVOL, the shared folder used for AD replication.
• This allows other DCs to replicate the policy automatically.
• DC agent monitors SYSVOL for newer policies replicated from other DCs.
• Even if a DC didn’t request the policy directly, it can pick up updates from SYSVOL.
• This ensures consistency across all DCs with the agent installed.
• At startup, DC agent always requests a new policy.
• When the DC boots up, the agent actively requests the latest policy from the proxy.
• This ensures it starts with a fresh and valid policy.
• After startup, DC agent checks policy age hourly.
• The agent runs a scheduled check every hour to see if the policy is stale.
• If older than one hour, it requests a new policy via proxy.
• If the cached policy is older than 1 hour, the agent requests a fresh copy from the proxy.
• Otherwise, it continues to use the cached policy.
• If the policy is still fresh, the agent uses the local copy—no need to re-fetch.
• When a password is set or changed on a DC, the DC agent uses the cached policy to accept or reject the password.
• During a password change or reset, the agent:
• Intercepts the plaintext password (locally, in memory).
• Evaluates it against the banned password policy.
• Accepts or rejects the password based on policy compliance.

🔍 What Is an SCP (Service Connection Point)?

An SCP (Service Connection Point) is a special object in Active Directory that acts like a directory listing or signpost.

• It tells clients (like domain controllers or apps) where to find a service.
• It’s stored in the Configuration partition of AD.
• It contains metadata like:
• Service name
• Server address
• Port
• Keywords for filtering

✅ Think of it like a DNS record inside AD—it helps clients discover services without hardcoding IPs or hostnames.

🔄 What Is the “Proxy” in Entra Password Protection?

The Password Protection Proxy Service is a middleware component you install on a member server (not a domain controller). Its job is to act as a secure bridge between:

• Microsoft Entra ID (cloud) — where the banned password policy is defined
• Your on-prem Active Directory domain controllers — where password changes happen

🧠 Why Is It Called a “Proxy”?

Because it proxies (relays) communication between the cloud and your DCs:

Summary: Think of it as a secure translator and gatekeeper: it speaks cloud on one side and AD on the other, but keeps them decoupled.

Let’s say you install the Password Protection Proxy Service on a server called proxy01.prudentcloud.us. It creates an SCP. Now inside that SCP you see:

• serviceBindingInformation = proxy01.prudentcloud.us:443
• keywords = AzureADPasswordProtectionProxy

Now, when a DC Agent starts up, it queries AD for SCPs with that keyword and finds the proxy—no manual config needed

Deployment Strategy

Recommended approach:

• Start in Audit mode.
• Weak passwords are logged but not blocked.
• Allows you to understand impact and improve processes.

During audit mode, organizations often find that:

• Operational processes need better security for passwords.
• Users frequently use weak passwords.
• Communication and training are needed before enforcing strong rules.

You should:

• Test at least one DC promotion and demotion to ensure stronger password validation does not break automation.

After a suitable audit period:

• Switch from Audit to Enforce.
• Continue monitoring.

Important. Password Protection only validates passwords during change or set operations. Existing passwords set before deployment are not revalidated and continue working until changed or expired. Accounts with password never expires are not forced to comply.

Multiple Forests

• Each forest is configured independently.
• Each proxy only supports DCs in its own forest.
• Password protection components in one forest are unaware of those in another, even with trusts.

Read-Only Domain Controllers (RODCs)

• Password change/set events are not stored on RODCs.
• Events are forwarded to writable DCs.
• You do not need to install the DC agent on RODCs.
• You cannot run the proxy service on an RODC.

High Availability

• Main HA concern is availability of proxy servers when DCs need policy updates.
• DC agents use a round-robin algorithm to choose proxies and skip unresponsive ones.
• Typically, two proxy servers are enough in well-connected environments.
• DC agents cache the latest policy locally.
• If all proxies are down, they still enforce the cached policy.

Policy update frequency is usually days, not hours. Short outages of proxies are not critical.

Licensing Requirements

For password protection:

• Cloud-only users.
• Global banned password list: Microsoft Entra Free.
• Custom banned password list: Microsoft Entra Premium P1 or P2.
• Users synchronized from on-premises AD DS.
• Global banned password list: Microsoft Entra Premium P1 or P2.
• Custom banned password list: Microsoft Entra Premium P1 or P2.

Core Requirements (On-Prem Password Protection)

General:

• You need AD Domain Admin privileges in the forest root domain to register the forest with Entra.
• Key Distribution Service must be enabled on all DCs running Windows Server 2012.
• Network connectivity from at least one DC in each domain to at least one proxy server.
• Access to RPC endpoint mapper port 135 and the dynamic or static RPC port used by the proxy.

External endpoints (for proxy servers):

• https://login.microsoftonline.com – Authentication.
• https://enterpriseregistration.windows.net – Password Protection functionality.

DC Agent requirements:

• Windows Server 2012 or later.
• No minimum forest or domain functional level.
• .NET 4.5 installed.
• Domain must use DFSR for SYSVOL replication.

Proxy service requirements:

• Windows Server 2012 R2 or later.
• Proxy is mandatory, even if DCs have direct internet access.
• .NET 4.7 installed.
• Must allow DCs to access the proxy via “Access this computer from the network” privilege.
• Must allow outbound TLS 1.2 HTTP traffic.
• To register your on-prem Active Directory forest with Microsoft Entra for Password Protection, you must use an account that has the Security Administrator role in Entra ID.
• This account is used during the initial registration process when running on the member proxy server:

Register-AzureADPasswordProtectionProxy

Register-AzureADPasswordProtectionForest

These are PowerShell commands executed locally on the proxy server, but they authenticate to Entra ID using a Security Administrator account.

Why it's required:

• These commands create service principals and SCPs, and authorize the proxy to fetch password policies.
• Only a Security Administrator (or Global Administrator) has the necessary permissions to:
• Register the forest
• Approve the proxy
• Write configuration metadata to Entra ID
• ✅ This ensures that only authorized personnel can bridge on-prem AD with cloud policy enforcement.
• Network access to ports and URLs used by Application Proxy environment setup.

Warning for the exam. You must not install Password Protection Proxy and Application Proxy on the same machine because they install incompatible versions of the Entra Connect Agent Updater. This breaks automatic updates.

Required Software

Two installers:

• DC agent: AzureADPasswordProtectionDCAgentSetup.msi.
• Proxy: AzureADPasswordProtectionProxySetup.exe.

Install and Configure Proxy Service

• Install the proxy service on a member server in your on-prem AD DS environment.
• Proxy downloads global and custom banned password lists from Entra for your tenant.

Install the DC Agent

Example MSI command:

msiexec.exe /i AzureADPasswordProtectionDCAgentSetup.msi /quiet /qn /norestart

• A restart is required for install or uninstall because password filter DLLs are only loaded/unloaded at reboot.
• DC agent can be installed before promotion; it remains inactive until the machine becomes a DC.

Upgrading Proxy and DC Agent

Proxy service:

• Supports automatic upgrade via the Entra Connect Agent Updater.
• Controlled using Set-AzureADPasswordProtectionProxyConfiguration.
• Status queried via Get-AzureADPasswordProtectionProxyConfiguration.
• Proxy versions can be listed with Get-AzureADPasswordProtectionProxy.
• Manual upgrade: run latest AzureADPasswordProtectionProxySetup.exe.
• In-place upgrade.
• No reboot required.

DC agent:

• Upgrade by running the latest AzureADPasswordProtectionDCAgentSetup.msi.
• In-place upgrade, but reboot is always required.
• Example:

msiexec.exe /i AzureADPasswordProtectionDCAgentSetup.msi /quiet /qn /norestart

• Can omit /norestart to let installer reboot automatically.
• DC agent versions can be listed with Get-AzureADPasswordProtectionDCAgent.