Turns out I was mistaken in my previous post. A few minutes after enabling inheritance, I noticed it was disabled again. So that means the groups must be protected by AD.
I knew of the
AdminSDHolder object and how it provides a template set of permissions that are applied to protected accounts (i.e. members of groups that are protected). I also knew that there were some groups that are protected by default. What I didn’t know, however, what that the defaults can be changed.
Initially I did a
Compare-Object -ReferenceObject (Get-ADPrincipalGroupMembership User1) -DifferenceObject (Get-ADPrincipalGroupMembership User2) -IncludeEqual to compare the memberships of two random accounts that seemed to be protected. These were accounts with totally different roles & group memberships so the idea was to see if they had any common groups (none!) and failing that to see if the groups they were in had any common ancestors (none again!)
Then I Googled a bit :o) and came across a solution.
Before moving on to that though, as a note to myself:
AdminSDHolderobject is at
CN=AdminSDHolder,CN=System,DC=domain,DC=com. Find that via ADSI Edit (replace the domain part accordingly).
- Right click the object and its Security tab lists the template permissions that will be applied to members of protected groups. You can make changes here.
- SDProp is a process that runs every 60 minutes on the DC holding the PDC Emulator role. The period can be changed via the registry key
HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\AdminSDProtectFrequency. (If it doesn’t exist, add it. DWORD).
- SDProp can be run manually if required.
So back to my issue. Turns out if a group as its
adminCount attribute set to 1 then it will be protected. So I ran the following against the OU containing my admin account groups:
Get-ADGroup -SearchBase "OU=Admin Accounts,DC=domain,DC=com" -Filter 'adminCount -eq 1' | ft Name
Bingo! Most of my admin groups were protected, so most admin accounts were protected. All I have to do now is either un-protect these groups (my preferred solution), or change the template to delegate permissions there.
Update: Simply un-protecting a group does not un-protect all its members (this is by design). The member objects too have their
adminCount attribute set to 1, so apart from fun-protecting the groups we must un-protect the members too.
Get-ADGroup -SearchBase "OU=Admin Accounts,DC=myDomain,DC=com" -Filter 'adminCount -eq 1' | Set-ADGroup -Clear adminCount
Get-ADUser -SearchBase "OU=Admin Accounts,DC=myDomain,DC=com" -Filter 'adminCount -eq 1' | Set-ADUser -Clear adminCount
Update 3: You can unprotect the following default groups via
dsHeuristics: 1) Account Operators, 2) Backup Operators, 3) Server Operators, 4) Print Operators. But that still leaves groups such as Administrators (built-in), Domain Admins, Enterprise Admins, Domain Controllers, Schema Admins, Read-Only Domain Controllers, and the user Administrator (built-in). There’s no way to un-protect members of these.
Something I hadn’t realized about
adminCount. This attribute does not mean a group/ user will be protected. Instead, what it means is that if a group/ user is protected, and its ACLs have changed and are now reset to default, then the
adminCount attribute will be set. So yes,
adminCount will let you find groups/ users that are protected; but merely setting
adminCount on a group/ user does not protect it. I learnt this the hard way while I was testing my changes. Set
adminCount to 1 for a group and saw that nothing was happening.
Also, it is possible that a protected user/ group does not have
adminCount set. This is because
adminCount is only set if there is a difference in the ACLs between the user/ group and the AdminSDHolder object. If there’s no difference, a protected object will not have the adminCount attribute set. :)