Password policy and FGPP: The difference between password change, reset, history, and lockout

1. Core mechanism

Password change and reset use different authorization requirements. In AD, a user changing their own password must supply the current password and possess User-Change-Password on their own object. A default ACL commonly grants that right, so no separate permission step may be visible; this does not mean authorization is skipped. Reset does not require the old password; the caller needs User-Force-Change-Password (Reset Password) on the target object. On the policy side, there are two layers: Default Domain Password Policy (defined in Group Policy: length, history, min/max age, complexity, lockout), which is unique for each domain, and Fine-Grained Password Policy — a Password Settings Object (PSO, class msDS-PasswordSettings) that can override it for specific users/groups. The limit of this lesson is the change/reset distinction, FGPP precedence/resultant and their relationship with lockout; account states (disable/lockout state) at 08.01, password hash storage details elsewhere. Critical distinction: a change/reset AUDIT record tells you that an action was taken; WHICH policy is applied to a user is a separate inference and is read from a single place (msDS-ResultantPSO).

Interfaces and specifications

• AD password change requires both the current password and User-Change-Password on the user’s own object. Event 4723 records change attempts; do not assume its Failure outcome records a domain account’s wrong-old-password error.
• Password reset attempt: User-Force-Change-Password (Reset Password) control access right, Rights-GUID 00299570-246d-11d0-a768-00aa006e0529; another-account reset attempt is audited as 4724, while the outcome must be read separately.
• Default Domain Password Policy: one per domain; It includes minimum length, password history, min/max age, complexity and Account Lockout Policy subsection (carried over by Group Policy).
• Fine-Grained Password Policy (PSO, msDS-PasswordSettings): overrides domain policy for specific user/global group; Contains the fields msDS-PasswordSettingsPrecedence, msDS-PSOAppliesTo, msDS-Lockout*.
• Resultant policy: evaluate directly assigned user PSOs first; otherwise consider applicable group PSOs. Within the chosen set, the lowest numeric msDS-PasswordSettingsPrecedence (highest priority) wins; objectGUID breaks ties. PSOs are not merged.
• Events 4723 and 4724 share similar Subject/Target fields but their event-specific field sets are not identical. Microsoft’s Version0 example includes PrivilegeList for 4723, while its 4724 example omits that field. Read EventID and outcome separately; inspect the relevant DC for a domain account or computer for a local account.

Change and reset: different permissions

A change operation verifies the current password, but that is not sufficient on its own. The user must also possess User-Change-Password on their own AD object. Default permissions may grant it; if the effective ACL denies the change, knowing the correct password does not override that restriction.

Reset does not require the current password. The caller uses User-Force-Change-Password (Reset Password) on the target user object to assign a new one. This separate right lets a help desk reset a user's password without knowing it; permission to change a password does not grant permission to reset it.

The distinction is not simply 'knowledge or permission': change requires both the current password and Change Password permission; reset requires Reset Password permission. Event 4723 records a change attempt and 4724 a reset attempt; success or failure is assessed separately. The applicable password policy and other operation requirements must also be met.

Two policy layers: domain default and FGPP

Each domain has a single Default Domain Password Policy; Defines minimum length, password history, minimum/maximum age, complexity and Account Lockout Policy. This has historically been a single baseline for all users in the domain.

Fine-Grained Password Policy (FGPP) breaks this uniqueness: you overwhelm the domain policy by creating a Password Settings Object (PSO, msDS-PasswordSettings class) and applying it to specific users or global groups (msDS-PSOAppliesTo). For example, you impose a 20-character minimum and a shorter maximum age on a privileged administrator group, while ordinary users remain at the domain default.

Important limit: FGPP applies to users and global groups, not OUs. If you want an OU-based password policy, you'll need to turn it into a group. This is a different scoping logic than the GPO's linking model to the OU.

Conflict: precedence and resultant PSO

A user may fall under the scope of more than one PSO (for example, both directly and through membership in a group). In this case the policies are NOT combined; A single PSO wins. The winner is determined by msDS-PasswordSettingsPrecedence: the numerically LOWEST precedence value has the highest priority.

