¿Por qué falla gpupdate?

¿Por qué falla gpupdate?

Entonces tengo un dominio de Windows Active Directory con dos controladores de dominio DC1y DC2ambos ejecutan Windows Server 2008 R2. DC1es el DC principal que desempeña todas las funciones de FSMO. Estaba funcionando bien como se esperaba hasta que un día tuvimos el requisito de que algunas aplicaciones (pésimas) dieran a ciertos usuarios la posibilidad de cambiar la hora y la fecha en sus máquinas por algún motivo. Hemos establecido un objeto de política de grupo para usuarios específicos ( OU1y OU2) permitiéndoles cambiar la hora del sistema:

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

Y agregué grupos a quienes quiero asignar este derecho. Sin embargo, después de configurar esta configuración en DC1, hice una operación gpupdatey se devolvió un error:

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.

Revisé el Visor de eventos y mostró un error, EventID 1006, ErrorCode 49, ErrorDescription: Credenciales no válidas.

Este artículosugiere que este error se debe a que algún servicio del sistema se está ejecutando como una cuenta de usuario cuyas credenciales han sido cambiadas, y después de verificar los servicios, resultó que ninguno de ellos se está ejecutando como usuario (todos se están ejecutando como sistema local, servicio local , o servicio de red, y aparece en los registros como usuario del SISTEMA).

La política no se aplicó a los usuarios y tuvimos que solucionar manualmente algunos casos urgentes. gpupdateLa ejecución DC2no produce errores, por lo que pensamos en transferir roles de FSMO, DC2eliminarlo DC1y reformatearlo (o lo que sea que hagan los administradores desesperados estos días :D) como último recurso. En este momento transferimos los roles y seguir ejecutando gpupdate(y gpupdate /force) genera el mismo error, DC1pero se ejecuta sin problemas en DC2. Sin embargo, la política no se aplicó. ¿Cuál es el problema y en qué nos estamos equivocando? ¿Y cómo podemos solucionar eso?

PD: También verifiqué dos veces el DNS y utilicé el analizador de mejores prácticas de roles de Active Directory, pero solo me dio un par de advertencias sobre no realizar copias de seguridad y un error sobre la configuración de la sincronización de hora.

ACTUALIZAR: Alguien publicó una respuesta (eliminada poco después) diciendo que sufrió el mismo problema y si encontramos una solución. No, no lo hicimos, simplemente reemplazamos la pésima aplicación que necesitaba esa política de grupo.

Respuesta1

borrar las credenciales almacenadas en caché en la máquina

rundll32.exe keymgr.dll,KRShowKeyMgr

borrar credenciales de dominio

  • descargar psexec
  • ejecutar cmd como sistema

    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
    

Si inicia el registro de Windows con privilegios de nivel SISTEMA y navega hasta "HKEY_LOCAL_MACHINE\SECURITY\CACHE", encontrará un total de 10 entradas desde NL1 hasta NL10. Estas entradas binarias contienen las credenciales almacenadas en caché de los usuarios a nivel de dominio. De forma predeterminada, Windows permite almacenar en caché un total de 10 credenciales y, si las 10 entradas están llenas, cualquier credencial nueva que se almacene en caché se sobrescribirá con la fecha de valor de la entrada NL más antigua. Además, para saber cuántas entradas libres quedan, simplemente cuente el número de entradas cuyos datos de valor binario están llenos de '0'.

información relacionada