Least‑privilege is a foundational requirement for FAR 52.204‑21 and CMMC 2.0 Level 1 control AC.L1‑B.1.II: grant users only the permissions they need to do their job and nothing more—this post shows concrete, actionable steps to configure least‑privilege on both Windows and Linux systems, including commands, Group Policy guidance, sudo rules, and small‑business scenarios you can implement immediately to meet Compliance Framework expectations.
\n\nAt a practical level the Control AC.L1‑B.1.II (least privilege) requires documented processes and technical enforcement so that users and programs run with the minimum required privileges. For compliance evidence, the Compliance Framework expects an access control policy, an access matrix or role descriptions, records of group membership and privileged accounts, configuration items (GPO exports, sudoers files), and logs showing enforcement (audit events, sudo logs, Windows Security events). Small organizations should be able to produce: an access control policy, a spreadsheet or RBAC map, exported GPOs or configuration management templates, and screenshots or logs demonstrating enforcement and periodic access reviews.
\n\nStart by eliminating unnecessary local administrative rights: make users standard (non‑admin) accounts and use dedicated admin accounts only when performing admin tasks. In Active Directory environments enforce this with Group Policy: Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → User Rights Assignment, and apply Restricted Groups or Preferred Management GPOs to ensure only approved service accounts and break‑glass accounts are in the local Administrators group. For single‑site/small business without AD, use PowerShell and local group management scripts to remove users from Administrators and audit memberships nightly.
\n\nExamples you can run or schedule: list members of local Administrators on a remote host: Get-LocalGroupMember -Group \"Administrators\" -ComputerName PC01. Remove a user from Administrators: Remove-LocalGroupMember -Group \"Administrators\" -Member \"CONTOSO\\jdoe\". Set NTFS permissions for a finance folder: icacls \"C:\\Data\\Finance\" /grant \"CONTOSO\\FinanceGroup:(OI)(CI)M\" /inheritance:r. Use LAPS to manage local admin passwords (deploy via GPO and use Get-AdmPwdPassword -ComputerName HOST to retrieve when needed). Harden execution: enable UAC, enable AppLocker or Software Restriction Policies to limit which executables or scripts can run, and enable Advanced Audit Policy for Object Access (audit success/failure) to produce logs proving enforcement.
\n\nOn Linux, implement least‑privilege by using non‑privileged accounts, group‑based access, and well‑scoped sudo rules. Remove direct root SSH access (edit /etc/ssh/sshd_config, set PermitRootLogin no, then systemctl restart sshd). Create role groups (finance, dev, ops) and assign users to those groups: usermod -aG finance jdoe. For file system access, use chown and chmod or POSIX ACLs to limit directories: chown root:finance /srv/finance && chmod 750 /srv/finance and setfacl -m g:finance:rwx /srv/finance to grant finer control.
\n\nUse visudo to create scoped sudoers snippets under /etc/sudoers.d. Example restricting finance admins to only run backup and view commands: create /etc/sudoers.d/finance with lines like \"Cmnd_Alias FIN_CMDS = /usr/bin/rsync, /usr/bin/tar, /usr/bin/less\" and \"%finance ALL=(ALL) FIN_CMDS\". Avoid NOPASSWD except for automated tasks that cannot handle prompts, and log all sudo usage (defaults log_output, and set log_timestamp in sudoers). For shell commands: to add a finance group and set ACLs: groupadd finance; usermod -aG finance jdoe; mkdir /srv/finance; chown root:finance /srv/finance; chmod 750 /srv/finance; setfacl -m d:g:finance:rwx /srv/finance. Use auditd to capture privileged command execution: auditctl -w /etc/sudoers -p wa -k privileged_changes and configure rules to log execve events for critical commands.
\n\nPractical small‑business scenarios: 1) Accounting team—create a FinanceGroup, grant folder access via NTFS or POSIX ACLs, restrict QuickBooks/financial software to a few workstations via AppLocker or binary whitelisting and prevent those users from installing software; 2) Developers—use a DevGroup with read/write to repos but no access to finance or HR shares; 3) Admins—use dedicated admin accounts only for changes and protect them with MFA and JIT elevation where possible. Operationalize least‑privilege with a documented onboarding/deprovisioning process, weekly or monthly group membership reports (PowerShell script to export local group and AD group memberships; getent group for Linux), and quarterly access reviews with attestation from managers.
\n\nFailing to enforce least‑privilege increases risk of lateral movement, privilege escalation, ransomware spreading, and accidental data disclosure—an attacker who compromises one developer or user account with broad rights can access CUI across your environment. For compliance, common pitfalls include undocumented privileged accounts, shared admin passwords, and missing audit logs. Tips: maintain an access control matrix; use automation (SCCM/Intune, Ansible, Chef) to enforce configuration; record and rotate privileged credentials (LAPS for Windows, Vault or HashiCorp for Linux admin secrets); use a break‑glass account controlled and logged; and preserve logs and evidence demonstrating enforcement during assessments.
\n\nIn summary, achieving AC.L1‑B.1.II for FAR 52.204‑21 and CMMC 2.0 Level 1 is a mix of simple technical controls (remove local admin by default, implement scoped sudoers and ACLs, use LAPS, disable root SSH), operational processes (access matrix, provisioning/deprovisioning, periodic reviews), and logging to provide evidence for auditors; small businesses can implement these with built‑in OS tools plus lightweight automation to create a repeatable, auditable least‑privilege environment that meets Compliance Framework expectations.
", "plain_text": "Least‑privilege is a foundational requirement for FAR 52.204‑21 and CMMC 2.0 Level 1 control AC.L1‑B.1.II: grant users only the permissions they need to do their job and nothing more—this post shows concrete, actionable steps to configure least‑privilege on both Windows and Linux systems, including commands, Group Policy guidance, sudo rules, and small‑business scenarios you can implement immediately to meet Compliance Framework expectations.\n\nUnderstanding the requirement and evidence expectations\nAt a practical level the Control AC.L1‑B.1.II (least privilege) requires documented processes and technical enforcement so that users and programs run with the minimum required privileges. For compliance evidence, the Compliance Framework expects an access control policy, an access matrix or role descriptions, records of group membership and privileged accounts, configuration items (GPO exports, sudoers files), and logs showing enforcement (audit events, sudo logs, Windows Security events). Small organizations should be able to produce: an access control policy, a spreadsheet or RBAC map, exported GPOs or configuration management templates, and screenshots or logs demonstrating enforcement and periodic access reviews.\n\nImplementation on Windows (workstations and servers)\nStart by eliminating unnecessary local administrative rights: make users standard (non‑admin) accounts and use dedicated admin accounts only when performing admin tasks. In Active Directory environments enforce this with Group Policy: Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → User Rights Assignment, and apply Restricted Groups or Preferred Management GPOs to ensure only approved service accounts and break‑glass accounts are in the local Administrators group. For single‑site/small business without AD, use PowerShell and local group management scripts to remove users from Administrators and audit memberships nightly.\n\nConcrete Windows commands and controls\nExamples you can run or schedule: list members of local Administrators on a remote host: Get-LocalGroupMember -Group \"Administrators\" -ComputerName PC01. Remove a user from Administrators: Remove-LocalGroupMember -Group \"Administrators\" -Member \"CONTOSO\\jdoe\". Set NTFS permissions for a finance folder: icacls \"C:\\Data\\Finance\" /grant \"CONTOSO\\FinanceGroup:(OI)(CI)M\" /inheritance:r. Use LAPS to manage local admin passwords (deploy via GPO and use Get-AdmPwdPassword -ComputerName HOST to retrieve when needed). Harden execution: enable UAC, enable AppLocker or Software Restriction Policies to limit which executables or scripts can run, and enable Advanced Audit Policy for Object Access (audit success/failure) to produce logs proving enforcement.\n\nImplementation on Linux (servers and workstations)\nOn Linux, implement least‑privilege by using non‑privileged accounts, group‑based access, and well‑scoped sudo rules. Remove direct root SSH access (edit /etc/ssh/sshd_config, set PermitRootLogin no, then systemctl restart sshd). Create role groups (finance, dev, ops) and assign users to those groups: usermod -aG finance jdoe. For file system access, use chown and chmod or POSIX ACLs to limit directories: chown root:finance /srv/finance && chmod 750 /srv/finance and setfacl -m g:finance:rwx /srv/finance to grant finer control.\n\nConcrete Linux sudoers and ACL examples\nUse visudo to create scoped sudoers snippets under /etc/sudoers.d. Example restricting finance admins to only run backup and view commands: create /etc/sudoers.d/finance with lines like \"Cmnd_Alias FIN_CMDS = /usr/bin/rsync, /usr/bin/tar, /usr/bin/less\" and \"%finance ALL=(ALL) FIN_CMDS\". Avoid NOPASSWD except for automated tasks that cannot handle prompts, and log all sudo usage (defaults log_output, and set log_timestamp in sudoers). For shell commands: to add a finance group and set ACLs: groupadd finance; usermod -aG finance jdoe; mkdir /srv/finance; chown root:finance /srv/finance; chmod 750 /srv/finance; setfacl -m d:g:finance:rwx /srv/finance. Use auditd to capture privileged command execution: auditctl -w /etc/sudoers -p wa -k privileged_changes and configure rules to log execve events for critical commands.\n\nOperational controls, monitoring, and small‑business scenarios\nPractical small‑business scenarios: 1) Accounting team—create a FinanceGroup, grant folder access via NTFS or POSIX ACLs, restrict QuickBooks/financial software to a few workstations via AppLocker or binary whitelisting and prevent those users from installing software; 2) Developers—use a DevGroup with read/write to repos but no access to finance or HR shares; 3) Admins—use dedicated admin accounts only for changes and protect them with MFA and JIT elevation where possible. Operationalize least‑privilege with a documented onboarding/deprovisioning process, weekly or monthly group membership reports (PowerShell script to export local group and AD group memberships; getent group for Linux), and quarterly access reviews with attestation from managers.\n\nRisks of not implementing least‑privilege and compliance tips\nFailing to enforce least‑privilege increases risk of lateral movement, privilege escalation, ransomware spreading, and accidental data disclosure—an attacker who compromises one developer or user account with broad rights can access CUI across your environment. For compliance, common pitfalls include undocumented privileged accounts, shared admin passwords, and missing audit logs. Tips: maintain an access control matrix; use automation (SCCM/Intune, Ansible, Chef) to enforce configuration; record and rotate privileged credentials (LAPS for Windows, Vault or HashiCorp for Linux admin secrets); use a break‑glass account controlled and logged; and preserve logs and evidence demonstrating enforcement during assessments.\n\nIn summary, achieving AC.L1‑B.1.II for FAR 52.204‑21 and CMMC 2.0 Level 1 is a mix of simple technical controls (remove local admin by default, implement scoped sudoers and ACLs, use LAPS, disable root SSH), operational processes (access matrix, provisioning/deprovisioning, periodic reviews), and logging to provide evidence for auditors; small businesses can implement these with built‑in OS tools plus lightweight automation to create a repeatable, auditable least‑privilege environment that meets Compliance Framework expectations." }, "metadata": { "description": "Practical, hands‑on guidance to implement least‑privilege access controls in Windows and Linux to satisfy FAR 52.204-21 and CMMC 2.0 Level 1 AC.L1-B.1.II requirements for small businesses.", "permalink": "/how-to-configure-least-privilege-permissions-in-windows-and-linux-for-far-52204-21-cmmc-20-level-1-control-acl1-b1ii.json", "categories": [], "tags": [] } }