The rules are an order of elimination: if there is a PSO applied DIRECTLY to the user, that group will crush their PSO. If there is no direct PSO, the lowest numeric precedence among the applied group PSOs wins. If Precedence is equal, the objectGUID (smallest) of the winning PSO object is used as a tie-break — this is a deterministic but arbitrary rule, with no security implications.

Instead of doing this inference manually, the result is read directly: a user's msDS-ResultantPSO attribute value indicates the only PSO actually applied to that user. 'Which policy applies?' The definitive answer to the question stops here; It is a mistake to guess it by mentally combining more than one PSO.

# Fine-grained password policy (PSO = msDS-PasswordSettings) sample attributes
# Fields visible in ADAC/PowerShell and carried by the msDS-PasswordSettings object:
msDS-PasswordSettingsPrecedence      : 10      # lower number = higher priority
msDS-PasswordReversibleEncryptionEnabled : FALSE
msDS-PasswordHistoryLength           : 24
msDS-MinimumPasswordLength           : 14
msDS-MinimumPasswordAge              : 1.00:00:00     # 1 day
msDS-MaximumPasswordAge              : 60.00:00:00    # 60 days
msDS-LockoutThreshold                : 10
msDS-LockoutObservationWindow        : 0:00:15:00     # 15 minutes
msDS-LockoutDuration                 : 0:00:15:00     # 15 minutes
msDS-PSOAppliesTo                    : CN=PW-Admins,OU=Groups,DC=outreason,DC=example
#
# A user's RESULTANT PSO is read in one place: msDS-ResultantPSO
# (when multiple PSOs apply, the one with the lowest numeric precedence wins; on a tie,
#  the PSO object's objectGUID is the tie-breaker). PSOs inherited from group membership
# are not merged; ONE resultant PSO is selected.

How to associate lockout with password

Account Lockout Policy is a subsection of the password policy and works with three values: lockout threshold (how many failed attempts to lock), lockout duration (how long the lock lasts), and observation/reset window (how long it takes to reset the counter). If FGPP is used, these values ​​come from msDS-Lockout* fields in PSO and overwhelm the domain default.

A wrong current password can fail a change attempt and affect badPwdCount. Treat auditing separately: for a domain account,4771 or 4776 may appear on the DC when the relevant auditing is enabled. Event 4723 Failure is relevant when the new password fails policy. Interpret lockout using the counter, observation/reset window and threshold together, rather than only “consecutive wrong attempts.”

Password history and minimum age constrain rapid reuse on the change path. Do not automatically assume identical behavior for reset: verify whether the password-set interface in use enforces these checks. The MS-ADTS policy-hints control requests history and age enforcement for LDAP password set. A reset validator updating the history list does not establish that it rejected a prior value. Keep three questions separate: which policy was selected, which checks this operation path enforced, and how the operation ended.

State and data flow

1. Choose the operation: change requires User-Change-Password; reset requires User-Force-Change-Password on the target. Evaluate the relevant right separately.
2. On the change path, verify the current password separately. A correct password does not supply a missing right; reset does not ask for the current password.
3. Read the user’s msDS-ResultantPSO; use the domain default if no PSO applies. This example displays one selected policy, without merging PSOs.
4. Evaluate history and minimum age together with the operation path. Checks required for change must be verified separately for the reset interface in use.
5. Read the operation result separately. A granted right or a selected policy alone does not establish that the password changed.
6. Choose the relevant evidence: for a domain account, wrong-old-password evidence may be 4771/4776 depending on auditing; a new-password policy rejection may be 4723 Failure. Inspect counters and lockout state separately.

2. Exploitation

Broken trust assumption

Password knowledge and password-modification authority are separate. Change requires current-password verification and the Change Password right. Reset does not ask for the old password and uses a distinct Reset Password right on the target. Broad delegation spreads this authority across many accounts; assigning a password alone does not establish successful logon. Visibility depends on Audit User Account Management and collection. Access Denied may produce no Failure 4724; event absence does not establish absence of an attempt.

