SEC401 - Windows Security
Lab 5.3 - Applying Windows System Security Policies
Solo, Lab
Focus: Windows Security
Level: SEC401
Date: Apr 2026
Artifacts: Sanitized PowerShell and MMC screenshots from secedit.exe analyze/configure workflow
TL;DR
- •secedit /analyze compared a live VM to the Alpha basic security template
- •Surfaced 5 Mismatch entries (password length, lockout, event log size) via Select-String
- •Applied the template with secedit /configure and re-analyzed to verify
Skills demonstrated
Note: Course-provided PCAPs and lab instructions are not shared. Only my own captures and sanitized notes are published.
Why this matters
Every Windows hardening program lives or dies on two questions: does this host match the baseline, and can you prove it after the fact? secedit /analyze and /configure are the oldest, simplest answer to both — zero extra tooling required, and the log format is grep-friendly. If you can't drive this workflow from a console you can't scale hardening to more than one host.
Context
This lab demonstrates how to baseline a Windows host against a security template, identify policy drift, apply a hardened configuration, and verify the change — using secedit.exe from PowerShell and the Security Templates / Security Configuration and Analysis MMC snap-ins.
Tools used
Steps taken
1Review secedit.exe /analyze syntax
Ran secedit /analyze with no arguments to print the help text. The workflow needs three things: a database file (/db) to hold the analysis, a configuration template (/cfg) that defines the desired state, and a log file (/log) to record per-setting results.
$ secedit.exe /analyze/dbanalysis database (.sdb)/cfgsecurity template file (.inf)/logoutput log path/quietsuppress prompts2Analyze the VM against the Alpha basic template
Ran secedit /analyze against the Alpha-Win-Wkstn-Basic-Sec-Policy.inf template. The engine compares every setting in the template to the current VM state and writes per-setting results to the compare log. Task completed successfully means the analysis engine ran cleanly — the actual drift findings live in the log.
$ secedit.exe /analyze /db alpha-basic-policy.sdb /cfg Alpha-Win-Wkstn-Basic-Sec-Policy.inf /log C:\sec401\labs\5.3\compare-vm-to-alpha-basic-policy.log3Open the compare log and scan for Mismatch
Opened the log in Notepad and used Find to jump through 'Mismatch' entries. The --Analyze Security Policy-- section shows MinimumPasswordLength as Mismatch while adjacent settings (PasswordHistorySize, MaximumPasswordAge, PasswordComplexity) are Not Configured — meaning the template doesn't define them. LockoutBadCount is also flagged.
$ notepad C:\sec401\labs\5.3\compare-vm-to-alpha-basic-policy.log4Grep the log with Select-String
Piped Get-Content to Select-String 'mismatch' to list only the drift. Five Mismatch lines: MinimumPasswordLength, LockoutBadCount, and MaximumLogSize (x3 — one per event log: Application, Security, System). That's the exact hardening delta the template will apply.
$ Get-Content .\compare-vm-to-alpha-basic-policy.log | Select-String 'mismatch'Get-Contentread file into pipelineSelect-Stringpattern match (PowerShell's grep)5Apply the template with secedit /configure
Ran secedit /configure using the same database. /configure is the verb that actually writes the template's settings into local policy. The task completed successfully message means every defined setting in the template was applied.
$ secedit.exe /configure /db alpha-basic-policy.sdb /log C:\sec401\labs\5.3\apply-apha-basic-policy-to-vm.log/configureapply template settings to the host/dbuse the prior analysis database (keeps settings consistent)6Re-analyze to verify the drift is gone
Ran /analyze a second time and wrote the output to recompare-vm-to-alpha-basic-policy.log. Running the compare twice — once before /configure and once after — is the evidence pattern: the second log should show zero Mismatch entries, which proves the template was applied successfully.
$ secedit.exe /analyze /db alpha-basic-policy.sdb /log C:\sec401\labs\5.3\recompare-vm-to-alpha-basic-policy.log7Load the MMC snap-ins
Added Security Templates and Security Configuration and Analysis to an MMC console. The MMC snap-ins are the GUI equivalent of secedit /analyze and /configure — useful for editing .inf templates interactively and for analysts who prefer a tree view. Same engine, different surface.
$ mmc.exe (File → Add/Remove Snap-in → Security Templates, Security Configuration and Analysis)Key findings
Outcome / Lessons learned
Demonstrated the full Windows baseline compliance loop: analyze a host against a template, surface the exact drift with Select-String, apply the template, and re-analyze to prove the drift is gone — all from a single PowerShell console with secedit.exe.
In a fleet environment, push the .inf template via Group Policy (SCE → Security Settings) instead of running secedit host-by-host. Automate the analyze/configure/reanalyze loop with a PowerShell wrapper so the compare logs land in a central share for audit evidence. Replace the basic template with a CIS Benchmark or Microsoft Security Compliance Toolkit baseline and extend the detection pipeline so any Mismatch on a production host raises a SIEM alert.
Security controls relevant
- Windows security baselines (CIS, Microsoft SCT)
- Group Policy Objects and Local Security Policy
- Password policy (length, history, lockout)
- Event log sizing and retention
- Configuration drift detection and audit evidence
What I took away from this
secedit is one of those tools that's been in Windows forever and still does exactly what you want. /analyze and /configure are both idempotent and log-first, which makes them trivially scriptable: run analyze, grep for Mismatch, run configure, run analyze again, diff. That before/after pair of logs is also the cleanest audit artifact you can hand an assessor.
The Not Configured vs. Mismatch distinction in the log matters. Not Configured means the template is silent on that setting — the host can do whatever it wants. Mismatch means the template has an opinion and the host disagrees. A lot of 'we applied the baseline' incidents trace back to teams not reading this distinction and assuming Not Configured means compliant.
The real production move is GPO, not host-by-host secedit. But understanding secedit is what makes the GPO debugging tractable — when a policy doesn't apply on one host, dropping to secedit /analyze on that box is the fastest way to see which specific setting didn't take and why.