I'm trying to determine the least-privilege approach for administering Windows DHCP. I'm considering moving DHCP off the domain controller and DNS server so those roles are separated. If DHCP runs on its own Windows Server, does the current Windows Server release handle the required permissions automatically, or should I apply additional hardening? I'm especially interested in the difference between permissions for managing DHCP and the credentials DHCP uses for secure DNS updates.
3 Answers
The best placement for DHCP depends on availability requirements. Running it on a firewall or Layer 3 switch can keep address assignment working if the server infrastructure is down, while running it on Windows integrates well with Active Directory DNS and provides familiar management tools. DHCP on a domain controller is functional, but separating the roles can reduce blast radius and make administration easier to delegate.
Regardless of where it runs, avoid giving operators local Administrator access just to manage DHCP. Use the DHCP-specific groups, and consider IPAM or a controlled automation layer if you need more granular workflows than the built-in administrator and read-only roles provide.
The DHCP service itself already runs under Network Service, so there normally isn’t a separate service account to restrict. The main privilege decisions are who can administer DHCP and which credential it uses when registering DNS records.
After installing the DHCP role, complete the security-group configuration, such as by running Add-DhcpServerSecurityGroup and restarting the DHCP Server service. Add administrators to the server’s DHCP Administrators group so they can manage scopes and reservations through RSAT without being local administrators or having broad Active Directory privileges. DHCP Users can be used for read-only access.
Authorizing a DHCP server in Active Directory is a separate, usually one-time task. It requires Enterprise Admin privileges or delegated rights on the NetServices container, so it is often simplest to have an appropriately privileged administrator perform that step.
For secure DNS updates, configure a dedicated ordinary domain account with Set-DhcpServerDnsCredential. This account is used for DNS registration; it does not run the DHCP service. Also enable DNS name protection, and avoid putting the DHCP server in DnsUpdateProxy when using a dedicated credential because that group can leave records without useful security ownership.
If you have DHCP failover or multiple DHCP servers, configure the same dedicated DNS update credential on every partner. Otherwise, records created by one server may not be updateable by another. This matters even more for Macs, Linux systems, appliances, and other clients that do not reliably perform their own secure DNS updates.
Keep secure dynamic updates enabled on the DNS zones. If a legacy or third-party system cannot perform secure updates, manually create its records rather than broadly allowing non-secure updates. Also verify that DNS aging and scavenging are configured deliberately instead of assuming stale records will disappear on their own.
Moving DHCP off the domain controller also avoids having the domain controller’s computer account create or update a broad range of records. Existing records created by the old server may remain owned by the old computer account, so some cleanup or scavenging may be needed after the migration.