# Entra ID and on-premises AD password defense

This is a separate password-policy workflow, not an IP enforcement action.
Download GET /api/v1/credentials/blocklist?format=entra&confidence=high using an approved Professional or Enterprise key from a trusted admin workstation. Keep the bearer key in your secret manager and the downloaded file private; never paste keys or passwords into tickets or SIEM logs. Use confidence=broad only after reviewing the wider policy impact. High requires 20 distinct source networks; broad requires 5. Neither feed proves every entry is breached.

1. Review the returned newline-separated terms. The feed selects Entra-eligible 4–16 character values and caps output at 1,000 terms. Empty output is not an instruction to erase your existing policy.
2. Back up your existing custom terms privately. Merge with organization-specific terms, deduplicate case-insensitively, review the 1,000-term limit and obtain your identity policy owner's approval. Do not overwrite unrelated terms or silently truncate them.
3. In the Microsoft Entra admin center, open Entra ID > Authentication methods > Password protection, enable the custom banned password list, paste the reviewed terms one per line and save. Verify current licensing and admin role requirements with Microsoft. This is a manual reviewed update, not a feed URL or direct import API.
4. Test password changes with dedicated test accounts. Microsoft's normalization and scoring can reject variants; list membership is not an exact-string-only test. Changes apply on password set/change, not retroactively to all existing passwords. Review weekly; do not automatically remove organization terms when feed entries retire.
5. For on-premises AD DS, deploy and register Microsoft's Entra Password Protection proxy service and DC agents following the official deployment guide. Start the on-premises policy in Audit mode, verify policy download and event logs on every writable DC, then pilot Enforced mode with identity-owner approval. Audit mode is an on-premises setting, not a cloud-only custom-list dry run. Plan proxy redundancy, domain controller rollout/restarts, monitoring and rollback using Microsoft's supported procedure.

Record review date, feed generation time (obtain from format=json if needed), term count and policy version without recording plaintext terms in ordinary logs. Roll back using the private previous policy if the pilot causes unexpected impact. No feed or SIEM match alone should disable an account.

Sources: [Microsoft custom list configuration](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-configure-custom-password-protection), [on-premises deployment](https://learn.microsoft.com/en-us/entra/identity/authentication/howto-password-ban-bad-on-premises-deploy).