Event ID 1046: the DHCP server is not authorised in Active Directory

Fix it now

The DHCP service asked Active Directory whether this server is on the authorised list, was told it is not, and stopped answering clients. Restarting the service only asks the same question again, so authorise the server with an account that can write to the forest configuration partition.

Get-DhcpServerInDC
Add-DhcpServerInDC -DnsName dhcp01.contoso.com -IPAddress 10.0.0.5
Restart-Service DHCPServer
Get-DhcpServerv4ScopeStatistics

1. Read the Get-DhcpServerInDC output first. If this server is absent, it was never authorised or the entry has been removed. If it is listed with an address it no longer uses, remove that entry with Remove-DhcpServerInDC before adding the current one.
2. The same list is visible from a command prompt with netsh dhcp show server, and in adsiedit.msc under Configuration, Services, NetServices.
3. Confirm the service has changed its mind: Event ID 1044 should appear after the restart, in the System log and in Applications and Services Logs, Microsoft, Windows, DHCP-Server.
4. If the authorisation itself fails with “The specified domain either does not exist or could not be contacted”, stop and test the path to a domain controller: Test-NetConnection -ComputerName <dc> -Port 389.

The authorised-server list lives in the forest configuration partition, which is why Microsoft’s guidance is to authorise from an Enterprise Administrator account rather than a domain admin one.

If leases are being issued again you can stop here. The next section explains what the service is checking, and why some servers lose their authorisation days after you grant it.

Why it happens

A domain-joined Windows DHCP server does not simply start serving. It looks for its own IP address in a list of authorised servers held in the configuration partition of Active Directory, reached over LDAP. If the address is not there, the service stays running but refuses to answer clients: the console looks normal, every scope is present, and no device gets a lease.

The check is not a one-off at service start. Microsoft documents that the server revalidates its authorisation status in Active Directory Domain Services every hour, and that if its address is not found in the list it deauthorises itself. That is the detail behind the most confusing version of this fault, where a server works all afternoon and stops overnight without anybody touching it.

Be clear about what the mechanism is not. It constrains Windows DHCP servers that are domain members; an appliance or a Linux server leases addresses regardless of what the directory thinks. Treat authorisation as control over your own estate, not protection from someone else’s equipment.

Full reference

The four events that describe the decision

1063 is often quoted in this context and it does not belong here. It is the pool-exhaustion event: if you have it, the server is authorised and serving, and it has simply run out of addresses.

Where the record actually lives

Authorisation creates an object under CN=NetServices,CN=Services,CN=Configuration,DC=..., written over LDAP. Because the configuration partition is forest-wide, one authorisation covers the forest and the rights needed are forest-level. Two consequences follow: replication latency can make a freshly authorised server look unauthorised on a distant site for a while, and a replication conflict on that container produces the CNF objects described above.

Commands worth having open

The standalone case, and what the event text actually says

Read the whole 1046 description rather than the first line. Microsoft’s text lists three possible reasons: the machine is part of a directory service enterprise and is not authorised in the same domain; the machine cannot reach its own directory enterprise and has encountered another DHCP service belonging to one where it is not authorised; or an unexpected network error occurred. The middle reason is the one that catches lab and workgroup servers plugged into a production segment – nothing was removed, and nothing on that server needs fixing except where it is plugged in.

When the server keeps losing its authorisation

• Someone or something is deleting the object. Enable Audit Directory Service Changes and set auditing on the NetServices container; the Security log then names the account behind “A directory service object was deleted”.
• Check for a second, older entry for the same server under a previous name or address, which can be removed by a cleanup script that thinks it is tidying up.
• Confirm the server’s address has not changed since the entry was written – DHCP servers should hold a static address.
• If the server sits behind an intermittent link, the hourly revalidation is the thing to watch: a failure to reach a directory server produces 1059, and 1046 follows.

Data collection before you call anyone

Microsoft’s own DHCP troubleshooting path uses the TroubleShootingScript toolset. On the affected server, .\TSS.ps1 -Scenario NET_DHCPsrv collects the logs a support case will ask for, which is worth doing before rebuilding anything.

Every code this article covers

Confirm the fix worked

1. Get-DhcpServerInDC lists this server with the address it is actually using.
2. Event ID 1044 appears after the most recent service start, and no 1046 follows it.
3. A test client releases and renews and receives a lease from this server.
4. Get-DhcpServerv4ScopeStatistics shows the in-use count climbing again.
5. Leave it a couple of hours and re-check the log, so the hourly revalidation has run at least once.

Questions people ask about this