Technical prerequisites

• The attacker has the Reset Password (User-Force-Change-Password) extended right on the target user object directly or with an inherited ACE; If this right is not available, the reset will fail.
• The target account must be enabled and there is no additional control (smartcard-required, disabled) that prevents the logon after the reset; Otherwise, it cannot be logged in even if a password is assigned.
• During a defensive review, verify which policy checks the reset path enforces. Do not treat history and minimum age as identical mandatory gates for every reset interface; history updates and rejection of a historical value are separate behaviors.
• Visibility of a reset attempt depends on Audit User Account Management, the success/failure result, and Security log collection. Not every failed attempt, such as an Access Denied case, necessarily produces a Failure 4724; verify the event coverage in use.

Exploitation mechanism

The risk comes from granting reset authority too broadly or to the wrong principals. Change also includes an authorization check; reset uses the separate User-Force-Change-Password right. The Reset Password right is granted by a control access right ACE in a user object's DACL; A principal with this right can assign a new password and then log in with that identity without knowing the target's current password. This is not a protocol vulnerability, but an intended mis/broad distribution of delegation capability: what is reasonable for a help desk scenario becomes an account-takeover surface when extended to an entire OU or privileged accounts. Change requires the current password as well as User-Change-Password. The risk examined here is which accounts the reset delegation covers. The relevant subtlety in terms of FGPP is that if a weak PSO (short min length, no history) is applied to a particular group, that group is protected by a weaker base than the domain default, and the resulting PSO reveals this in one place; Saying 'domain policy is strong' does not mean that every user is in the strong policy.

Reset right: changing password without password

Reset Password extended right is the ability to assign a new password without knowing the target's current password. Therefore, to whom this right is granted and on which objects is a critical question of authority. A group with this right over all user objects of an OU can practically take over every account in that OU. Audit visibility must be verified separately: relevant auditing and collection are required, and Access Denied may produce no Failure 4724.

This is fundamentally different from change: since change requires the current password, it is limited to someone who 'already knows' it. Reset is pure authority. Mixing the two in the audit — putting 4723 and 4724 in the same 'password changed' box — hides the privilege use signal of the reset.

Weak PSO: strong domain, weak island

FGPP can also apply a WEAKER policy than the domain default to a group of users. Since the PSO with the lowest numeric precedence wins, a poorly configured or malicious low numeric precedence (high priority) PSO can reduce a group below the overall strength of the domain.

That's why claiming 'our password policy is strong' alone is not enough; The resulting PSO of each privileged group must be verified separately. On the attacker's side, a group with weak PSO is a softer target for brute-force or password spraying. Reading the result from msDS-ResultantPSO instead of guessing it closes this blind spot.

Bulk reset and write to PSO: scope and blocking control

The danger of the reset right is not singular but comprehensive: if a principal has the Reset Password right over all user objects of an OU, he can take over every account in that OU, one by one — no existing password is required, only a new password is assigned. The scope limit is important: if this right is not available, the reset will fail and if the target is smartcard-required or disabled, it will not be possible to log in even if a password is assigned. That is, the effect is limited by the 'scope of the right' × 'additional constraints of the target'; The worst possible case is if the right is spread across privileged accounts or a large OU.

A second scope point is the PSO objects themselves: a principal with write privileges to the msDS-PasswordSettings object can create a weak PSO with low precedence and apply it to a group (msDS-PSOAppliesTo), reducing that group's resulting policy below the domain base. This isn't password cracking, it's policy weakening and then makes password spraying easier. Inhibitory control is twofold: Reduce Reset Password delegation to the narrowest set of objects and regular inventory; Password Settings Give write permissions on the container only to trusted administrators and hunt for unexpected/low precedence PSOs. Thus, both the 'passwordless password changing' and 'policy weakening' surfaces are narrowed in scope.

3. Defense & Detection

Telemetry scope

