Event ID 1006: Group Policy cannot authenticate to Active Directory

Fix it now

Microsoft publishes 1006 as “Windows could not authenticate to the Active Directory service on a domain controller. (LDAP Bind function call failed). Look in the Details tab for error code and description.” A domain controller was found, so this is not connectivity: the machine’s own credentials, its clock, or a right on the domain controllers is the problem.

Test-ComputerSecureChannel -Verbose
w32tm /query /status
gpupdate /force

1. Read the LDAP error in the Details tab of the 1006 entry. 81 is LDAP_SERVER_DOWN and 82 is LDAP_LOCAL_ERROR, which Windows maps to a generic client-side directory error rather than to anything credential-specific.
2. If the secure channel test returns false, repair that first with Test-ComputerSecureChannel -Repair -Credential * and restart. Group Policy cannot authenticate with a computer account that no longer matches.
3. On a domain controller, run dcdiag /test:CheckSecurityError /ReplSource:<another dc>. Microsoft documents it as checking time skew, which must be under 300 seconds for Kerberos, the permissions on every naming context, connectivity to SYSVOL and NETLOGON, and the “Access this computer from the network” privilege.
4. Run dcdiag /test:NetLogons on the same server, which checks that Administrators, Authenticated Users and Everyone hold that privilege.

Test-ComputerSecureChannel -Repair needs local Administrators membership on the machine being repaired, and a credential with rights over its computer object.

If the bind succeeds and gpupdate completes, you are done. If not, the next section covers what the bind needs and where it breaks.

Why it happens

Before it reads a single setting, the Group Policy service binds to LDAP on a domain controller as the computer account. That bind is normally Kerberos: the machine asks for a service ticket for the directory service, presents it, and gets a session. Every part of that has its own failure mode. The computer account must exist and its password must match, a key distribution centre must be reachable, the clocks must be close enough, and the service principal name must match the server actually being contacted.

The LDAP result code in the Details tab narrows it, though less than people assume. 81 is LDAP_SERVER_DOWN, which Windows maps to ERROR_BAD_NET_RESP: the server could not be reached for the bind. 82 is LDAP_LOCAL_ERROR, which Windows maps to ERROR_DS_GENERIC_ERROR. That is a generic client-side failure, not a credential-specific one, so an 82 is a starting point rather than an answer.

Event 1097 is the companion worth knowing: Microsoft publishes it as “Windows could not determine the computer account to enforce Group Policy settings. This may be transient. Group Policy settings, including computer configuration, will not be enforced for this computer.” Where 1006 says the bind failed, 1097 says the machine could not establish its own identity at all, and the two together point firmly at the computer account rather than at the network.

Event 40961 turns up in the same window on many of these machines. Microsoft does not publish a meaning for it, so read it for the service name it carries rather than for the number: it tells you which service the machine was reaching for when the secured connection could not be established, which is usually enough to say whether one domain controller is at fault or all of them are.

Full reference

The codes

An LDAP 82 does not mean Kerberos. It maps to a generic directory error on the client side, and the useful next step is to establish the machine’s own identity and clock rather than to start reading ticket caches.

The dcdiag tests that fit this event

Working out whether it is one domain controller or all of them

1. Establish which domain controller the failing client is using. Do not assume it is the nearest one.
2. Point a test client at a different domain controller and repeat.
3. If only one server fails, run the machine account and advertising tests on it.
4. If every server fails for every client, something changed centrally: a user right, a directory security requirement, or the time source the hierarchy uses.
5. If every server fails for one client, the client’s own account or clock is the problem.

Repairing rather than rejoining

Rejoining the domain does clear most of these, and it is a poor first move. Leaving to a workgroup and rejoining under the same name typically produces a new object with a new security identifier, so group memberships and anything keyed to the old identifier are lost. Microsoft’s documented repairs keep the object: Test-ComputerSecureChannel -Repair on the client, and dcdiag /test:MachineAccount /FixMachineAccount on a domain controller whose own account is at fault. Try both before you take the machine out of the domain.

The privilege that breaks more than policy

If your investigation ends at the “Access this computer from the network” privilege on the domain controllers, widen it before you close the ticket. Microsoft’s own NetLogons test looks for three principals holding it, and a baseline that removed them will be breaking file share access, replication and remote management at the same time. Those failures are quieter than a Group Policy event, so they are often reported days later as separate problems by different people.

Hardening you should not undo

Where the failing clients are old builds or appliances that cannot meet a directory security requirement the domain controllers now enforce, the temptation is to relax the requirement until the errors stop. That trades a visible problem for an invisible one across the whole domain, and it is not a fix so much as a decision to accept a weaker posture on every client to accommodate the weakest. Isolate what cannot comply, plan its replacement, and keep the requirement.

Every code this article covers

Confirm the fix worked

1. Test-ComputerSecureChannel returns true without the repair switch.
2. gpupdate /force completes and no new 1006 appears.
3. dcdiag /test:CheckSecurityError /ReplSource:<dc> reports no errors on the domain controller involved.
4. dcdiag /test:NetLogons succeeds on that domain controller.
5. w32tm /query /status on the client shows a small offset against a domain time source.

Questions people ask about this