How to Manage Local Security Policies in Batch Script
Local Security Policies are the fundamental building blocks of a secure Windows environment. Some examples are auditing logon events, managing user rights (like "Log on as a service"), and controlling password complexity. For IT administrators managing standalone servers or non-domain joined workstations, automating these policies is a critical task. While these settings are typically handled via the secpol.msc GUI, a Batch script can use the secedit utility to export, modify, and re-apply security templates programmatically. This guide explains how to manage these deep-level system settings.
Why Automate Local Security Policies?
- Hardening at Scale: Ensuring every server in a non-AD workgroup has the same strict security posture.
- Service Configuration: Automatically granting the "Log on as a service" right to a new service account created by your script.
- Compliance Auditing: Exporting current settings to a text file to verify they match corporate security standards.
Incorrectly modifying security policies can lock you out of your system or cause critical services (like SQL or IIS) to stop functioning. Always create a system restore point or backup your security configuration before running these scripts.
Method 1: Exporting and Auditing Current Policies (Secedit)
The secedit command allows you to dump the current local security database into a readable .inf file.
@echo off
setlocal
:: Check for admin rights
net session >nul 2>&1
if %errorlevel% neq 0 (
echo [ERROR] Administrator privileges are required.
pause
exit /b 1
)
set "OUT_FILE=%TEMP%\security_audit.inf"
echo [PROCESS] Exporting local security policies to %OUT_FILE%...
secedit /export /cfg "%OUT_FILE%" /areas SECURITYPOLICY >nul
if %errorlevel% equ 0 (
echo [SUCCESS] Policies exported successfully.
echo [INFO] File: %OUT_FILE%
echo [TIP] Open with Notepad to review settings.
) else (
echo [ERROR] Export failed. Code: %errorlevel%
)
pause
Method 2: Applying a Security Template
To change a policy, you first create a .inf file with the desired settings and then "Configure" the system database using that file.
@echo off
setlocal
:: Check for admin rights
net session >nul 2>&1
if %errorlevel% neq 0 (
echo [ERROR] Administrator privileges are required.
pause
exit /b 1
)
set "POLICY_FILE=%TEMP%\lock_policy.inf"
set "TEMP_DB=%TEMP%\temp_secedit.sdb"
:: Create a Unicode INF file using PowerShell
:: (secedit requires UTF-16 LE encoding)
echo [PROCESS] Creating security policy template...
powershell -NoProfile -Command ^
"[System.IO.File]::WriteAllText('%POLICY_FILE%', '[Unicode]`r`nUnicode=yes`r`n[System Access]`r`nLockoutBadCount = 5`r`n', [System.Text.Encoding]::Unicode)"
echo [PROCESS] Applying revised security policy...
:: Use a temporary database to avoid corrupting the main security database
secedit /configure /db "%TEMP_DB%" /cfg "%POLICY_FILE%" /areas SECURITYPOLICY
if %errorlevel% equ 0 (
echo [SUCCESS] Account lockout policy applied (5 attempts^).
) else (
echo [ERROR] Policy application failed. Code: %errorlevel%
)
:: Clean up temporary files
del "%POLICY_FILE%" >nul 2>&1
del "%TEMP_DB%" >nul 2>&1
del "%TEMP_DB%.log" >nul 2>&1
del "%TEMP_DB%.jfm" >nul 2>&1
pause
Method 3: Managing User Rights (ntrights.exe)
ntrights.exe is an old tool from the Windows Resource Kit. While not bundled with modern Windows, it is still the fastest way to manage individual user rights (like SeServiceLogonRight) from a Batch script if you can include the binary.
@echo off
:: Note: This requires ntrights.exe to be in the script's folder or PATH
set "USER=MyServiceAccount"
where ntrights >nul 2>&1
if %errorlevel% neq 0 (
echo [ERROR] ntrights.exe not found. This tool is from the Windows Resource Kit.
echo [HELP] As an alternative, use secedit or PowerShell to manage user rights.
pause
exit /b 1
)
echo [PROCESS] Granting 'Log on as a service' to %USER%...
ntrights -u "%USER%" +r SeServiceLogonRight
if %errorlevel% equ 0 (
echo [SUCCESS] Right granted to %USER%.
) else (
echo [ERROR] Failed to grant right. Code: %errorlevel%
)
pause
Creating a Robust Security Hardening Script
This script exports settings as a backup, confirms the backup was successful, and then refreshes the security database.
@echo off
setlocal
echo ============================================================
echo Local Security Policy Manager
echo ============================================================
:: 1. Verify Admin Rights
net session >nul 2>&1
if %errorlevel% neq 0 (
echo [CRITICAL] Administrator privileges are REQUIRED.
pause
exit /b 1
)
:: 2. Backup Current Config
set "BACKUP_FILE=%TEMP%\security_backup_%date:~-4%%date:~-10,2%%date:~-7,2%.inf"
echo.
echo [1/2] Backing up current settings...
secedit /export /cfg "%BACKUP_FILE%" /areas SECURITYPOLICY >nul
if %errorlevel% neq 0 (
echo [FAIL] Backup failed. Aborting for safety.
pause
exit /b 1
)
echo [PASS] Backup saved: %BACKUP_FILE%
:: 3. Refresh/Re-apply existing DB (to fix configuration drift)
echo.
echo [2/2] Refreshing local security database...
secedit /configure /db "%windir%\security\local.sdb" /cfg "%windir%\inf\defltbase.inf" /areas SECURITYPOLICY >nul
if %errorlevel% equ 0 (
echo [PASS] Security database refreshed.
) else (
echo [WARN] Refresh encountered issues. Code: %errorlevel%
echo [HELP] Review the backup file and verify via secpol.msc.
)
echo.
echo [SUCCESS] System policies refreshed and backed up.
echo ============================================================
pause
Common Pitfalls and How to Avoid Them
INF File Encoding
secedit is extremely sensitive to file encoding. It typically expects Unicode (UTF-16 LE) files.
Wrong Way:
echo [System Access] > config.inf
:: This creates an ANSI file, which secedit may reject or interpret incorrectly.
Correct Way:
Use PowerShell to generate properly encoded .inf files (as shown in Method 2), or use a pre-created template file that is already saved in UTF-16 LE encoding.
Area Specificity
Do not try to configure the entire system at once.
Use the /areas flag (e.g., /areas SECURITYPOLICY or /areas USER_RIGHTS) to target only the specific part of the security database you intend to change. This minimizes the risk of accidentally reverting other unrelated settings to their defaults.
Best Practices for Policy Automation
- Always Backup: The
local.sdbfile is opaque. If you break it, it is very hard to fix without a.infexport. - Verify via GUI: After running your script, open
secpol.mscto visually confirm that your changes are "Active" and not being overridden by a Domain Group Policy. - Domain Conflicts: Note that if the machine is joined to a Domain, Group Policy Objects (GPO) will overwrite your local security policies every 90 minutes.
Advanced audit policies (like "Audit Detailed File Share") are managed via the auditpol.exe command, which is separate from the secedit tool.
Conclusion
Managing local security policies via Batch script is a high-level administrative task that ensures the integrity and security of the Windows environment. By utilizing the secedit utility to export and apply configuration templates, you can achieve a level of consistency and automation that is impossible with manual GUI configuration. This professional approach to system hardening reduces human error, simplifies compliance audits, and provides a robust framework for securing your infrastructure across the entire Windows ecosystem.