6

In our environment we have two AD-accounts per person, one user level account and one admin level account. Our support-staff can only reset user level accounts, which is good but I can't figure out why. This is the ADUC permissions on top domain: ADUC permissions

What can be causing them to not be able to reset admin-accounts? The admin accounts are not part of any global admin group (Domain Admins etc).

Salve
  • 73
  • 4
  • 1
    You need to show the permissions on the user accounts that are unable to have the password reset, *not* the permission on the OU/domain. – Greg Askew Jul 07 '22 at 11:31

2 Answers2

11

Is it possible that they were once part of the Domain Admins group? If so, inheritance of permissions from OU would be disabled on them and you would have manually to reactivate it.

Manu
  • 704
  • 2
  • 19
  • Yes, in fact they were! I can now see on the user objects security tab that the support staff doesn't have permission to reset. What's the easiest approach to delegate this? Because newer admin accounts will not be part of DA at any point so I wan't to make this standard and only if your account is in a certain group you can reset admin passwords. Do I need to add a group on every account? – Salve Jul 07 '22 at 12:33
  • 1
    Open the user and go to the Security Tab. Klick on Advaned. If it says "Enable inheritance" in the bottom left corner, it is disabled. If you haven't set some permissions manually on these users, you should just be able to enable it again. I would compare the permissions with these of the OU first to be sure there won't be something missing afterwards. – Manu Jul 07 '22 at 12:40
  • As I don't know the history of your AD, I can't tell you 100% what to do. Once inheritance is enabled on any users again, you would be able to give permissions to change passwords on an OU. Maybe start with one user at the time ;) – Manu Jul 07 '22 at 12:45
  • 2
    So I have now created a specific group to handle ADM-accounts, and kept the disabled inheritence on the OU where the admin accounts are located. Thanks for the help! – Salve Jul 07 '22 at 13:50
7

This is by design.

Generally, lower-tier support staff (even secondary privileged accounts) should not have the ability reset passwords of higher-tier adminstrative accounts. This is viewed as a potential privilege escalation. A lower tiered admin can reset the password of a higher-tiered admin, gain control of the account and potentially own the network.

To protect against this, AD has a built-in mechanism to ensure that stray delegations are not inherited by what are deemed to be highly-privileged accounts. A full list of the groups covered by this mechanism 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#protected-groups

The SDProp process flags all accounts which are recursive members of these groups by setting the attribute adminCount to a value of 1. Then each of these accounts has inheritance disabled and NTDS permissions changed/updated to match with the ACL on the AdminSDHolder object. So every hour, inheritance is disabled and the ACL is reset to a known good baseline.

This process ensures that any protected account's ACL doesn't drift from a defined base -- so you don't accidentally delegate the ability of a junior admin to reset the password of a domain admin -- or that you don't accidentally (permanently) block an admins access to do so.

So, if you need to change the ACL on sensitive/privileged objects (though I would advise against doing so in this case), you need to change the ACL on the AdminSDHolder object first, and let the permissions flow through the SDProp process.

One catch is that, the SDProp process will set the adminCount attribute to 1; however, there is no corresponding process that will ever clear that attribute (null/empty is the default). So, any account that used to be privileged that is no longer will still be affected by this process. If you find yourself in that situation, the appropriate course of action would be to clear the attribute and re-enable inheritance on the object.

Semicolon
  • 1,646
  • 7
  • 7