• Events 4723 (change attempt) and 4724 (reset attempt for another account) have similar field shapes but track different authorization models. Collapsing them into one generic 'password changed' category loses the privilege-use signal in 4724 and the distinction between attempt and result.
• Both events are linked to the Audit User Account Management subcategory and are generated on the computer where the operation occurs (relevant DC for the domain account, member server/client for the local account); Does not require SACL, this subcategory should be clear.
• Subject != Target in event 4724 indicates a password-reset attempt for another account; read the success/failure result as well. Subject == Target is the typical self-service change pattern for event 4723.
• 'What policy is being implemented?' question is read from the msDS-ResultantPSO attribute, not from an event; The audit log shows that the transaction was made, not the policy applied.
• When examining the FGPP scope, the msDS-PSOAppliesTo and msDS-PasswordSettingsPrecedence values ​​of individual PSOs are read collectively; but a user's actual result is always the resultant PSO, not the mental combination of the PSO list.

Events and relevant fields

• 4723 / SubjectUserSid == TargetSid is consistent with a password-change attempt for the caller’s own account. Matching SIDs alone do not establish that the password changed or the old password was validated; inspect the success/failure outcome and authentication context separately.
• 4724 / SubjectUserSid != TargetSid: a reset attempt for another account. Read the success/failure result separately; an attempt record alone does not prove the password changed.
• 4724 / TargetSid: is the persistent ID of the reset account; Resets on privileged accounts are reviewed first because they may be a takeover route.
• Wrong old password for a domain account:4771/4776 may appear on the DC if the relevant auditing is enabled; do not search only for 4723 Failure. Event 4723 Failure may indicate new-password policy rejection. badPwdCount, observation window and threshold are separate lockout evidence.
• 4724 / SubjectLogonId: identifies the session that performed the reset; The same Subject resetting many accounts in a short time (mass reset) may be a sign of delegation abuse or campaigning.

Separate transaction trail from policy question

The first question is 'what was attempted?': 4723 records a change attempt, while 4724 records a reset attempt for another account. The Subject/Target relationship helps confirm that distinction; read the event's success/failure result separately. The second question is 'which password policy applies?'—an audit event cannot answer that; the msDS-ResultantPSO directory attribute does.

Maintaining this distinction prevents two errors: missing the privilege signal by mistaking the reset (4724) for an ordinary 'password changed', and guessing a user's password policy by mentally combining the PSO list. The transaction trace is read from the event and the policy result is read from the attribute.

Question                    Evidence
--------------------------  -----------------------------------------
Change or reset attempt?    4723 / 4724; outcome and Subject/Target context
Required authorization?     Change: User-Change-Password + current password
                            Reset: User-Force-Change-Password
Applicable policy?          msDS-ResultantPSO; otherwise domain default
PSO selection tie?          precedence, then objectGUID

Don't guess Resultant PSO, read it

When a user is covered by multiple PSOs, the only policy applied is the resultant PSO, which must be read from the msDS-ResultantPSO attribute rather than guessing. Directly applied PSO crushes group PSOs; lowest numeric precedence among group PSOs wins; In case of equality, objectGUID becomes a tie-break.

This deterministic rule involves a 'predictable but arbitrary' tie-break for security: objectGUID ranking is not an indicator of strength, it just makes the decision deterministic. So relying on precedence equality is fragile; Assigning a single powerful PSO to privileged groups with clear, low precedence eliminates conflict ambiguity from the outset.

Detection logic · Sigma

title: Password reset attempts (4724) - for another account
status: experimental
description: >
  Observes reset attempts for another account through 4724; interpret Subject/Target
  and the success/failure result separately.
logsource:
  product: windows
  service: security
detection:
  reset_attempt:
    EventID: 4724
  condition: reset_attempt
fields:
  - EventID
  - SubjectUserName
  - SubjectUserSid
  - TargetUserName
  - TargetSid
  - Keywords           # System/Keywords carries Audit Success or Audit Failure
falsepositives:
  - A legitimate reset attempt by an authorized help desk or administrator
