SDProp and Password changes for Domain Admins (and other Protected Group members)

Problem: Domain Admins (and other Protected Group members) can’t set their own password

User accounts that are members of Protected Groups, such as Domain Admins, have their Access Controls Lists (ACLs) set to match the ACL of the AdminSDHolder object every 60 minutes (reference: https://technet.microsoft.com/en-us/magazine/2009.09.sdadminholder.aspx).

Because of this, those User accounts are not able to change their own password when either…

• The password expires

Or

• They press ctrl+alt+del and select the “change password” option

…because the Security Description Propagator (SDPROP) removes those permissions every time it runs and matches the User’s ACL to AdminSDHolder.

More Details:

When SDProp Runs, a lot of things happen (Microsoft and other sources are going to be much better for info), but a couple of things happen that are directly related to the problem described above.  I’m going to do my best to explain them below.

To start, I went into ADUC, into the Properties of my Domain Admin account, and flipped the “User cannot change password” checkbox on (applied changes) and off again (applied changes).  This will put my Domain Admin user account into a state where it can change its own password in the two scenarios that are mentioned in the “Problem” section of this document.

After you do that (and before SDProp runs again at its’ regular 60min interval…timing may be tough here), if you go to the Security Tab, you will notice that “Everyone” is granted the “Change password” permissions.  Now, you may be thinking to yourself – “Everyone?  That can’t be right.”  Well, it is.  This is a default entry (for objects that aren’t protected by SDAdminHolder):

The Everyone group has Change Password permissions on all computer and user objects so that unauthenticated or “anonymous” users or computers are able to change their passwords when they expire without having to be authenticated first. If the anonymous user is denied the ability to change passwords, the user would be unable to change the password without logging on. (https://support.microsoft.com/en-us/kb/242795)

Things would obviously be at a stand-still if a user with an expired password needed to log in before they were allowed to set a new password.

However, if you wait for SDProp to run (or force it as in screenshot below- reference end of article instructions using LDP.exe: https://technet.microsoft.com/en-us/magazine/2009.09.sdadminholder.aspx ) and wait for it to complete…

…SDProp removes the “Change Password” permission that’s assigned to “Everyone”

Proving that granting “Everyone” the “Change password” permission is all it takes:

Now that my Domain Admin account has been modified by SDProp and is unable to change its own password, let’s forget about flipping the “User cannot change password” setting.  We want to confirm that granting “Everyone” the “Change password” permission is all it takes, and there’s nothing else happening that’s preventing the change.  So just go right to the Security ACLs.  Click “Advanced” and then “Add…” search for “Everyone” and click “OK”

In the new Permission Entries that apply to “Everyone”, Scroll down until you see “Change password”, check the “allow” box, and click OK.

With that set, you will see “Everyone” has been granted the “Change Password” permission on the Security Tab for this User account.  And you can successfully log on as that user, press CTRL+ALT+DEL, and choose the “Change password” option.

Now the remaining question is – what should be done, if anything, to allow a Domain Admin (or another user account that is a member of a Protect Group) the ability to change their password without asking another Domain Admin to fix the ACL so that they are (temporarily) allowed to do it?

I haven’t seen a lot of good recommendations on solving this problem (or is it a problem?  there is good reason for SDProp to protect these accounts…).  Everything I can think of is a little “hacky”.  There should be a widely accepted fix for this.  I would be hesitant to implement any fix that’s really unique to one particular environment, because I’m concerned about ongoing supportability, and the fact that, eventually, someone else will be responsible for managing the environment and they won’t be familiar with it.