Why gpupdate fails?

Question

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..

Solution

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'.

Comments

[Bartłomiej Zarzecki]

what about executing instruction from the error message ? what are the result of GPRESULT /H GPReport.html

[jojojoj]

This doesn't sound like the current issue, but will eventually affect your result. GPOs with user settings should be linked to User OU's. Those with computer settings (like this) need to be linked to the OU where the computer account resides. You're not linking this to a Domain Controllers OU, right?

[amyassin]

@BartłomiejZarzecki the result showed not apparent error. Just a denied GPO. It is the same in DC2 where there's no error. I couldn't paste the entire output, is there any specific part to look for?

[amyassin]

@Craig620 No, not to the Domain Controllers OU. And also computers OU is missing! I'm applying it to two OUs that contains those users, assuming those users will have these privileges on all computers they login to!

[amyassin]

@BartłomiejZarzecki It's worth mentioning that the denied GPO was another empty GPO, not the one that was added. The same result (including the denied GPO) is in DC2's report after a successful gpupdate...