Apologies if I did not find a question similar to mine but i have searched honest!

Firstly we have undertaken a no default group approach to our security on active directory. This has been very successful. However we have a bug bear that is causing all senior admins on site frustration in that they need to ask another admin to change their passwords for them. This is not an ideal we would like and wondered if anyone else had come against the same issue.

Key information here is we are using terminal services to remote the DC's and use the users and computers snap in on the server to reset passwords.

In addition I have also discovered that placing the user in the Enterprise Admins group allows the password change to occur. But I cannot for the life of me workout what acl/dacl to add/change in order to make our groups operate without the Enterprise admin role added to the user.

  • Are these admins able to change their own passwords if they RDP into a DC and do Ctrl+Alt+End > Change a password ? – BlueCompute Jul 16 '14 at 10:54
  • Firstly we have undertaken a no default group approach to our security on active directory - What does that mean exactly? However we have a bug bear that is causing all senior admins on site frustration in that they need to ask another admin to change their passwords for them - Are these accounts used solely for administration? These are not their every day user accounts are they? – joeqwerty Jul 16 '14 at 13:56
  • yes these account are soley for admin. - joeqwerty – Robert Jul 17 '14 at 13:11

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:

Account Operators
Backup Operators
Domain Admins
Domain Controllers
Enterprise Admins
Print Operators
Read-only Domain Controllers
Schema Admins
Server Operators

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:

  1. Open ADUC (dsa.msc)
  2. Find the user account in question and select Properties
  3. Go to the "Account" tab
  4. Check the "User cannot change password" box
  5. Click "Apply"
  6. Uncheck the "User cannot change password" box
  7. 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

| improve this answer | |
  • Interesting information no doubt. But in investigating this lot I find that the OU container although set to inherit from parent and the security affects this objects and all decendant objects. Although none of the user accounts appear to have changed to reflect this.... – Robert Jul 17 '14 at 13:09
  • further investigation now required. I shall update as soon as I can. – Robert Jul 17 '14 at 13:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.