Windows Server · Lesson 06
Learn where local and domain password policy actually comes from, how account lockout settings work together, and how to protect authentication without breaking required accounts.
The secure choice is not a memorized number. It is the policy that satisfies the scenario, protects the environment, and preserves required administrative and service access.
Lesson Snapshot
Learning objectives
Explain how local password policy differs from domain password policy on Windows Server.
Use the correct administrative path to review password and account lockout settings at the right scope.
Interpret password length, history, age, complexity, lockout threshold, lockout duration, and reset counter settings.
Use gpresult, net accounts, and Active Directory PowerShell to inspect effective account-policy context.
Recognize why domain controllers and domain users require domain-level policy reasoning.
Avoid one-size-fits-all values by following scenario requirements, organizational policy, and dependency-aware verification.
Core concepts
Controls password-related requirements such as history, age, length, and complexity at the applicable local or domain scope.
Controls when repeated failed sign-in attempts can lock an account and how long that lockout lasts.
For domain accounts, password and lockout behavior is normally governed by domain-level policy rather than one member server's local setting.
Applies to local accounts on a standalone or member server when the setting is not superseded by other applicable policy.
In Active Directory, Password Settings Objects can apply different password or lockout requirements to selected users or global security groups.
The policy that actually governs the target account after scope, domain configuration, and any fine-grained password policy are considered.
Core idea
A strong-looking setting in the wrong place may do nothing for the account you are trying to protect.
Availability warning
Password resets and lockout changes can affect administrators, services, tasks, applications, and remote-management workflows.
Tool map
Server Manager → Tools → Group Policy Management → Forest → Domains → your domain → review the domain-linked GPO that defines account policyQuick action
Win + R → gpmc.msc
For domain accounts, review the domain-level policy source instead of assuming a member server's local policy controls the result.
Computer Configuration → Policies → Windows Settings → Security Settings → Account Policies → Password PolicyQuick action
Open the correct GPO first, then navigate to Password Policy.
Review each configured value in context. Do not substitute arbitrary values for scenario or organizational requirements.
Computer Configuration → Policies → Windows Settings → Security Settings → Account Policies → Account Lockout PolicyQuick action
Open the correct GPO first, then navigate to Account Lockout Policy.
Lockout policy reduces password-guessing risk but overly aggressive settings can create availability problems.
Win + R → secpol.msc → Account PoliciesQuick action
Use on applicable member or standalone servers for local-account policy review.
Do not assume this is the effective source for domain-user password policy.
Win + R → gpedit.msc → Computer Configuration → Windows Settings → Security Settings → Account PoliciesQuick action
Useful for local policy review when local scope is appropriate.
Domain GPOs can supersede local settings on domain-joined systems.
Server Manager → Tools → Active Directory Administrative Center → your domain → System → Password Settings ContainerQuick action
Use when reviewing fine-grained password policies.
Fine-grained password policy can change the result for selected domain users or groups even when the default domain policy looks correct.
Password Policy
Determines how many previous passwords are remembered so users cannot immediately recycle them.
Decision note
Review the required policy and whether account workflows depend on frequent password changes.
Defines how long a password can remain valid before change is required when expiration is used.
Decision note
Do not assume shorter is always safer. Follow the scenario or authorized policy.
Controls how soon a password can be changed again and can help prevent rapid cycling through password history.
Decision note
Review together with password history and administrative reset procedures.
Sets the minimum number of characters required for passwords under the applicable policy.
Decision note
Use the scenario or organizational requirement rather than inventing a universal competition value.
Enables Windows complexity rules for applicable passwords.
Decision note
Understand what the setting changes and verify that required accounts can still authenticate after policy changes.
Allows passwords to be stored in a form that can be recovered by the system for legacy authentication needs.
Decision note
Treat enabling this as high risk unless an explicit authorized requirement justifies it.
Account Lockout Policy
Specifies how many failed sign-in attempts can trigger lockout when lockout is configured.
Too permissive can allow repeated guessing; too aggressive can make denial-of-service or accidental lockouts easier.
Controls how long a locked account remains locked before automatic recovery when configured that way.
Long lockouts can interrupt required administration or service access if applied carelessly.
Defines when the failed-attempt counter returns toward a clean state.
Review it together with threshold and duration rather than treating each value independently.
Scope examples
Likely source
Local security policy or applicable policy affecting that server's local accounts.
Inspect
secpol.msc, gpresult, and net accounts on the member server.
Likely source
Default domain password policy or another domain-level account-policy source.
Inspect
Group Policy Management plus Get-ADDefaultDomainPasswordPolicy.
Likely source
A Password Settings Object with higher precedence for that user or group.
Inspect
Active Directory Administrative Center or Get-ADUserResultantPasswordPolicy.
Likely source
Local account policy on that member server, subject to applicable security configuration.
Inspect
Local Security Policy and local account state.
Likely source
Depends on whether the identity is local or domain-based and whether a fine-grained policy applies.
Inspect
Identify the account type first, then inspect the correct local or domain policy source.
Inspection commands
net accountsShows a concise local account-policy summary on the current system. On a domain controller, interpret output in the correct domain context.
net accounts /domainQueries domain account-policy information when run with appropriate domain connectivity and permissions.
Get-ADDefaultDomainPasswordPolicyShows the Active Directory domain's default password and lockout policy when the ActiveDirectory module is available.
Get-ADUserResultantPasswordPolicy -Identity "username"Shows the effective fine-grained password policy for a specific domain user when one applies.
Get-ADFineGrainedPasswordPolicy -Filter * | Select-Object Name, Precedence, MinPasswordLength, PasswordHistoryCount, LockoutThresholdInventories Password Settings Objects without changing them.
gpresult /rShows applied Group Policy context and helps confirm whether the expected domain GPO is affecting the server.
Fine-grained password policy
Fine-grained password policy allows different domain users or global security groups to receive different password and lockout requirements.
Password Settings Objects are stored in Active Directory and can be reviewed in Active Directory Administrative Center or with PowerShell.
When multiple Password Settings Objects could apply, precedence helps determine which one wins.
Always check the user's resultant password policy instead of guessing from group membership alone.
Some environments use different password behavior for service identities, but every exception should be justified and protected carefully.
If a user's behavior does not match the default domain policy, investigate whether a fine-grained policy is affecting the account.
Safe review flow
01
Determine whether you are reviewing a local account, domain account, or service identity before looking at policy values.
02
Use Local Security Policy for local-account context and Group Policy Management / Active Directory tools for domain-account context.
03
Use net accounts, gpresult, Get-ADDefaultDomainPasswordPolicy, and resultant password-policy checks as appropriate.
04
Use the fictional scenario or authorized organizational policy as the standard instead of choosing arbitrary values.
05
Identify administrators, services, tasks, applications, and remote workflows that could fail after password or lockout changes.
06
Make the smallest justified change, then verify authentication, required services, and administrative access.
Operational risks
Changing lockout behavior without preserving an authorized recovery path can interrupt management access.
Changing password behavior for an account used by a service, task, application, or scheduled job can cause failures.
The local value may be overwritten or irrelevant for domain users.
A secure policy still needs to match scenario requirements and the authorized environment.
Unexpected resets can break stored credentials used by services, tasks, applications, or remote processes.
A specific user may receive different settings from the default domain policy.
Decision cases
On a domain-joined member server, secpol.msc shows a local password value that differs from the domain standard.
The local value does not prove what governs domain users.
Response
Inspect gpresult and the domain password policy before changing the local setting.
Most users share one set of requirements, but one service account behaves differently.
A fine-grained password policy may apply to that identity.
Response
Use Get-ADUserResultantPasswordPolicy and review Password Settings Objects before assuming the domain policy is broken.
A small number of failed sign-ins can cause a long lockout.
The setting may reduce guessing attempts but also creates availability and accidental lockout risk.
Response
Compare the setting with scenario requirements and authorized policy, preserve administrator access, and change only if justified.
A required Windows service runs under a domain account whose password will be updated.
The service may still store the old credential and fail after the password changes.
Response
Document every dependency, coordinate the credential change, update dependent services or tasks, and verify them immediately.
Fictional defensive lab
Step 01
DC-PRACTICE hosts the CYBERSHIELD.LOCAL domain. Morgan is the required administrator, and AppSvc is a required domain service account.
Step 02
Use Server Manager → Tools → Group Policy Management and locate the domain-linked GPO that defines account policy.
Step 03
Navigate to Account Policies → Password Policy and Account Lockout Policy. Record the configured values without changing them.
Step 04
Run Get-ADDefaultDomainPasswordPolicy and compare its output with the values observed in Group Policy Management.
Step 05
Use Get-ADUserResultantPasswordPolicy -Identity AppSvc to determine whether a fine-grained policy changes its effective requirements.
Step 06
After any authorized policy or credential change, verify Morgan can administer the domain and the AppSvc-dependent application still runs.
Common mistakes
The real setting may be coming from domain policy or a fine-grained policy.
Security policy should reflect the scenario and authorized environment, not arbitrary numbers.
A password change can break services, tasks, scripts, or applications that store credentials.
Availability matters. Preserve an authorized recovery path before tightening lockout settings.
The policy you open may not be the effective policy for the target account.
A selected user can receive different settings from the domain default.
Reflection
Question 1
Why can secpol.msc show a value that is not the effective password policy for a domain user?
Question 2
What is the difference between default domain password policy and fine-grained password policy?
Question 3
Why should account lockout threshold, duration, and reset counter be reviewed together?
Question 4
How can a password change break a required service?
Question 5
Why is gpresult useful even when the password settings are being reviewed in Group Policy Management?
Question 6
What should be verified after changing password or lockout policy?
Verification checklist
The correct local or domain policy source was identified.
Domain users are governed by the intended domain password policy.
Any fine-grained password policy is understood and intentional.
Authorized administrators can still sign in.
Required service accounts still run their services.
Required scheduled tasks still authenticate successfully.
Required applications using stored credentials still function.
No unexpected lockouts occurred after the change.
gpresult and domain-policy commands show the expected effective configuration.
Relevant Security and System logs show no new authentication or service failures.
Competition checklist
Identify whether the account is local or domain-based.
Open the correct policy-management tool.
Review Password Policy.
Review Account Lockout Policy.
Use gpresult to understand policy context.
Use net accounts for a quick summary.
Use Get-ADDefaultDomainPasswordPolicy for domain policy.
Check fine-grained password policy when behavior differs by user.
Protect required administrator access.
Check service-account dependencies before password changes.
Avoid arbitrary universal policy values.
Verify authentication and required services after changes.
Next Windows Server lesson
Next, review Defender health, real-time protection, exclusions, detections, security intelligence, scan history, and evidence preservation on Windows Server.