
Portanto, tenho um domínio do Windows Active Directory com dois controladores de domínio DC1
e DC2
ambos executando o Windows Server 2008 R2. DC1
é o DC principal que detém todas as funções do FSMO. Ele estava funcionando bem como esperado, até que um dia tivemos a necessidade de alguns (péssimos) aplicativos darem a determinados usuários a capacidade de alterar a hora e a data em suas máquinas por algum motivo. Definimos um objeto de política de grupo para usuários específicos ( OU1
e OU2
), permitindo que eles alterem a hora do sistema:
Computer Configurations
-> Windows Settings
-> Security Settings
-> Local Policies
-> User Rights Assignment
-> Change the system time
E adicionei grupos aos quais desejo atribuir esse direito. No entanto, depois de definir essas configurações DC1
, fiz um gpupdate
e um erro foi retornado:
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.
Verifiquei o Visualizador de Eventos e ele mostrou um erro, EventID 1006, ErrorCode 49, ErrorDescription: Invalid Credentials.
Este artigosugere que este erro é causado porque algum serviço do sistema está sendo executado como uma conta de usuário cujas credenciais foram alteradas e, após verificar os serviços, descobriu-se que nenhum deles está sendo executado como usuário (todos estão sendo executados como sistema local, serviço local , ou serviço de rede, e aparece nos logs como usuário SYSTEM).
A política não foi aplicada aos usuários e tivemos que fazer algumas soluções manuais para alguns casos urgentes. gpupdate
A execução DC2
não produz erros, então pensamos em transferir as funções do FSMO, DC2
removê-lo DC1
e reformatá-lo (ou o que quer que os administradores desesperados façam hoje em dia :D) como último recurso. No momento, transferimos as funções e ainda executar gpupdate
(e gpupdate /force
) resulta no mesmo erro, DC1
mas funciona perfeitamente em DC2
. No entanto, a política não foi aplicada. Qual é o problema e onde estamos errando? E como podemos consertar isso?
PS: Também verifiquei novamente o DNS e usei o analisador de práticas recomendadas da função do Active Directory, mas ele apenas me deu alguns avisos sobre não fazer backup e um erro sobre a configuração da sincronização de horário.
ATUALIZAR: Alguém postou uma resposta (excluída logo depois) que sofreu o mesmo problema e se encontramos uma solução. Não, não encontramos, apenas substituímos o péssimo aplicativo que precisava daquela política de grupo.
Responder1
limpe as credenciais armazenadas em cache na máquina
rundll32.exe keymgr.dll,KRShowKeyMgr
limpar credenciais de domínio
- baixar psexec
execute 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
Se você iniciar o registro do Windows com privilégio de nível SYSTEM e navegar até "HKEY_LOCAL_MACHINE\SECURITY\CACHE", encontrará um total de 10 entradas começando de NL1 a NL10. Essas entradas binárias contêm credenciais armazenadas em cache dos usuários no nível do domínio. Por padrão, o Windows permite que um total de 10 credenciais sejam armazenadas em cache e, se todas as 10 entradas estiverem cheias, qualquer nova credencial a ser armazenada em cache será substituída pela Data Valor na entrada NL mais antiga. Além disso, para saber quantas entradas livres restam, basta contar o número de entradas cujos dados de valor binário estão cheios de '0'.