Various accounts in my Active Directory environment didn’t seem to want to inherit permissions correctly. This was causing issues with Azure AD Connect and other various homebrew processes that were in place. I would go to the security tab of the account, go to advanced, and see the option to “Enable Inheritance” was available. Upon clicking that, it would seem to temporarily work, only to revert back next time I would go and check on it.
The culprit? Orphaned adminCount accounts. Or more precisely, accounts that used to be part of a protected group in Active Directory. They were removed from that group membership, but the setting stuck anyway. Basically, accounts that have the adminCount attribute set to a value of 1 are protected by the AdminSDHolder object in AD. What this does is overwrite security permissions on protected objects to prevent malicious activity every hour (by default).
First, let’s find all the accounts that have the attribute set to 1
Get-ADUser -Filter * -Properties admincount | where-object admincount -eq 1 | sort-object name | select name, admincount
This will generate a list of users who have the admincount attribute set to a value of 1. Obviously there will be some accounts that require this. We want to target the ones that don’t need it. If you are able to narrow down this list by specifying a certain OU or by excluding certain accounts based on their naming convention that would probably be a good idea. For example, if we know our troublesome users are in the sales OU, we can add this to the script above. Obviously you’ll need to put in the actual distinguished name for the OU.
Get-ADUser -filter * -SearchBase "OU=sales,ou=users,dc=company,dc=com" | where-object admincount -eq 1 | sort-object name | select name, admincount
So for me, I luckily only had about 12 or so users who were messed up so it wasn’t too bad to fix. If you browse to the user account in Active Directory Users and Computers (not search, browse to the OU) and go to the properties of the account, you should be able to go to the attribute tab. From there, you will see the adminCount attribute set to a value of 1. Edit this value, and select clear. This will remove the attribute from the account altogether so it matches other non-protected accounts.
Then go to the security tab, click advanced, and enable inheritance.
So you think we’re done? Well, possibly. The real test is to kick off the process that resets permissions on objects protected by the AdminSDHolder object. If that process runs and the accounts keep the settings we changed above, then you’re good. If the account gets set back with adminCount=1, it is most likely still getting this setting from a group membership.
To manually kick off this process, log into your PDC Emulator and type “ldp” into the start menu and click on the Ldap program it suggests.
Click on Connection > Connect. I can use port 636 because my environment supports SSL. The default port is 389.
If it is successful you should see Dn:(RootDSE) in the output
Click on Connect > Bind
In my environment, I can bind as the “currently logged on user”. If your environment is different, use the appropriate credentials.
You should see this if the bind is successful
Click Browse > Modify
Enter the following information
- Attribute: RunProtectAdminGroupsTask
- Values: 1
- Push Enter
- Click Run to execute the task.
If it is successful, the output should look like this
So at this point, you’ve re-ran the SDProp process which re-applies the security permissions held by the AdminSDHolder object. Go and check to see if your user account(s) have reverted back to their previous settings. If they have, they are likely part of a protected group. To determine what group may be causing this, run the following command
Get-ADPrincipalGroupMembership | Get-ADGroup -properties admincount | select name, admincount
The output from this command will show all the groups the user is a member of, and if any of those groups have the adminCount attribute set to 1. From here, you need to go down the rabbit hole and determine why the groups are set the way they are. Do they have an orphaned adminCount attribute? Or is it a member of a protected group on purpose? If it is not on purpose, you’ll likely need to go through the same steps we just did above, only this time for the group in question. Remove the adminCount attribute, enable inheritance, manually run the SDProp process and see if the settings reverted for the group. If it does revert, you’ll have to see what groups that group is a part of and so on and so forth. The default protected groups can be found here https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/appendix-c–protected-accounts-and-groups-in-active-directory
While this was a bit time consuming to track down, I was able to successfully identify and correct the problem in my environment.