Account Policies
Password and lockout settings are part of Local Security Policy. They control how local credentials and failed sign-ins are handled.
Windows 11 · Lesson 04
Local Security Policy
Learn how local policy controls user rights, auditing, account behavior, and system-wide security decisions that can affect the entire Windows image.
The goal is not to make every option more restrictive. Understand what the policy controls, compare it with the scenario, make justified changes, and verify the result.
Lesson Snapshot
Major policy domains4
User-right examples8
Audit categories6
Main goalSafe policy hardening
Learning objectives
What this lesson should help you do
01
Explain what Local Security Policy controls beyond ordinary Windows settings.
02
Review User Rights Assignment, Security Options, and Audit Policy with scenario context.
03
Recognize high-impact policy changes that can affect logon, RDP, networking, services, or evidence.
04
Distinguish allow rights from deny rights and understand why group membership matters.
05
Use evidence and least-disruptive reasoning before changing local security policy.
06
Verify policy, access, functionality, and logging after meaningful changes.
Core concept
Policy defines what the system permits
Account review asks who exists. Local Security Policy goes further: what may that user or group do, and what security activity should Windows record?
High-impact warning
Some policy changes can lock out the team
User-right and security-option changes can affect administrators, RDP, local sign-in, shares, services, and authentication.
Preserve a valid administrative path and know how you will test a high-impact change.
Quick path map
Exactly where to go in Local Security Policy
Open the console first with Win + R → secpol.msc, then use the path that matches the requirement you are reviewing.
Password Policy
Win + R → secpol.msc → Account Policies → Password PolicyLength, history, age, complexity, and related local password settings.
Account Lockout Policy
Win + R → secpol.msc → Account Policies → Account Lockout PolicyThreshold, duration, and reset-counter behavior.
User Rights Assignment
Win + R → secpol.msc → Local Policies → User Rights AssignmentWho may log on locally, through RDP, from the network, shut down the system, back up files, and perform other sensitive actions.
Security Options
Win + R → secpol.msc → Local Policies → Security OptionsAccount, interactive logon, UAC, network access, device, and other system-wide security behaviors.
Audit Policy
Win + R → secpol.msc → Local Policies → Audit PolicyWhich categories of security-relevant activity Windows is configured to record.
Policy map
Four major areas to recognize
Audit Policy
Determines which security-relevant activity Windows records, affecting both detection and forensic evidence.
User Rights Assignment
Defines which users or groups may perform sensitive actions such as local logon, network access, RDP logon, backup, or shutdown.
Security Options
Controls many system-wide behaviors involving accounts, interactive logon, network access, UAC, devices, and other protections.
User Rights Assignment
Rights can change who may perform sensitive actions
Allow log on locally
Controls who may sign in interactively at the computer.
Caution
Removing a required user or administrator can block local access.
Deny log on locally
Explicitly prevents selected users or groups from local interactive sign-in.
Caution
Deny assignments can override expected access and create lockouts.
Access this computer from the network
Controls which users or groups may access resources across the network.
Caution
Changing this can affect shares, remote administration, or required services.
Deny access to this computer from the network
Explicitly blocks selected users or groups from network access.
Caution
Broad deny assignments can break legitimate network workflows.
Allow log on through Remote Desktop Services
Controls who may use RDP when Remote Desktop is enabled.
Caution
Changing it can break required remote administration.
Shut down the system
Controls who may shut down the computer.
Caution
Unnecessary assignment creates additional operational risk.
Back up files and directories
Grants powerful backup access that can bypass normal file permissions.
Caution
Limit this right to users or groups that genuinely need it.
Restore files and directories
Allows restoration actions that can affect ownership and permissions.
Caution
This capability should not be assigned broadly.
Allow vs deny
Understand effective access
Allow rights grant capability
An allow assignment can permit an account or group to perform an action such as local logon or RDP logon.
Deny rights explicitly block capability
Deny assignments are intentionally restrictive and can override expected access.
Group membership affects the result
A user may receive rights through one or more groups, so review both the assignment and the user's memberships.
Effective access must be tested
If allow and deny settings interact, verify the real behavior instead of assuming the list alone tells the full story.
Evidence questions
Ask before changing security policy
01
What exact policy setting is currently configured?
02
What scenario requirement or security objective does it affect?
03
Which users, groups, services, or remote workflows depend on it?
04
Is the current setting clearly weak, or only unfamiliar?
05
Could a deny right override an allow right?
06
Could the change affect RDP, file sharing, local logon, or service accounts?
07
Could the setting change what security events are recorded?
08
How will the team verify security and functionality afterward?
Security Options
System-wide behavior deserves careful reasoning
Interactive logon
Sign-in messages, Ctrl+Alt+Del behavior, inactivity controls, and other local sign-in behavior.
Accounts
Built-in account behavior and other account-related operating-system security settings.
Network access
Anonymous access, local account behavior, and settings that influence network authentication.
User Account Control
Elevation prompts, administrator approval behavior, and secure-desktop choices.
Devices
Settings that can restrict device or removable-media behavior depending on the environment.
System security
Additional system-wide controls that may improve security but can also affect compatibility or required software.
Audit Policy
Decide what security activity Windows should record
Account Logon
Helps record authentication activity involving account validation.
Logon / Logoff
Tracks sign-in sessions, logoffs, and related authentication behavior.
Account Management
Records user and group changes and can support privilege or identity investigations.
Policy Change
Records changes to important security and audit policy.
Privilege Use
Can provide evidence about use of sensitive privileges, though excessive auditing may create noise.
System
Captures important security-subsystem and system events relevant to troubleshooting and forensics.
Impact levels
Classify before changing
Lower impact
Limited side effects and easy verification. Strong evidence may make this suitable for a normal Do Now task.
Medium impact
Can affect a user group, audit source, application, or specific workflow. Document and test carefully.
High impact
Can affect all users, administrators, RDP, network authentication, or system-wide behavior. Coordinate and preserve recovery access.
Inspection tools
Understand current policy first
Local Security Policy
secpol.mscPrimary graphical tool for local account policies, audit policy, user rights, and security options on supported Windows editions.
Local Group Policy Editor
gpedit.mscProvides broader local policy configuration and can expose settings outside the narrower security console.
Applied policy overview
gpresult /rHelps show whether policy sources beyond a simple local setting may be influencing the system.
Decision cases
Local policy decisions in context
RDP is required but login fails
The scenario requires Morgan to administer through RDP. RDP is enabled and the firewall appears correct, but Morgan cannot sign in.
The issue may be User Rights Assignment or group membership rather than the RDP service itself.
Response
Review the RDP logon right, relevant deny rights, and Morgan's group membership before changing unrelated settings.
Network access is too broad
A broad group can access the computer from the network although only a limited project group requires network access.
The assignment may be excessive, but changing it can affect shares and remote administration.
Response
Map required users and services, narrow carefully, and test the required network path afterward.
Important auditing is disabled
The scenario includes forensic questions about account changes, but account-management auditing is disabled.
Without appropriate auditing, future account changes may not be recorded.
Response
Enable the relevant audit category if appropriate, then perform a safe test and verify the Security log records it.
A stricter option breaks required software
A restrictive security option looks attractive, but a required application depends on the current behavior.
Technically stricter does not automatically mean correct for the scenario.
Response
Preserve the required application and change policy only when the scenario and compatibility evidence support it.
Audit verification
Prove the logging works
01
Decide what event question you need to answer.
02
Enable only the audit categories relevant to that question.
03
Perform a benign authorized action that should create an event.
04
Open Event Viewer and find the expected Security log evidence.
05
Document which policy produced which observable event.
Before a high-impact change
Eight safety questions
01
Do I have a working administrative session before changing this policy?
02
Could this block local logon or RDP?
03
Could this affect file sharing or network access?
04
Could a service or scheduled task depend on the affected account or right?
05
Does the scenario require the current behavior?
06
Do I understand allow versus deny behavior here?
07
Will this alter forensic or audit visibility?
08
What exact test will prove the change is safe afterward?
Fictional defensive lab
Secure policy without breaking required access
Step 01
Read the fictional scenario
Morgan is the only authorized administrator. Avery and Riley are standard users. Morgan must use RDP. File sharing is required for a small project group. A forensic question asks when local accounts were modified.
Step 02
Inspect the fictional policy
RDP logon is allowed for Administrators, network access is granted broadly, no deny-logon conflict is present, and account-management auditing is disabled.
Step 03
Identify the meaningful problems
RDP access aligns with the scenario. Network access appears broader than required. Audit visibility does not support the forensic need.
Step 04
Plan controlled corrections
Map the users who genuinely require network access, narrow the assignment without breaking the share, and enable the relevant account-management auditing.
Step 05
Test functionality
Confirm Morgan can still use RDP and the project group can still reach the required share.
Step 06
Verify evidence
Perform a safe authorized account-management action and confirm the expected Security log event is recorded.
Common mistakes
Policy changes that create avoidable problems
Changing user rights blindly
One setting can affect local sign-in, RDP, shares, services, backup capability, or another required workflow.
Ignoring deny assignments
Deny rights can override access that appears to be granted elsewhere.
Assuming stricter is always better
A stronger-looking setting can still be wrong if it conflicts with the scenario or required software.
Enabling every audit category
Too much logging creates noise. Audit what supports the security and forensic questions you need to answer.
Making high-impact changes without recovery access
Do not risk losing the only working administrative path to the image.
Skipping functional verification
Policy work is not complete until required users, RDP, shares, services, and logging still function.
Reflection
Test your security-policy reasoning
Question 1
Why can User Rights Assignment be riskier to change than a normal visual setting?
Question 2
How can a deny right affect an account that also belongs to an allowed group?
Question 3
Why should RDP be tested after changing user rights?
Question 4
What is the purpose of auditing account-management activity?
Question 5
Why can enabling every audit category be counterproductive?
Question 6
What should you verify after changing a high-impact security option?
Verification checklist
Confirm the final policy state
01
Re-open each changed setting and confirm its final value.
02
Confirm authorized local logon still works.
03
Confirm required RDP access still works when applicable.
04
Confirm required network access and shares still work.
05
Confirm service accounts and privileged groups were not unintentionally blocked.
06
Confirm expected audit events are being recorded.
07
Check Event Viewer for errors related to the change.
08
Document high-impact policy changes and test results.
09
Re-read scenario requirements before leaving Local Security Policy.
Next Windows lesson
Microsoft Defender Antivirus
Next, review Defender protection status, exclusions, scan behavior, protection history, and evidence without destroying information that may matter to the competition image.