Ldap – Why gpupdate fails

active-directorydomain-controllergroup-policyldap

So I have a Windows Active Directory Domain with two domain controllers, DC1 and DC2, both running Windows Server 2008 R2. DC1 is the primary DC holding all FSMO roles. It was functioning all right as expected until one day we had a requirement for some (lousy) applications to give certain users the ability to change time and date on their machines for some reason. We've set a Group Policy Object for the specific users (OU1andOU2) allowing them to change system time:

Computer Configurations
    -> Windows Settings
        -> Security Settings
            -> Local Policies
                -> User Rights Assignment
                    -> Change the system time

And added groups whom I want to assign this right to. However, after setting this settings on on DC1, I did a gpupdate and an error was returned:

C:\Users\myuser>gpupdate
Updating Policy...

User Policy update has completed successfully.
Computer policy could not be updated successfully. The following errors were encountered:

The processing of Group Policy failed. 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.

To diagnose the failure, review the event log or run GPRESULT /H GPReport.html from the command line to access information about Group Policy results.

I checked the Event Viewer and it showed an error, EventID 1006, ErrorCode 49, ErrorDescription: Invalid Credentials.

This article suggests that this error is caused because some system service is running as a user account whose credentials has been changed, and after checking the services, it turned out that none of them is running as a user (all are running as local system, local service, or network service, and appears in the logs as SYSTEM user).

The policy was not applied to the users, and we had to do some manual workaround for some urgent cases. Running gpupdate on DC2 yields no errors, so we thought of transferring FSMO roles to DC2 and removing DC1 and reformat it (or whatever desperate admins do these days :D) as a last resort. Right now we transferred the roles, and still running gpupdate (and gpupdate /force) results in the same error in DC1 but runs smoothly in DC2. However, the policy was not applied. What is the problem and where are we going wrong? And how can we fix that?

P.S. I've also double checked the DNS, and used the Active Directory Role best practice analyzer, but it only gave me a couple of warnings about not backing up, and an error about setting time synchronization.

UPDATE: Someone posted an answer (deleted shortly after) that s/he suffered the same problem and whether we found a solution.. No we didn't, we just replaced the lousy app that needed that group policy..

Best Answer

clear the cached credentials on the machine

rundll32.exe keymgr.dll,KRShowKeyMgr

clear domain credentials

  • download psexec

  • run cmd as system

    c:\PSTools>psexec -i -s cmd.exe

PsExec v2.2 - Execute processes remotely
Copyright (C) 2001-2016 Mark Russinovich
Sysinternals - www.sysinternals.com

Microsoft Windows [Version 10.0.14393]
(c) 2016 Microsoft Corporation. All rights reserved.

C:\Windows\system32>whoami
nt authority\system

If you launch Windows registry with SYSTEM level privilege and browse to "HKEY_LOCAL_MACHINE\SECURITY\CACHE", you will find a total of 10 entries starting from NL1 to NL10. These binary entries contain users cached credentials at the domain level. By default Windows allows a total of 10 credentials to be cached and if all 10 entries are full, any new credential to be cached will be overwritten by the Value Date in the oldest NL entry. Also, to know how many free entries are left, simply count the number of entries whose binary value data is full of '0'.

Related Topic