Hello all, Eric here again. Just recently I was helping one of my customers with some ADRAP remediation efforts. One of the items that they requested some guidance on was creating a delegation plan to put in place so that they could remove a number of users from the default administrative groups. They had a few groups nested into these groups, one example being the Help Desk group, that was nested into the Administrators group.
Anyhow, after coming up with a plan, we put the delegations in place and then removed the users that didn’t need to be in the administrative groups. I also mentioned some of the issues that they might see regarding the possible inability of their Help Desk group members to administer one another, as well as the newly delegated OU admins to be able to administer the Help Desk group members. I briefly explained how AdminSDHolder worked and sent them this KB article (http://support.microsoft.com/kb/817433) to further explain workarounds since the hotfix didn’t apply to them (they were 2K3 post SP1). Sure enough a few days later they had some issues and we fixed them based on the article, however they also mentioned that the fix still didn’t allow their Help Desk group members to unlock their Domain Admin accounts. I told them that it was like that by design, but that if they followed workaround Method 3 in the KB article that I sent, then they could fix that. They wanted the Help Desk group to only be able to unlock locked Domain Admins and that’s it. I sent them the KB article ( http://support.microsoft.com/kb/279723 ) with instructions for delegating the rights to unlock accounts and said that we should just need to apply those permissions to the AdminSDHolder container and we should be all set. I said that I’d test it in my lab and get back with them.
In setting up my lab to test, I simply created a “Help Desk” group and delegated that group Full Control over an OU that contained a user that was in the “Administrators” group in the domain. Of course, by design, they should not be able to administer that protected user because protected accounts don’t inherit permissions. To meet their requirements, all I should have needed to do was open up DSA.msc, turn on Advanced Features, navigate to the AdminSDHolder container ( CN=AdminSDHolder,CN=System,DC=Domain,DC=Com ), go to the Permissions Tab in Advanced Security, and set the Help Desk group to be able to read and write the LockOutTime attribute. So I did that, an since I didn’t want to potentially wait an hour for SDProp to run, I set the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNTDSParameters AdminSDProtectFrequency REG_DWord key to a value of 60 (number of seconds), so that it would run every minute. You don’t want to do that in a production environment, this was just for my testing purposes.
Note: To force SDProp to run immediately there’s another method for kicking off the process, without making changes to the registry. To kick it off on command, follow these steps after making a change that you want propagated:
In LDP click Browse choose Modify and leave the DN blank.
Type FixUpInheritance for the attribute.
Type Yes for the Value.
Click Enter
Click Run
So I made the registry change, and then about a minute or so later, I checked the protected user to see if the permissions changes that I just applied to the AdminSDHolder container had propagated to that user as of yet. They did. The next thing that I did was open up an RDP session to try to log in as the protected account, putting in bad passwords until it locked out. After that I opened up DSA.msc, running as a user that is in the Help Desk group; since that user should now be able to unlock the protected account. I navigated to the locked out account, but much to my surprise, the option was grayed out. Below to the left you can see that the permissions are in place on the Protected User, but to the right, that the option to unlock the account is grayed out:
OK, so I ran through the same process on another OU, delegating only the unlock account right. I locked out a user in the new OU, and then checked to see if my Help Desk user was able to unlock the account. I took a look and it worked just fine, the only administrative option that I could do was to unlock the account, as expected. After that, I wasn’t sure what the issue was, so I did more testing. This time I gave the Help Desk group “Full Control” over the AdminSDHolder container. A minute later, the permission changes propagated, but this time, the Help Desk user could do whatever he wanted to on the protected account. I then removed “Full Control”, and just gave the Help Desk group “Write” permissions. This too worked, but it still gave the helpdesk too many rights. When trying the original “unlock” permissions again, that still failed to work. I tried this in a couple of other 2003 domains as well with the same result.
After a fair amount of research and testing, I found a method that finally worked. In the end, I used LDP to make the exact same permissions changes, and that’s what did the trick. The version of LDP that came with 2003 R2 did not work however. I had to use the 2003 R2 LDP version that came with ADAM, and that’s what did it. Once you get a copy of that version of LDP, follow the instructions below:
1. Open ldp.exe that is saved to the Desktop of the DC
a. Press CTRL+B
b. Press CTRL+T
2. Navigate to the AdminSDHolder container under System.
3. At the top, select Browse, choose Security –> Security Descriptor
a. Since the AdminSDHolder container should already be selected, the DN path should be displayed in the box that pops up, if it’s not, fill it in – ( CN=AdminSDHolder,CN=System,DC=Domain,DC=Com )
b Click OK
4. The Security Descriptor Window for the AdminSDHolder container will pop up.
5. Normally you would choose, Add ACE, and add the required permissions, but since I have already added the ACE from DSA.msc, we’ll merely need to click Edit ACE, click OK without making any changes, and then choose Update.
6. After that, we wait for SDProp to run again to update the “new” permissions, and then check to see if we can perform the delegated permissions on the protected accounts.
After going back and opening DSA.msc as my Help Desk user, I’m finally allowed to unlock the protected account…
