“What is there to talk about a simple task like this?!” – this question you may have in your mind is actually a valid question on first look. If you’ve ever had the need to delegate the Microsoft DHCP server administration to a person or, say the network team of your organization you might have used the built-in domain local Active Directory security group “DHCP Administrators” pretty easily but does this approach delegate the DHCP infrastructure “completely” from an Active Directory perspective? Not exactly! You might experience the incompleteness of this “delegation” when your network team says that they cannot authorize or unauthorize DHCP servers. So how do we make this “complete”?
To do this task we need to look a little deeper into the Active Directory (well, as usual 😉 ). The DHCP server metadata is stored in the NetServices compartment in the node Services in the Active Directory Sites and Services.
The metadata are stored in the dHCPClass objects and each authorized DHCP server has a corresponding dHCPClass object. These corresponding dHCPClass objects are created during the authorization process of DHCP servers and are deleted during the process of unauthorization. Now you almost know what to do next! 😉
The delegation of authorization and unauthorization of DHCP servers is two-fold.
- Granting permission to create/delete dHCPClass objects.
- Granting permission to change all properties of the existing dHCPClass objects.
So, we go into the Security tab of the NetServices node and find the create/delete dHCPClass objects permission or ACL. But wait, where are those ACLs???
After pulling our my hair for a few minutes I decided to call upon my sweet friend, the “ADSI Edit”! 🙂 The NetServices node is located in the Configuration naming context in Active Directory. (Note: viewing the Configuration naming context using ADSI Edit is not covered here.)
Now we are in business! When you go into the security settings of the node NetServices you can see the two ACLs Create dHCPClass objects and Delete dHCPClass objects. You need to select the This object only from the Applies to: section as it is useless to propagate this ACL to the child objects.
When we set the two ACLs shown above we have already accomplished the first goal of ours, which is to delegate permission to create/delete dHCPClass objects. The second goal is to delegate permission to change all properties of existing dHCPClass objects. To accomplish this task we need to Allow List Contents, Read all properties, Write all properties, and Delete to the Descendant dHCPClass objects. Of course you can grant Full control but its really unnecessary!
Always remember the principle of least privilege and never grant a permission that is not needed.
That’s it! But you know, you can make this delegation “perfect” so no one will ever have to worry about this in future. What if you delegate these permissions to a security group, say “DHCP Authorizers” and add the built-in DHCP Administrators domain local security group as a member to it? Pretty nice ha! Now the DHCP Administrators will indeed be the “full” DHCP Administrators after all.
Until next time!
Note: By default, only the Domain Admins and the Enterprise Admins have the privilege to authorize and unauthorize DHCP servers in an Active Directory domain.