Password Hygiene for Active Directory

One policy.
Every path.
No exceptions.

A user changing their password through MyPass SSPR, a Windows login screen, a remote session, or an admin reset — all should be held to the same standard. MyPass Password Hygiene enforces a consistent, intelligent policy at the AD kernel level across every path. Weak, compromised, and policy-violating passwords blocked everywhere. Instantly. Without GPO changes.

<15 min
Typical deployment time on all domain controllers
100%
Password paths covered — change, reset, self-service, admin
Zero
GPO changes required — supplements existing policy
Group-level
Targeting — different policies per AD group

The Gap in Native AD Policy

Complexity rules don't equal strong passwords

"Password123!" meets most AD complexity requirements. It has uppercase, lowercase, a number, and a symbol. It also appears in every major breach database and will be tried in the first 30 seconds of any credential stuffing attack.

Native AD policy cannot check against breach lists, block keyboard patterns, enforce custom organisational rules, or apply different requirements to different groups. MyPass Password Hygiene adds all of that — at the kernel level — without replacing what you already have.

  • Breach list detection — Block passwords from known compromised credential databases. All checks run locally — passwords never leave the DC.
  • Custom dictionary blocking — Company name, product names, brand terms, location names, role titles. Your organisation, your list.
  • Keyboard pattern rejection — qwerty, 12345, asdfgh, and all variations including common leet substitutions like P@ssw0rd.
  • Account and full name checks — Built-in rules block passwords that contain or closely resemble the user's own username or display name.
  • Supplements existing GPO — Operates alongside your existing AD Group Policy. No conflict, no replacement, no GPO changes needed.
  • Windows Server 2008 R2 through 2025 — Full version coverage, 32 and 64-bit. Silent install MSI for mass DC rollout.
Password policy enforcement
New password attempt
Password123
Found in breach database
Contains username pattern
DecisionREJECTED

Consistent Enforcement

The policy applies no matter how the password changes

Installed at the Windows LSA layer on every domain controller, Password Hygiene intercepts every password event — regardless of where it came from. There is no back door through an admin reset or a remote session.

Self-Service Reset
User resets via MyPass SSPR portal or mobile app
Filter applied
Windows Login Screen
Ctrl+Alt+Del password change on workstation or RDP session
Filter applied
Admin / Helpdesk Reset
IT admin or helpdesk agent resets via AD Users & Computers or ITSM
Filter applied
Remote / VPN Session
Password change from off-network device via VPN or remote desktop
Filter applied
Every path hits the same filter. One policy. No exceptions.

Group-Level Targeting

Different groups. Different requirements.

Not every user needs the same password policy. Finance requires stricter controls than general staff. IT admins managing privileged accounts need higher standards than a reception desk login. Password Hygiene rules are scoped to AD group membership — assign different policies per department, role, or risk level.

General Staff
Standard Policy
  • Minimum 10 characters
  • Block known breach list passwords
  • Block username and full name in password
  • Block common keyboard patterns
  • Block company name and brand terms
Finance / HR / Legal
Enhanced Policy
  • Minimum 14 characters
  • Extended breach database check
  • Block username, full name, department name
  • Block all keyboard patterns and leet substitutions
  • Require character class variance (upper, lower, digit, symbol)
  • Block common words from custom organisational dictionary
IT Admins / Privileged Accounts
High-Security Policy
  • Minimum 16 characters
  • Full breach list + extended compromised hash check
  • Block all pattern, dictionary, and name-based passwords
  • Entropy-based strength scoring — meets threshold or rejected
  • Separate rule set for admin accounts vs standard accounts
  • Logged to Windows Event Log with elevated severity
How it works: Each rule in the XML configuration carries a groupnamepattern attribute targeting a specific AD group, and a groupnamepatternmatch flag to either include or exclude that group. Rules can overlap, stack, and conflict-resolve — giving you unlimited policy combinations without multiple filter installations.

Rule Engine

Flexible. Regex-powered. XML-configured.

Rules are defined in an XML configuration file on the domain controller. No service restart required for rule updates. Supports ECMAScript regex for custom pattern matching.

Built-in Checks
Smart Identity Checks
Pre-built keyword checks that understand the user context — not just raw string matching. Applied without needing custom regex.
AccountNameCheck FullNameCheck CharacterVarianceCheck
Pattern Matching
Regex Rule Enforcement
Full ECMAScript regex engine for custom patterns. Enforce or deny specific patterns, sequences, or structures. Optional case-insensitive matching.
ignorecasing match: yes/no accountnamepattern
Scope Control
Group & Operation Targeting
Each rule is scoped to a specific AD group and a specific operation type. Include or exclude groups. Apply different rules to password changes vs password resets.
groupnamepattern PasswordChange PasswordReset
Audit & Logging
Windows Event Log Integration
All filter events written to Windows Server Event Log. Configurable log levels from verbose (all events) to errors-only. Supports SIEM integration via Windows event forwarding.
Level 0: Verbose Level 2: Errors (default) Level 3: Warnings+Errors

Deployment

Under 15 minutes. Silent install supported.

Password Hygiene installs as a Windows Password Filter DLL, integrated at the Windows LSA layer. Must be installed on all domain controllers. GUI and silent MSI install modes available — suitable for mass DC rollout via software deployment tools.

  • GUI install — MSI installer with InstallShield wizard. Typical deployment under 15 minutes per DC.
  • Silent install — MSI with /s /v"/qn" flags. Deploy via SCCM, Intune, or any software push tool.
  • One reboot required — LSA integration requires a single DC reboot after install to activate the filter.
  • Normal & Silent Mode — Silent Mode logs rejections without blocking users — useful for policy testing before enforcement.
  • Supported: Windows Server 2008 R2 – 2025 — 32 and 64-bit where applicable.
Full Deployment Guide ↗
Filter configuration
Breach list check
Dictionary word block
Username pattern block
Min entropy score72 bits

FAQ

Common questions

No. Password Hygiene supplements your existing Group Policy settings — it does not replace or conflict with them. Both are enforced. A password must satisfy AD Group Policy AND the Password Hygiene filter rules to be accepted. Your existing GPO configuration stays exactly as it is.
Yes. The filter intercepts both PasswordChange (user-initiated) and PasswordReset (admin-initiated) operations. You can configure rules to apply to both, either, or different rule sets per operation type — so you can enforce stricter rules on self-service changes while giving IT admins a different policy for emergency resets if required.
No. All evaluation happens locally on the domain controller. Breach databases are stored as local hash lists — no API call, no external transmission. Passwords never leave your environment. Hash lists are updated on a configured schedule via a secure update mechanism that downloads hashes, not the credentials themselves.
Yes. Silent Mode runs the filter and logs all rejections to the Windows Event Log without actually blocking the password change. This lets you validate your rule configuration against real user behaviour in production before enabling enforcement. Recommended for all new policy deployments.
Default behaviour is fail-open — if the filter is unavailable, password changes fall back to standard AD policy evaluation so users are not impacted. Fail-closed mode is available as a configurable option for high-security environments where no password change is preferable to an unfiltered one.
Each rule in the XML configuration file carries a groupnamepattern attribute (a regex matching the target AD group name) and a groupnamepatternmatch flag (True to include, False to exclude that group). Rules without a group attribute apply globally. Multiple group-scoped rules can coexist — so Finance, IT Admins, and General Staff can each have their own policy layers running simultaneously on the same DC installation.

One policy. Every path. No exceptions.

Stop weak and compromised passwords — from every direction. Book a demo or read the deployment guide to see how quickly Password Hygiene can be in place across your domain controllers.