Local Security Policy & Security Configuration Wizard

#One Misconfigured Audit Policy Can Hide an Entire Attack#link

The Local Security Policy (secpol.msc) and Security Configuration Wizard (SCW) are the Swiss army knives of Windows hardening. Yet many admins either ignore them or blindly apply templates without understanding the implications. This lesson teaches you to craft a security policy that aligns with your server's role—web server, database, or domain controller—while avoiding common pitfalls like disabling necessary services or creating blind spots in audit logs.

User Rights Assignment: The Backbone of Security Policy

User Rights Assignments control who can log on locally, shut down the system, debug programs, and dozens of other sensitive actions. The default 'Access this computer from the network' includes Everyone; you should restrict it to 'Authenticated Users' or specific groups. 'Debug programs' (SeDebugPrivilege) is a critical right—attackers use it to inject into lsass.exe. Remove it from all non-admin accounts. Always configure these via Group Policy for consistency.

The exported INF file contains every local policy setting. You can diff it against a CIS benchmark template to identify deviations.

# List user rights assignments using PowerShell
Get-Policy -Type "User Rights" | Format-Table Identity, Access, NTAccount

Security Configuration Wizard: Role-Based Hardening

SCW (scw.exe) is a role-based tool that analyzes a server's functions, services, and network ports, then produces an XML security policy that disables unnecessary services, configures firewall rules, and sets audit policies. It's far more granular than a blanket GPO. After running SCW, review the generated policy carefully—it might disable a service needed by a third-party app. The resulting XML can be applied with scwcmd configure.

Audit Policy: Logging What Matters

A common mistake is enabling 'Success' audit for everything and flooding the security log. Use SCW or GPO to set a targeted audit policy: Audit Logon Events (Success, Failure), Account Management, Privilege Use, and Object Access only on sensitive folders. On domain controllers, also enable Directory Service Access. Test the log volume and adjust with auditpol.exe before pushing to production.

• ▪Export and review the current security policy with secedit before making changes.
• ▪Run SCW for each server role; don't apply the same policy to a web server and a DC.
• ▪Restrict SeDebugPrivilege to Administrators only—remove even from 'Power Users'.
• ▪Configure audit policy to capture account logons, privilege use, and policy changes.