Skip to main content

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.
High Risk

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)

Legacy Tool

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.

SEO and UX Tip

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

  1. Always Backup: The local.sdb file is opaque. If you break it, it is very hard to fix without a .inf export.
  2. Verify via GUI: After running your script, open secpol.msc to visually confirm that your changes are "Active" and not being overridden by a Domain Group Policy.
  3. 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.
Audit Policies

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.