You've encountered the power and annoyance of the Security Descriptor Propagator (SDPROP).
To secure "critical objects", Active Directory tries to keep track of all objects that are a member of one or more protected groups. These include:
Read-only Domain Controllers
All accounts that are members of these groups will automatically have an attribute called
AdminCount set to a value of
1 - and if you unset this attribute while a user is still a member of one of the protected groups it will reemerge shortly.
The aim is to make sure that these objects cannot have their object ACL screwed so much over that they "break" functionally (try to imagine an evil co-Domain Admin who tries to strip you of all your own rights on your admin account).
To maintain the critical objects' ACLs, a reference object called
AdminSDHolder exists in all Active Directory Default Naming Context partitions.
On a fixed interval, SDPROP calls the
FixUpInheritance routine on the local DSA. The
FixUpInheritance routine, among other things, examines all objects for the attribute
AdminCount and applies the ACL of the reference object called
AdminSDHolder to the critical objects.
This ACL-"fix" has the annoying side effect of stripping user accounts of the "Change Password" permission, due to the way this particular permission is implemented, unless the account itself is already authenticated and has Enterprise Admin group membership.
The Active Directory Users and Computers mmc might even show the "User cannot change password" option as unchecked, even though it still doesn't work on its own.
To test whether this is the in fact what is going on, try the following:
- Open ADUC (
- Find the user account in question and select Properties
- Go to the "Account" tab
- Check the "User cannot change password" box
- Click "Apply"
- Uncheck the "User cannot change password" box
- Click "OK"
Now test that the user can actually change his password.
To test that SDPROP is actually the cause of this behavior, force the
FixUpInheritance routine to run (here using PowerShell):
$RootDSE = [ADSI]"LDAP://RootDSE"
Make sure your run this command with administrative credentials
If the user is no longer able to change the password after running
FixUpInheritance, SDPROP is the culprit.
In any case, the real problem here is the practice of treating regular accounts and privileged accounts equally.
Everyone who has administrative privileges, like membership of any protected group, should maintain 2 accounts - one regular, without any protected group memberships - and an admin account for doing admin-work and nothing else.
Read more about this routine and it's sometimes bizarre effect here:
AdminSDHolder, Protected Groups and SDPROP - TechNet Magazine 2009