This is a short follow-up on my earlier blog entry on the AdminSDHolder.
As stated earlier the AdminSDHolder process that runs as a background task on the Domain Controller acting as PDC Emulator sets the Security Descriptor of Protected Admin Groups.

The thing I wanted to revisit is when the adminCount attribute and Security Descriptor isn’t set on objects.

When AdminSDHolder evaluates the direct and indirect members of Protected Groups Security Descriptor it changes it on those that doesn’t comply. If a user for some reason already has a compliant SD no changes is needed and nothing will be done.
Since nothing is done, the adminCount attribute won’t be changed to the value of 1. this is one reason why you can’t trust a simple search for users with adminCount=1.

If you want to see the defaultSecurityDescriptor of AdminSDHolder per schema version.

Another interesting side of this is the nesting of memberships cross trusts. A few easy examples:

Trusts within a forest:

What happens when a user in a child domain is member of Enterprise Admins which resides in the Forest root domain?

The user objects SD will be changed. But it’s done by the Domain Local AdminsSDHolder process and it uses its own SD to propagate to the user object. This means there could be a difference of Enterprise Admins SDs depending of which domain in the forest the user belong to.
If the admins in the child domain manage to mess up the ACLs for AdminsSDHolder the Enterprise Admin could be in jeopardy.

Forest trusts:

What happens when a user from another forest is member of the Built-in Administrators group?

Well, that user object won’t have any special SD and the adminCount attribute will be Null/not set. AdminSDHolder nor the DCs doesn’t keep track of users group memberships in external domains. The group membership references lie within the groups domain and AdminSDHolder has no way of propagating the SD on a user from the external domain.

This is not unusual and could be a high risk since there could be many more delegated admins owning that account and can compromise the entire forest where the user is a Built-in Administrator.

Summary:
adminCount for me, is only a half good attribute for traceability, it can give you a hint of privileged users, user that has had privileges and users that has the potential to be a privileged user.
AdminSDHolder is a good extra layer of defense when having delegated admins, but it can’t help you all the way if you start nesting over trusts.

Bonus:
And here is a bonus point about inheritance. The AdminSDHolder process by itself doesn’t turn of inheritance on the objects.
The SD has the P control dacl_flag set, meaning its marked as protected and doesn’t allow inheritance. If that is changed on the AdminSDHolder objects SD, it will be propagated to the members within 60 min. Don’t change this!