level: medium

Query assumptions

• Sigma logsource assumes windows/security channel; The choice of 4724 does not say 'bad' on its own, it brings the use of privilege to the point of observation. Subject != Target inference requires a backend join/field comparison; the raw EventID filter does not do this.
• This rule cannot see which password policy is applied; The policy question is read from msDS-ResultantPSO, not from the event.
• 4723/4724 is generated in the relevant DC in the domain account process; If there are multiple DCs and Security logs are not centralized, resets may be missing.
• This selection was not run on a live system; Validated selectability of fields (EventID, Subject*, Target*) on synthetic 4723/4724 samples of this course only.
• This is an educational selection example. No Sigma parser/backend validation was performed; it is not claimed as an executed production rule.

False positives

• Legitimate help-desk or administrator reset attempts produce 4724; prioritize using target importance, operator context, and volume patterns.
• A legitimate help-desk reset attempt for another account also produces 4724; Subject != Target is expected for this normal operation and does not alone show malicious intent.
• Negative example: an attacker who knows the current password will do change (4723) instead of reset and this will not fall into the filter at all; reset-driven selection is a scope limit, it does not cover the entire password-based takeover.

Hardening

• Keep Reset Password (User-Force-Change-Password) delegation to the narrowest scope; Grant the right only to the required help desk group and required objects, not to the entire OU or privileged accounts. Regularly inventory and verify delegation.
• Process change (4723) and reset (4724) attempts separately; prioritize resets for another account (Subject != Target) with target/operator context rather than labeling them malicious on that condition alone.
• Implement a hardened FGPP (high min length, reasonable history, reasonable max age, appropriate lockout) for privileged groups and verify the msDS-ResultantPSO of each privileged account; Don't rely on the 'domain default strong' assumption.
• Hunt for weak or unexpected PSOs: a PSO with low precedence, short min length or history=0 can take a group below the domain base. Review PSO inventory with msDS-PSOAppliesTo.
• Evaluate history and minimum age together for change. For authorized reset tools, verify whether the interface actually enforces history/age checks; reading the resultant PSO alone does not prove that enforcement.
• Verification step: attempt a change and a reset on a test account, then inspect EventID, Subject/Target, and success/failure fields in 4723/4724; separately confirm the target user's resultant PSO. Audit User Account Management must be enabled and the logs collected.

Read the examples

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-a5ba-3e3b0328c30d}" />
    <EventID>4723</EventID>
    <Version>0</Version>
    <Level>0</Level>
    <Task>13824</Task>
    <Opcode>0</Opcode>
    <Keywords>0x8020000000000000</Keywords>
    <TimeCreated SystemTime="2026-09-29T09:03:11.5540000Z" />
    <EventRecordID>91344</EventRecordID>
    <Correlation />
    <Execution ProcessID="724" ThreadID="3980" />
    <Channel>Security</Channel>
    <Computer>DC01.outreason.example</Computer>
    <Security />
  </System>
  <EventData>
    <Data Name="TargetUserName">kaan</Data>
    <Data Name="TargetDomainName">OUTREASON</Data>
    <Data Name="TargetSid">S-1-5-21-3623811015-3361044348-30300820-1201</Data>
    <Data Name="SubjectUserSid">S-1-5-21-3623811015-3361044348-30300820-1201</Data>
    <Data Name="SubjectUserName">kaan</Data>
    <Data Name="SubjectDomainName">OUTREASON</Data>
    <Data Name="SubjectLogonId">0x4a2b7</Data>
  </EventData>
