Users get access denied when trying to change their own password

Washington, Candace N 20 Reputation points
2026-08-29T01:10:28.3133333+00:00

Our group policy settings have users change their passwords after a certain amount of time. We (both IT administrators and normal users alike) will get a prompt telling us our password expired and needs to be changed. This is expected behavior, fine. We put in our old password, then type in the new one we want to use. After we press enter, the screen shows the spinning circle for a while then it says access denied. This is also the case if we try to change out password through CTRL+ALT+DEL. I checked the security settings for each account in AD. Based on my research, "SELF" should have "reset password" checked, so I checked it (it was blank before). Still the same issue. I've also made sure none of the accounts had the "user not able to change password" box checked. When I ran "net user <username>," it said that we're able to change our password. I'm not sure what other permissions could possibly be needed.

Windows for business | Windows Server | Directory services | Active Directory
0 comments

1 answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. James Gamble 0 Reputation points
    2026-08-29T01:36:42.4366667+00:00

    Hola Candace,

    I would start by checking the effective permissions on one of the affected user objects in Active Directory.

    "Reset password" and "Change password" are two different AD extended rights. Reset Password is used when an administrator changes another user's password without supplying the existing password. A normal user changing their own password, including through CTRL+ALT+DEL or an expired-password prompt, uses the Change Password extended right instead.

    Microsoft documents the Change Password extended right here.

    The GUID for that right is: ab721a53-1e2f-11d0-9819-00aa0040529b

    For comparison, Reset Password is a separate extended right.

    Since this is happening both during password expiration and through CTRL+ALT+DEL, I would inspect one affected account in AD Users and Computers with Advanced Features enabled, then go to Properties > Security > Advanced and look specifically for Change password permissions involving SELF and Everyone.

    Technically, the "User cannot change password" setting is enforced through ACEs on the security descriptor of the user object. That means an explicit or inherited Deny ACE for Change Password can override an Allow and cause the DC to reject the password-change operation with Access Denied, even if the checkbox in ADUC appears correct.

    You can also verify what AD thinks about the account from PowerShell: Get-ADUser username -Properties CannotChangePassword,PasswordExpired,PasswordLastSet,PasswordNeverExpires | Format-List SamAccountName,CannotChangePassword,PasswordExpired,PasswordLastSet,PasswordNeverExpires

    I would also check which password policy is actually applying to the user: Get-ADUserResultantPasswordPolicy -Identity username | Format-List *

    That is useful because a Fine-Grained Password Policy can override the domain's default password policy for particular users or groups. A policy problem typically produces a password complexity/history-type error rather than an Access Denied error, but it is worth ruling out.

    Because administrators and normal users are both affected, I would also compare the OU placement of the affected accounts. If a Change Password permission was modified on an OU and inherited by its users, that could explain why the issue is widespread.

    A simple test would be to create a temporary user in the default Users container and see whether that account can change its password if it works there but stops working after being moved into the normal OU structure, which strongly points to an inherited ACL or delegation problem.

    If those permissions look normal, could you provide a little more information?

    • Does this affect every domain user, or only users in certain OUs?
    • Can a newly created test user change its password?
    • Does the failure happen on every domain-joined workstation?
    • Do you see any corresponding Security or System events on the domain controller at the exact time of the failure?

    Those details should help determine whether this is an AD object permission issue or whether the request fails later, when the domain controller processes the password change.

    Thanks,

    James

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.