This post shows how to configure Active Directory password and account policies so your environment aligns with the intent of NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 control IA.L2-3.5.7, giving step‑by‑step implementation advice, practical PowerShell and GPO actions, and small-business scenarios you can implement quickly.
\n\nIA.L2-3.5.7 addresses identification and authentication protections for Controlled Unclassified Information (CUI) — in practice this means enforcing password controls, preventing reuse, and ensuring password-based authentication provides sufficient protection until stronger mechanisms (like MFA) are applied. In an Active Directory (AD) environment the primary controls are: the domain password policy (Default Domain Policy or domain default password policy), Fine-Grained Password Policies (Password Settings Objects/PSOs) for high-privilege accounts, account lockout behavior, and proper management of service/local accounts.
\n\nTo meet IA.L2-3.5.7, adopt conservative, evidence-backed settings. Example recommended domain defaults for many small businesses seeking CMMC Level 2 compliance: Minimum Password Length = 12–15 characters, Enforce Password History = 24 passwords, Minimum Password Age = 1 day (to prevent immediate reuse), Maximum Password Age = 365 days (or rely on event-driven resets per modern NIST guidance — document your rationale), Password must meet complexity requirements = Enabled, Store passwords using reversible encryption = Disabled, Account lockout threshold = 5 invalid attempts, Lockout duration = 15 minutes, Reset account lockout counter after = 15 minutes. These settings strike a balance between security, usability, and assessor expectations.
\n\nSteps to configure a domain-wide policy: open Group Policy Management Console (GPMC) on a domain controller or management workstation; edit the Default Domain Policy (or create and link a new GPO at the domain root and ensure precedence) -> Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Account Policies -> Password Policy and Account Lockout Policy. Set the values above, then run a Group Policy update on a test machine (gpupdate /force) and verify with Get-ADDefaultDomainPasswordPolicy (ActiveDirectory PowerShell module) or by using net accounts on a domain member for a quick check. Always test changes first — a too-strict lockout on a live domain can disrupt users and services.
\n\nUse PSOs to apply stronger rules to privileged groups (Domain Admins, Helpdesk) without impacting all users. On a small AD domain you can create a PSO using PowerShell from an account in the Domain Admins group. Example (conceptual) command sequence: create a PSO named \"PSO-Admins\" with higher precedence and stricter settings (minimum length 15, history 24, lockout threshold 3) and apply it to the Admins group. The cmdlets are New-ADFineGrainedPasswordPolicy and Add-ADFineGrainedPasswordPolicySubject — document the PSO and its rationale so an assessor can trace policy to privileged principals. For Windows Server 2012+/AD PowerShell module usage, run: Get-Help New-ADFineGrainedPasswordPolicy for parameter details and test PSOs in a lab before production deployment.
\n\nPasswords for service and local accounts are a common audit failing point. Replace static service account passwords with group-managed service accounts (gMSA) where possible. For local administrator accounts on endpoints, implement Microsoft LAPS (Local Administrator Password Solution) so passwords are unique, rotated, and stored securely in AD — this satisfies the \"prevent reuse and maintain secure storage\" goals in IA.L2-3.5.7. For legacy service accounts that cannot be converted, store credentials in a hardened secrets manager (Azure Key Vault, HashiCorp Vault, CyberArk) and document rotation procedures. Avoid embedding credentials in scripts; use managed identities or certificates where possible.
\n\nAssessors will want proof that settings are applied and being monitored. Produce the following evidence: Group Policy Management Console reports (GPO settings), output of Get-ADDefaultDomainPasswordPolicy and Get-ADFineGrainedPasswordPolicy, screenshots of GPMC, change requests/ticket records showing approvals, and audit logs demonstrating enforcement (Windows Security logs and Directory Service changes). Enable Audit Directory Service Changes and monitor for Event IDs related to password changes and policy modifications. Example small-business scenario: a 25-user company sets domain policy to 12-character minimum, creates a PSO for its 3 IT admins with 15-character minimum and stricter lockout, deploys LAPS for 40 endpoints, converts 6 services to gMSA, and stores remaining service secrets in a SaaS vault. This configuration is simple to document and presents a clear compliance story.
\n\nFailing to implement adequate AD password protections increases the risk of credential compromise, lateral movement, privilege escalation, and data exfiltration of CUI. Attackers frequently rely on password reuse, weak passwords, and unrotated service credentials to persist. Non‑compliance also creates programmatic risk: failure during a CMMC assessment or NIST-based audit can require remediation plans, loss of contracting opportunities, or remedial actions that are more expensive than implementing controls proactively.
\n\nTo keep controls effective, document your policy decisions (including any deviation from strict password rotation in favor of event-driven changes as per NIST guidance), maintain evidence, and combine strong password policies with mandatory MFA for domain-joined remote access and sensitive roles.
\n\nSummary: implement a domain-level GPO with conservative password and lockout settings, use PSOs for privileged accounts, convert service accounts to gMSA or managed secrets, deploy LAPS for local admin passwords, enable auditing and retain evidence, and document all decisions and exceptions. These steps will give small businesses a practical, evidence-able path toward meeting the intent of IA.L2-3.5.7 under NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2.
", "plain_text": "This post shows how to configure Active Directory password and account policies so your environment aligns with the intent of NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 control IA.L2-3.5.7, giving step‑by‑step implementation advice, practical PowerShell and GPO actions, and small-business scenarios you can implement quickly.\n\nUnderstanding IA.L2-3.5.7 and how it maps to Active Directory\n\nIA.L2-3.5.7 addresses identification and authentication protections for Controlled Unclassified Information (CUI) — in practice this means enforcing password controls, preventing reuse, and ensuring password-based authentication provides sufficient protection until stronger mechanisms (like MFA) are applied. In an Active Directory (AD) environment the primary controls are: the domain password policy (Default Domain Policy or domain default password policy), Fine-Grained Password Policies (Password Settings Objects/PSOs) for high-privilege accounts, account lockout behavior, and proper management of service/local accounts.\n\nRecommended AD password and lockout settings (practical values)\n\nTo meet IA.L2-3.5.7, adopt conservative, evidence-backed settings. Example recommended domain defaults for many small businesses seeking CMMC Level 2 compliance: Minimum Password Length = 12–15 characters, Enforce Password History = 24 passwords, Minimum Password Age = 1 day (to prevent immediate reuse), Maximum Password Age = 365 days (or rely on event-driven resets per modern NIST guidance — document your rationale), Password must meet complexity requirements = Enabled, Store passwords using reversible encryption = Disabled, Account lockout threshold = 5 invalid attempts, Lockout duration = 15 minutes, Reset account lockout counter after = 15 minutes. These settings strike a balance between security, usability, and assessor expectations.\n\nConfiguring the domain-level policy via Group Policy\n\nSteps to configure a domain-wide policy: open Group Policy Management Console (GPMC) on a domain controller or management workstation; edit the Default Domain Policy (or create and link a new GPO at the domain root and ensure precedence) -> Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Account Policies -> Password Policy and Account Lockout Policy. Set the values above, then run a Group Policy update on a test machine (gpupdate /force) and verify with Get-ADDefaultDomainPasswordPolicy (ActiveDirectory PowerShell module) or by using net accounts on a domain member for a quick check. Always test changes first — a too-strict lockout on a live domain can disrupt users and services.\n\nWhen to use Fine‑Grained Password Policies (PSOs) and example PSO configuration\n\nUse PSOs to apply stronger rules to privileged groups (Domain Admins, Helpdesk) without impacting all users. On a small AD domain you can create a PSO using PowerShell from an account in the Domain Admins group. Example (conceptual) command sequence: create a PSO named \"PSO-Admins\" with higher precedence and stricter settings (minimum length 15, history 24, lockout threshold 3) and apply it to the Admins group. The cmdlets are New-ADFineGrainedPasswordPolicy and Add-ADFineGrainedPasswordPolicySubject — document the PSO and its rationale so an assessor can trace policy to privileged principals. For Windows Server 2012+/AD PowerShell module usage, run: Get-Help New-ADFineGrainedPasswordPolicy for parameter details and test PSOs in a lab before production deployment.\n\nService accounts, local admins, LAPS, and managed identities\n\nPasswords for service and local accounts are a common audit failing point. Replace static service account passwords with group-managed service accounts (gMSA) where possible. For local administrator accounts on endpoints, implement Microsoft LAPS (Local Administrator Password Solution) so passwords are unique, rotated, and stored securely in AD — this satisfies the \"prevent reuse and maintain secure storage\" goals in IA.L2-3.5.7. For legacy service accounts that cannot be converted, store credentials in a hardened secrets manager (Azure Key Vault, HashiCorp Vault, CyberArk) and document rotation procedures. Avoid embedding credentials in scripts; use managed identities or certificates where possible.\n\nAuditing, evidence collection and small-business scenario\n\nAssessors will want proof that settings are applied and being monitored. Produce the following evidence: Group Policy Management Console reports (GPO settings), output of Get-ADDefaultDomainPasswordPolicy and Get-ADFineGrainedPasswordPolicy, screenshots of GPMC, change requests/ticket records showing approvals, and audit logs demonstrating enforcement (Windows Security logs and Directory Service changes). Enable Audit Directory Service Changes and monitor for Event IDs related to password changes and policy modifications. Example small-business scenario: a 25-user company sets domain policy to 12-character minimum, creates a PSO for its 3 IT admins with 15-character minimum and stricter lockout, deploys LAPS for 40 endpoints, converts 6 services to gMSA, and stores remaining service secrets in a SaaS vault. This configuration is simple to document and presents a clear compliance story.\n\nRisks of not implementing IA.L2-3.5.7 controls\n\nFailing to implement adequate AD password protections increases the risk of credential compromise, lateral movement, privilege escalation, and data exfiltration of CUI. Attackers frequently rely on password reuse, weak passwords, and unrotated service credentials to persist. Non‑compliance also creates programmatic risk: failure during a CMMC assessment or NIST-based audit can require remediation plans, loss of contracting opportunities, or remedial actions that are more expensive than implementing controls proactively.\n\nTo keep controls effective, document your policy decisions (including any deviation from strict password rotation in favor of event-driven changes as per NIST guidance), maintain evidence, and combine strong password policies with mandatory MFA for domain-joined remote access and sensitive roles.\n\nSummary: implement a domain-level GPO with conservative password and lockout settings, use PSOs for privileged accounts, convert service accounts to gMSA or managed secrets, deploy LAPS for local admin passwords, enable auditing and retain evidence, and document all decisions and exceptions. These steps will give small businesses a practical, evidence-able path toward meeting the intent of IA.L2-3.5.7 under NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2." }, "metadata": { "description": "Step-by-step guidance to configure Active Directory password and account policies to meet NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 (IA.L2-3.5.7) requirements, including GPO, PSO, PowerShell, auditing, and small-business examples.", "permalink": "/how-to-configure-active-directory-password-policies-to-comply-with-nist-sp-800-171-rev2-cmmc-20-level-2-control-ial2-357.json", "categories": [], "tags": [] } }