</Event>

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-a5ba-3e3b0328c30d}" />
    <EventID>4724</EventID>
    <Version>0</Version>
    <Level>0</Level>
    <Task>13824</Task>
    <Opcode>0</Opcode>
    <Keywords>0x8020000000000000</Keywords>
    <TimeCreated SystemTime="2026-09-29T09:07:48.9120000Z" />
    <EventRecordID>91352</EventRecordID>
    <Correlation />
    <Execution ProcessID="724" ThreadID="3980" />
    <Channel>Security</Channel>
    <Computer>DC01.outreason.example</Computer>
    <Security />
  </System>
  <EventData>
    <Data Name="TargetUserName">kaan</Data>
    <Data Name="TargetDomainName">OUTREASON</Data>
    <Data Name="TargetSid">S-1-5-21-3623811015-3361044348-30300820-1201</Data>
    <Data Name="SubjectUserSid">S-1-5-21-3623811015-3361044348-30300820-1105</Data>
    <Data Name="SubjectUserName">helpdesk.ops</Data>
    <Data Name="SubjectDomainName">OUTREASON</Data>
    <Data Name="SubjectLogonId">0x3e9f1</Data>
  </EventData>
</Event>

Two reality checks

Assumption: In order to change someone's password, you must first know that password.

In fact: No. This is only true for 'change' (4723); change requires the current password. 'Reset' (4724) does not require the current password at all: a principal with the Reset Password (User-Force-Change-Password) extended right on the target user object assigns a new password without knowing the current password. Therefore, 'knowing' and 'changing' a user's password are two separate abilities; The latter is an ACL right and a widely distributed reset delegation is a broad account-control risk.

Assumption: If the domain's password policy is strong, every user is protected by that strong policy.

In fact: No. Fine-Grained Password Policy (PSO) can apply a different — or even WEAKER — policy than the domain default to specific users or global groups, crushing a low numeric precedence (high priority) PSO domain base. Additionally, PSOs are not merged; If a user is covered by more than one PSO, only the one with the lowest numeric precedence (objectGUID tie-break in the equation) is applied. Which policy a user is actually in is found by reading PSOs from one place — msDS-ResultantPSO — rather than by combining them with prediction.

Sources

• Microsoft · 4723(S, F) An attempt was made to change an account's password
  Event XML (Version 0); change operation requiring the current password; Subject/Target fields; Audit User Account Management; can be generated on domain controllers, member servers, and clients (on the computer where the operation occurs).
• Microsoft · 4724(S, F) An attempt was made to reset an account's password
  Event XML (Version 0); reset not requiring the current password and depending on the Reset Password right; Subject != Target pattern; can be generated on domain controllers, member servers, and clients (on the computer where the operation occurs).
• Microsoft · User-Force-Change-Password extended right (AD Schema)
  CN User-Force-Change-Password, Display-Name 'Reset Password', Rights-GUID 00299570-246d-11d0-a768-00aa006e0529; 'Permits resetting a password on a user account.'
• Microsoft · Fine-grained password policies (AD DS)
  PSO (msDS-PasswordSettings) applies to users and global groups (not OUs); lowest numeric precedence wins; objectGUID on tie; result is msDS-ResultantPSO.
• Microsoft · Password Policy (security policy settings)
  Default Domain Password Policy components: minimum length, password history, min/max age, complexity; one policy per domain.
• Microsoft · Account lockout threshold (security policy setting)
  Relationship among lockout threshold/duration/observation window; context that msDS-Lockout* fields override the domain default when FGPP is used.
• Microsoft Open Specifications · [MS-ADTS] unicodePwd
  §3.1.1.3.1.5.1: current password and User-Change-Password for change; User-Force-Change-Password for reset.
• Microsoft Open Specifications · General Password Policy
  §3.1.1.7.1: history/minimum-age enforcement depends on change versus password-set path.
• Microsoft Open Specifications · LDAP_SERVER_POLICY_HINTS_OID
  §3.1.1.3.4.1.27: requested history/age enforcement during password set.
• Microsoft Open Specifications · SamValidatePasswordReset
  §3.1.5.13.7.3: history update is not a history-match rejection.
• Microsoft Open Specifications · SamValidatePasswordChange
  §3.1.5.13.7.2: wrong-password counter and observation window.
• Microsoft Open Specifications · msDS-ResultantPSO
  §3.1.1.4.5.36: direct user policy first; lower numeric precedence, then objectGUID.