Users get access denied when trying to change their own password

Question

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.

Answer 1

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.

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

Answer 2

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