Users get access denied when trying to change their own password

Question

Users get access denied when trying to change their own password

Washington, Candace N 20

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.

0 comments

1 answer

Your answer

Answer 1

James Gamble 0

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

Washington, Candace N 20 Reputation points

2026-08-31T16:39:27.86+00:00

According to the provided powershell command, the CannotChangePassword value is set to false. The Get-ADUserResultantPasswordPolicy command doesn't return anything. The effective policy says the users should be able to change their password. I tried making a test user in the Users group and I'm still unable to change the password. I'll have to go back the check for system events in the event log on the domain controller, but this issue occurs regardless of OU and on new accounts created.
James Gamble 0 Reputation points

2026-08-31T18:54:17.01+00:00
Hola Candace,

Since CannotChangePassword is False and a brand-new account in the default Users container has the same problem, I would move the OU-specific ACL theory much lower on the list.

Also, Get-ADUserResultantPasswordPolicy returning nothing is not necessarily a problem. That cmdlet returns a Fine-Grained Password Policy if one applies to the user. If you are only using the normal domain password policy, a null result is expected.

At this point, I would try to separate a Windows UI problem from a domain-controller-side password change problem. You can do that by changing a test account's password through the AD PowerShell module while supplying both the old and new passwords:

$OldPassword = Read-Host "Old password" -AsSecureString; $NewPassword = Read-Host "New password" -AsSecureString; Set-ADAccountPassword -Identity testuser -OldPassword $OldPassword -NewPassword $NewPassword

Using -OldPassword is important. That tells AD this is a user password change, not an administrative reset, so it follows essentially the same authorization path that CTRL+ALT+DEL should use.

If that also returns Access Denied, I would start looking at the domain controllers rather than the workstation. If you have more than one DC, it would also be worth repeating the test against each DC explicitly with -Server DCName. If one succeeds and another fails, that gives us a much narrower problem to chase.

A domain controller processes a normal password change, and Windows commonly uses the Kerberos password-change service for domain password changes. The client, therefore, needs to be able to locate and communicate with a writable DC, and that DC has to authorize and process the change correctly.

Microsoft has a useful overview of the password-change mechanisms here.

I would definitely check the DC event logs next, preferably while reproducing the failure with a test account. Event ID 4723 in the Security log is particularly relevant because it records an attempt by an account to change its own password.

If you can, let us know:

How many writable domain controllers do you have?

Whether Set-ADAccountPassword with -OldPassword fails the same way.

Whether it succeeds when explicitly pointed at any particular DC.

What Security/System events are generated on the DC at the exact time of the failure?

At this point, those results should tell us whether we are dealing with a domain-wide authorization issue, a specific DC, or something earlier in the password-change path.

Thanks,

James
Washington, Candace N 20 Reputation points

2026-09-14T14:43:15.1833333+00:00

Running the powershell command on the domain controller (we only have one for now) worked without issue, and Event ID 4723 appeared in the domain controller's security event log. All the times I tried it on the workstation through CTRL+ALT+DEL, it never appeared. On the workstation, I did see some audit failures, but I'm not sure if they're relevant.

C:\Windows\System32\wlrmdr.exe
-c -s 0 -f 0 -t Empty -m Empty -a 0 -u Empty

Security Account Manager EventID 4673
SeTcbPrivilege

Window Manager\DWM-15
SeAssignPrimaryTokenPrivilege
SeAuditPrivilege
SeImpersonatePrivilege
James Gamble 0 Reputation points

2026-09-16T18:32:39.18+00:00

Hola Candace,

Since Set-ADAccountPassword works when run on the domain controller and generates Event ID 4723 there, the domain controller is clearly capable of processing a normal self-service password change for that account. Microsoft documents 4723 as the event generated when a user attempts to change their own password. :contentReference[oaicite:0]{index=0}

The fact that CTRL+ALT+DEL attempts from the workstation never generate 4723 on the DC strongly suggests the password-change request isn’t actually reaching the domain controller. That moves this away from an AD ACL/password-policy problem and toward the workstation-to-DC path.

The 4673 events you found for wlrmdr.exe and DWM are probably noise. Event 4673 records use of sensitive privileges such as SeTcbPrivilege, SeAssignPrimaryTokenPrivilege, SeAuditPrivilege, and SeImpersonatePrivilege. Those are common Windows security auditing events for system processes and don’t specifically indicate a password-change failure.

At this point, I’d check whether the workstation can reach the Kerberos password-change service on the DC. Domain password changes commonly use the Kerberos kpasswd service over TCP/UDP 464.

From an affected workstation, try:

Test-NetConnection <DC-FQDN> -Port 464

I’d also verify the workstation is locating the expected DC:

nltest /dsgetdc:<yourdomain>

And then check Kerberos/DC communication:

klist purge

klist get krbtgt/<yourdomain>

If TCP 464 fails, that would fit the symptoms very well: normal domain logon can still work, but CTRL+ALT+DEL password changes fail before the DC ever logs Event 4723.

If 464 is reachable, the next thing I’d look at is a packet capture from the workstation during one failed password-change attempt. That should tell us whether the client is attempting Kerberos password change traffic at all, whether it’s going to the correct DC, and whether anything is being rejected or dropped before it reaches LSASS on the DC.

Microsoft’s documentation on the password change flow is useful here.

Thanks,

James