If you found this post, then you probably have searched to the ends of the Earth and the cyber space for a solution to this requirement. I know the frustration and I hope I have a solution for you!
My story starts in an organization with a Microsoft infrastructure where the Microsoft Network Policy Servers (NPS) are deployed on the domain controllers as recommended by Microsoft. The domain controllers are managed by the Directory Services team and the NPS, being a network service is managed by a separate Network Services team. Microsoft probably didn’t think of a scenario where the NPS is needed to be managed by a non-domain administrator before they publicly announced their recommendation on deploying the NPS. (It’s Microsoft, nothing surprising there 😉 ). When I started this work we already had more than 10 domain admins which is fairly high. There was only one person in the Network Services team and he was a member of the Domain Admins group since he was the one who managed NPS. The situation became complicated with the arrival of a new member to the Network team.
For NPS administration, you should be a member of the local administrators group of the server on which the NPS role is installed. In the recommended setup, the user should be a member of the domain controller’s Administrators group. There are 4 highly privileged groups in an Active Directory domain; Administrators, Enterprise Admins, Domain Admins, and Schema Admins. These groups are also called Protected Groups. (There are a few other Protected Groups as well). Out of these 4 groups, Administrators group is the most privileged group by design. For example, in a situation where the Administrators group is denied full control of an Active Directory object, a member of this group can “still” take ownership of that particular object and reset all the ACLs of it. Pretty neat ha!
In delegating NPS we have to use the Administrators group whether we like it or not. What we can do however is to reduce the undesired “impact” of this situation. We need to avoid using the groups Domain Admins and Enterprise Admins as they allow “heavenly powers” such as promotion and demotion of domain controllers. So the concepts to follow here are,
- enforcing the principle of least privilege, and
- preventing privilege escalation.
We have already covered the first one, where we decided to use the Administrators group instead of any other privileged group. Once a user is a member of the Administrators group he/she can freely add him/herself to Domain Admins or Enterprise Admins as he/she needs. The solution, we remove “write members” property on the groups Domain Admins and Enterprise Admins for Administrators right? Unfortunately this simple solution work only for the next ~60 minutes from the moment the change is done. In the built-in mechanics of Microsoft Active Directory, there is a process called SDProp that resets the ACLs of the Protected Groups every 60 minutes. (You can read more about this in the TechNet magazine and the AskDS TechNet blog). Now this is a dead end! We need to grant the Network team access to NPS to perform their day to day work but at the same time we don’t want them to be able to be Domain or Enterprise Admins as they please.
If they can’t see the groups Domain Admins, Enterprise Admins, Schema Admins, and Administrators (of course this one too, so that they can’t make one of their friends an Administrator 🙂 ) they can’t do anything to them right? How can someone change the membership of a group that they can’t see or access in the first place, right?! The strategy I followed here is called “data hiding in Active Directory”. I haven’t seen this technique being widely used but it is indeed a valuable feature. So I created a new group for NPS administration, let’s say “NPS Admins”, added it as a member of the Administrators group. Then I created a new OU named “Protected Objects” at the root of the directory,
- denied Full Control on it for the “NPS Admins”,
- disabled permission inheritance,
- removed Administrators, Authenticated Users and other non-important ACLs, and
- made sure that the Enterprise Admins, Domain Admins, SYSTEM, ENTERPRISE DOMAIN CONTROLLERS retain the permissions they need on it.
Hang on, we are almost there! Finally I moved the groups Domain Admins, Enterprise Admins, and Schema Admins into the new OU. Unfortunately, the group Administrators being a built-in one it cannot be moved. So I had to add an ACL on the Builtin OU that denied List Contents for the NPS Admins. That’s it, right? Not exactly! What if the new network guy decides to reset the passwords of all Domain Admins and Enterprise Admins one day?! Pretty scary right?! We need to protect them as well. So I moved the users that are members of these two groups into the Protected Objects OU. We have now delegated NPS administration in “safer way” without much compromise.
Protected Objects OU
View of the Protected Objects OU for a NPS Admin
View of the Builtin OU for a NPS Admin
You need to make sure that any ACLs that grants “allow” permissions on the OU’s that contain user accounts and groups that are sensitive to your business are removed. Manage these permissions with custom access groups. Something to keep in mind in working with ACLs is that, although the deny ACLs always override the allow ones, in Microsoft Active Directory an allow ACL closest to the target object will override a deny one that is farthest to it. In other words, a non-inherited allow ACL will override an inherited deny one.
Note: If you go deep into modifying the AdminSDHolder you can be creative and set up ACLs on the Protected Groups and accounts according to your requirements but think twice before over complicating your set up. It might be a nightmare during troubleshooting in future, if not for you, then for the next domain administrator. Modifying the AdminSDHolder will not give any solution in delegating the NPS administration. You can read more about this in the Laura’s nice blog post here.