I recently had a customer who had an issue which is by design, but not well known to every AD Administrator. So I decided to summarize some info about it.
Symptom
Usually you delegate permission in Active Directory via OUs. Those permissions apply (if configured so) to objects like users underneath that OU. However you may experience that they don’t apply to all user-accounts (e.g. a delegated admin is able to change the phonenumber for most users, but not on a few others), or that the permissions are being reset/lost on some accounts. If you look at the permissions of that user-account you’ll find that the accounts security-descriptor is set not to inherit permissions from parent objects. If you set the security-descriptor to inherit permissions again, you’ll see that this will be reset after a while. If you configure permissions directly on the object they will be reset after a while as well.
Usually you delegate permission in Active Directory via OUs. Those permissions apply (if configured so) to objects like users underneath that OU. However you may experience that they don’t apply to all user-accounts (e.g. a delegated admin is able to change the phonenumber for most users, but not on a few others), or that the permissions are being reset/lost on some accounts. If you look at the permissions of that user-account you’ll find that the accounts security-descriptor is set not to inherit permissions from parent objects. If you set the security-descriptor to inherit permissions again, you’ll see that this will be reset after a while. If you configure permissions directly on the object they will be reset after a while as well.
Reason
Active Directory protects certain accounts not to inherit delegated permission. This behavior applies to direct and nested members of the following security-groups:
Windows 2000 SP3:
Enterprise Admins
Schema Admins
Domain Admins
Administrators
Windows 2000 SP4 oder Windows Server 2003 additional:
Account Operators
Server Operators
Print Operators
Backup Operators
Cert Publishers
Additional the accounts Administrator and krbtgt are protected.
Why are those accounts protected?
Delegation via AD permissions is usually used to delegate administrative rights to regular user-accounts, to implement administrative roles like Site-Administrator. Those might be assigned to reset passwords, deactivate accounts or other tasks. The AdminSdHolder-Thread assures that such an administrative roles gains not more permissions or is able to compromise the privileged accounts.
How are those accounts protected?
The AdminSdHolder/Ds Propagator tread modifies all accounts which are direct or nested members of one of those groups and increases the attribut adminCount to a value higher than 0. This thread runs once an hour on the Domaincontroller holding the PDC-Emulator role. The thread further resets the security-descriptor of those accounts with the default permissions for administrative accounts which is defined by the security-descriptor of the object cn=AdminSdHolder,cn=System,dc=yourdomain,dc=com. This also resets the flag to disable inheritance of parent objects.
The AdminSdHolder/Ds Propagator tread modifies all accounts which are direct or nested members of one of those groups and increases the attribut adminCount to a value higher than 0. This thread runs once an hour on the Domaincontroller holding the PDC-Emulator role. The thread further resets the security-descriptor of those accounts with the default permissions for administrative accounts which is defined by the security-descriptor of the object cn=AdminSdHolder,cn=System,dc=yourdomain,dc=com. This also resets the flag to disable inheritance of parent objects.
But what can I do if I need different permissions?
If you need different permissions on those accounts there are a few approaches you can take:
- Usually you should avoid using administrative accounts for the daily routine. Use a regular user-account, and just start administrative applications (such as Active Directory-Users and -Computers) with administrative credentials (via RunAs or Context-Menu, Open with…).
Active Directory enabled applications or Site-Admins would be able to change the regular user-account of the Administrators, which is usually sufficient, but their administrative accounts are protected. This protects the Administrator from administrative errors of delegated administrators, and he’s further protected against virusses/worms when surfing the web/reading e-mail.
- You could use a domain-admin account for AD-enabled applications: This would be a solution, but should be avoided whenever possible. It’s quite easy to delegate AD-integrated applications only write-permissions to the attributes they need, so use that feature to protect your AD. Many times those applications only need permissions to add/modify/delete objects which are defined by their schema extension, and write-permissions on attributes on existing objects their schema extension also added.
- If absolutely necessary you are able to change the default permissions on administrative accounts to reflect the need of those applications. You can easily do this by modifying the permissions on cn=AdminSdHolder,cn=System,dc=yourdomain,dc=com. This can be accomblished using ADSIEdit.msc or DsAcls.exe. DsAcls is a commandline-tool for modifying AD-permissions, which every administrator who delegates rights in AD should know. Be sure to test in advance which attributes of which objects are being modifies by the application.
What else is important to know?
- AdminSdHolder also applies the permissions to accounts which are nested members through distribution groups. E.g. if User1 is a member of the distribution group Maillist-KnowHow, which is a member of account operators, then User1 is considered as one of the protected accounts (since the distribution group could be converted to a security group).
Be aware that the command whoami /all does show nested group memberships, but not nested groups through distribution groups.
Usually you should avoid nesting distribution groups in one of the protected groups.
- Users, which are removed out of one of the protected groups (or their nested groups) do not inherit permissions from parent objects. You need to check the box to inherit permissions when removing those users out of the group manually, or use a script to check your users.
- If you have many accounts which are protected by the AdminSdHolder/DS Propagation-Thread, you might notice that the lsass-process on the Domaincontrller holding the PDC-Emultor raises to 100% once an hour. Therefore you should avoid putting loads of users in the protected groups, and rather use delegated administration whenever possible.
- Depending on your need you might want to remove Backup Operators, Printer Operators, Server Operators or Account Operators out of the AdminSdHolder protection. You can get a Hotfix at Microsoft PSS which allows to configure that. See the following KB for more informations on that:
http://support.microsoft.com?id=817433
Hi Ulf,
tja, wir sind da auch gerade reingelaufen! Bestimmte User hatten das "inheritance" flag nicht gesetzt und auch die Rechte der OU nicht übernommen. Wir haben ein VBScript geschrieben, dass das Inheritance-Flag wieder setzt, aber nach einer Weile war das Flag wieder verloren und die Rechte nicht so, wie sie sein sollten. Zuerst kam ich nicht auf den "SDProp" threat, weil die betroffenen User keine besonderen sind und auch keine DIREKTE Mitgliedschaft in einer der geschützten Gruppen haben.
Die Frage konzentrierte sich dann darauf: wie bekomme ich eine vollständige Liste aller direkten UND indirekten Gruppenmitgleidschaften? Ich habe hier den Group Policy Modelling Wizard laufen lassen, der dir u.a. auch eine vollständige Liste all dieser Gruppen ausgibt. Und siehe da: die betroffenen User waren alle indirekte Mitglieder in "Account Operators", was bei einigen gar nicht der Fall sein sollte. Für die anderen Fälle haben wir es so gelöst, dass wir die entsprechenden Rechte auf dem "AdminSDHolder" Container gesetzt haben.
Viele Grüsse…Stefan
Excellent blog post. In short, to resolve this issue on the user object which cannot be managed by the delegated user account, you need to; Right-click the object, click Properties, and then click the Security tab (Advanced) Check the option, "Allow Inheritable Permission from Parent".
Note: It may take at least an hour for the changes to be propogated from the PDC as defined on HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\AdminSDProtectFrequency
This behavior is to protect the "protected groups" in AD like those who are member for Domain Admins or Bulit-in Groups.
Good day,
Mohammed Athif Khaleel
MVP – SUS / WSUS
I Blog on http://msmvps.com/athif/
Hi Athif,
thanks for the feedback. To clarify, the procedure you described is for the issue mentioned in my blog under "What else is important to know", Number 2:
<i>"Users, which are removed out of one of the protected groups (or their nested groups) do not inherit permissions from parent objects. You need to check the box to inherit permissions when removing those users out of the group manually, or use a script to check your users."</i>
It will not work on users which are still in one of the protected group – there it will be reset after one hour again.
There’s also a script in http://support.microsoft.com/kb/817433 underneath "Workaround, Method 1" which does enable the inheritance on all users in a domain with admincount=0 (AKA users formerly belonged to one of the protected groups).
Hi Simon,
Can you explain, what happens if the script as you mentioned is run on DC=domain, DC=com and contains some users who are part of the protected groups aka memeber of Adminstrators group. Will it ignore these or ???
Please email me Md DOT AthifKhaleel AT MVPS.ORG
Thanks
Mohammed Athif Khaleel
MVP – SUS / WSUS
Blog http://msmvps.com/athif/
I am having the same issue, excpet the users that are not inheriting permissions are not members of any admin group. They actually are just random members of different OU’s, with no common denominator. The way that I discovered this issue was that one of our helpdesk employees, who is not a member of an admin group, can make changes on most of the user accounts, but some she cannot. When I checked on it, the group she is a member of is not located on the security tab of these users and the permissions are not inheriting, while 95% of the other users in these same OU’s are inheriting. Make sense?
Hi Athif,
if you refer to the script in KB 817433 it only resets inheritance if the adminCount is 0. That means only users are affected which have been previously in one of the administrative protected groups.
Ulf
Hi Adam,
it does not depend where your helpdesk user is a member of, it depends on where the accounts she tries to manage are members of. You can memberships of one of those "unmanageable" users with "whoami /all" on their desktop while they are logged in. Be carefull b/c even recursive memberships through a distribution group count but will not show via whoami.
You can also check the adminCount attribute of those users, if it’s higher than 0 then they are underneath one of the protected groups.
Ulf
Thanks for the quick reply Ulf…
However, one of the users that is not inheriting permissions is only a member of All Users and Domain Users; no other groups. All Users is the universal distribution group. There are other users that are members of these groups and more that she can make changes to, but not this one. It is not inheriting permissions that would give her the rights to make those changes. KB817433 describes this issue. I got the patch from Microsoft and applied it, but have yet to see any changes.