This post explains how to implement the NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 requirement AC.L2-3.1.8 — limiting unsuccessful logon attempts — by configuring Windows and Active Directory, with step-by-step GPO instructions, local-machine commands, monitoring guidance, and small-business examples that map directly to compliance evidence collection.
\n\nAC.L2-3.1.8 requires organizations to limit failed authentication attempts to reduce the effectiveness of brute-force and credential-stuffing attacks; without such controls, attackers can automate password guessing to compromise accounts, enable lateral movement, and access controlled unclassified information (CUI). In practice, lacking a lockout strategy also increases risk from compromised service accounts or reused credentials and makes detection and incident response more difficult because noisy authentication attempts can mask targeted activity.
\n\nThere is no single “correct” numeric value mandated by NIST/CMMC, so select settings that balance security and availability. Practical recommended values for most small-to-medium organizations: Account lockout threshold = 5 invalid logon attempts; Account lockout duration = 15 minutes; Reset account lockout counter after = 15 minutes. These values limit attack speed while minimizing denial-of-service risk from accidental lockouts. If you operate exposed RDP hosts or legacy apps that cause repeated failures, consider 7–10 attempts or implement compensating controls (MFA, network restrictions, jump hosts) instead of simply raising thresholds.
\n\nTo set lockout policy at the domain level (recommended so it applies consistently to all domain accounts), edit the Default Domain Policy or a domain‑level GPO: open Group Policy Management (gpmc.msc) → expand your domain → right-click Default Domain Policy → Edit → Computer Configuration → Policies → Windows Settings → Security Settings → Account Policies → Account Lockout Policy. Configure the three settings (Account lockout threshold, Account lockout duration, Reset account lockout counter) to your chosen values (for example 5 / 15 / 15). After applying, run gpupdate /force on domain controllers and client machines and validate with gpresult /r or the Resultant Set of Policy (rsop.msc).
\n\nVerify policy application by checking a client with “gpresult /h report.html” and opening the HTML to ensure the Account Lockout Policy is present. Monitor event logs for failed sign-in attempts and lockouts: look for Event ID 4625 (failed logon) and Event ID 4740 (account locked out) in the Security log on DCs and affected hosts. For evidence collection during assessment, capture screenshots of the GPO settings, export the GPO report from GPMC, and collect sample event log entries showing failed attempts followed by a 4740.
\n\nFor standalone machines or systems not joined to the domain, configure local policy via secpol.msc (Local Policies → Security Options) or use the command line: net accounts /lockoutthreshold:5 /lockoutduration:15 /lockoutwindow:15. You can export and check the local security policy with secedit: secedit /export /cfg C:\\temp\\localsec.cfg then open the file and confirm LockoutBadCount, LockoutDuration, and ResetLockoutCount values. Include these exports and screenshots as evidence for standalone system compliance.
\n\nExample 1 — receptionist locked out frequently: If a shared workstation causes accidental lockouts because many users share profiles, implement per-user domain accounts, set thresholds carefully (e.g., 5), and deploy MFA for interactive logons. Example 2 — backup service causing lockouts: Replace legacy service accounts that store passwords in clear text with gMSAs (group Managed Service Accounts) or configure services to use computer accounts; this prevents scheduled task credential mismatches from triggering lockouts. Example 3 — remote workers: Limit RDP exposure with a VPN/jump host, enable MFA for remote access, and monitor failed connection spikes to detect credential-stuffing campaigns.
\n\nImplement centralized logging (SIEM, syslog aggregation, or cloud log collection) to collect 4625/4740 events from domain controllers and critical servers; retain logs per your policy to meet evidence retention requirements. Compliance evidence should include: (a) GPO configuration screenshots or exported policy files, (b) gpresult/rsop reports from representative endpoints, (c) sample event logs showing failed attempts and lockout events, and (d) documentation of the chosen thresholds and rationale. Additional tips: enforce MFA for sensitive accounts, maintain a break-glass account with different controls and monitoring, and test lockout behavior during change windows to verify legitimate services are not interrupted.
\n\nIn summary, implement domain-level account lockout policies via GPO with recommended thresholds (e.g., 5/15/15), configure standalone machines with net accounts or secpol, monitor lockout and failed-sign-in events (4625/4740), and document settings and evidence for NIST SP 800-171 / CMMC 2.0 assessments. Pair lockout controls with MFA, managed service accounts, and centralized logging to minimize operational disruption while meeting AC.L2-3.1.8 requirements.
", "plain_text": "This post explains how to implement the NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 requirement AC.L2-3.1.8 — limiting unsuccessful logon attempts — by configuring Windows and Active Directory, with step-by-step GPO instructions, local-machine commands, monitoring guidance, and small-business examples that map directly to compliance evidence collection.\n\nWhy this control matters and risks of non‑implementation\nAC.L2-3.1.8 requires organizations to limit failed authentication attempts to reduce the effectiveness of brute-force and credential-stuffing attacks; without such controls, attackers can automate password guessing to compromise accounts, enable lateral movement, and access controlled unclassified information (CUI). In practice, lacking a lockout strategy also increases risk from compromised service accounts or reused credentials and makes detection and incident response more difficult because noisy authentication attempts can mask targeted activity.\n\nRecommended account lockout settings and trade-offs\nThere is no single “correct” numeric value mandated by NIST/CMMC, so select settings that balance security and availability. Practical recommended values for most small-to-medium organizations: Account lockout threshold = 5 invalid logon attempts; Account lockout duration = 15 minutes; Reset account lockout counter after = 15 minutes. These values limit attack speed while minimizing denial-of-service risk from accidental lockouts. If you operate exposed RDP hosts or legacy apps that cause repeated failures, consider 7–10 attempts or implement compensating controls (MFA, network restrictions, jump hosts) instead of simply raising thresholds.\n\nConfigure Account Lockout via Active Directory Group Policy (domain environment)\nTo set lockout policy at the domain level (recommended so it applies consistently to all domain accounts), edit the Default Domain Policy or a domain‑level GPO: open Group Policy Management (gpmc.msc) → expand your domain → right-click Default Domain Policy → Edit → Computer Configuration → Policies → Windows Settings → Security Settings → Account Policies → Account Lockout Policy. Configure the three settings (Account lockout threshold, Account lockout duration, Reset account lockout counter) to your chosen values (for example 5 / 15 / 15). After applying, run gpupdate /force on domain controllers and client machines and validate with gpresult /r or the Resultant Set of Policy (rsop.msc).\n\nDomain-level verification and auditing\nVerify policy application by checking a client with “gpresult /h report.html” and opening the HTML to ensure the Account Lockout Policy is present. Monitor event logs for failed sign-in attempts and lockouts: look for Event ID 4625 (failed logon) and Event ID 4740 (account locked out) in the Security log on DCs and affected hosts. For evidence collection during assessment, capture screenshots of the GPO settings, export the GPO report from GPMC, and collect sample event log entries showing failed attempts followed by a 4740.\n\nConfiguring local and standalone Windows systems\nFor standalone machines or systems not joined to the domain, configure local policy via secpol.msc (Local Policies → Security Options) or use the command line: net accounts /lockoutthreshold:5 /lockoutduration:15 /lockoutwindow:15. You can export and check the local security policy with secedit: secedit /export /cfg C:\\temp\\localsec.cfg then open the file and confirm LockoutBadCount, LockoutDuration, and ResetLockoutCount values. Include these exports and screenshots as evidence for standalone system compliance.\n\nReal-world small business scenarios and mitigations\nExample 1 — receptionist locked out frequently: If a shared workstation causes accidental lockouts because many users share profiles, implement per-user domain accounts, set thresholds carefully (e.g., 5), and deploy MFA for interactive logons. Example 2 — backup service causing lockouts: Replace legacy service accounts that store passwords in clear text with gMSAs (group Managed Service Accounts) or configure services to use computer accounts; this prevents scheduled task credential mismatches from triggering lockouts. Example 3 — remote workers: Limit RDP exposure with a VPN/jump host, enable MFA for remote access, and monitor failed connection spikes to detect credential-stuffing campaigns.\n\nMonitoring, evidence, and compliance tips\nImplement centralized logging (SIEM, syslog aggregation, or cloud log collection) to collect 4625/4740 events from domain controllers and critical servers; retain logs per your policy to meet evidence retention requirements. Compliance evidence should include: (a) GPO configuration screenshots or exported policy files, (b) gpresult/rsop reports from representative endpoints, (c) sample event logs showing failed attempts and lockout events, and (d) documentation of the chosen thresholds and rationale. Additional tips: enforce MFA for sensitive accounts, maintain a break-glass account with different controls and monitoring, and test lockout behavior during change windows to verify legitimate services are not interrupted.\n\nIn summary, implement domain-level account lockout policies via GPO with recommended thresholds (e.g., 5/15/15), configure standalone machines with net accounts or secpol, monitor lockout and failed-sign-in events (4625/4740), and document settings and evidence for NIST SP 800-171 / CMMC 2.0 assessments. Pair lockout controls with MFA, managed service accounts, and centralized logging to minimize operational disruption while meeting AC.L2-3.1.8 requirements." }, "metadata": { "description": "Step-by-step guidance to configure Windows and Active Directory account lockout settings to meet NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 AC.L2-3.1.8 requirements, with recommended values, commands, and audit evidence.", "permalink": "/how-to-configure-windows-and-active-directory-to-limit-unsuccessful-logon-attempts-nist-sp-800-171-rev2-cmmc-20-level-2-control-acl2-318.json", "categories": [], "tags": [] } }