O caso do desaparecimento das alterações na política de grupo (Group Policy)
Por: Daniel Mauser
Introdução
Na semana passada trabalhei em um caso interessante colaborando com o time de Exchange. Inicialmente existia um problema para montar a base de dados do Exchange. O time de Exchange prontamente identificou a causa do problema como à falta de direitos (user right) no privilégio: Manage auditing and security log. Este problema é documentado publicamente neste artigo:
O problema é solucionado inserindo o grupo do domínio Exchange Servers no privilégio: Manage auditing and security log no Default Domain Controller Policy.
Passaram-se dois dias e o time de Exchange foi novamente notificado que o problema voltara a ocorrer. Ao verificarem o privilégio, a modificação feita para incluir o grupo Exchange Servers havia novamente desaparecido, e o privilégio estava sem nenhuma definição.
O problema agora é de Active Directory e mais especificadamente na política de grupo: Default Domain Controller Policy. A questão a ser levantada, porque a política modificada dois dias antes despareceu?
Detalhes sobre o Problema
No ambiente em questão tínhamos dois controladores de domínio chamados DC1 e DC2 respectivamente. O primeiro ponto é verificar a saúde do componente SYSVOL, onde são armazenadas todas as políticas de grupo, e verificar se a replicação do SYSVOL está consistente em todos os controladores de domínio. O serviço responsável pela replicação é o File Replication Service (FRS) e há também um log de eventos específico para este serviço.
Um ponto importante a ser lembrado é que todas as modificações de Group Policy (GPO) via GPMC são efetivadas por padrão no controlador de domínio que armazena o FSMO de PDC. Não importando de onde é iniciado o GPMC, seja do cliente, de um servidor ou outro controlador de domínio. Este comportamento pode ser modificado no próprio GPMC ao clicar o botão direto sobre o domínio.
Ao editar um GPO pode ser observado que o PDC é o controlador de domínio que sempre será selecionado, no caso o DC01, conforme figura abaixo:
Todas as modificações via Group Policy Editor serão salvas no SYSVOL do PDC Emulator e este diretório é replicado para outros controladores de domínio através do FRS. Para verificar a saúde do FRS devemos consultar o log de eventos File Replication Service. No caso, do ambiente em questão o seguinte erro foi encontrado:
Event Type: Error
Event Source: NtFrs
Event ID: 13568
Computer: DC1
Description:
The File Replication Service has detected that the replica set "DOMAIN SYSTEM VOLUME (SYSVOL SHARE)" is in JRNL_WRAP_ERROR.
Este tipo de erro indica que o SYSVOL do controlador de domínio DC1 está em modo de “Journal Wrap”. Neste modo qualquer modificação feita neste servidor não será replicada para os demais controladores de domínio. Entretanto, o DC1 continua recebendo alterações dos outros controladores, que no caso do nosso ambiente é composto apenas por DC1 e DC2.
Nota: Para maiores detalhes sobre esta condição de Journal Wrap consulte:
What happens in a Journal Wrap?
https://blogs.technet.com/b/instan/archive/2009/07/14/what-happens-in-a-journal-wrap.aspx
O fator pelo qual a política estava sendo revertida para “Not Defined” (sem definição) estava sendo causada pela a inexistência desta configuração no DC2. Assim, como a modificação era feita no DC1, e este não replicava a alteração para o DC2, pois estava em modo de Journal Wrap, o DC2 tinha a configuração do privilégio como não definida que sobrepunha à configuração modificada. Assim, revertendo qualquer modificação feita no DC1.
Solução
Para corrigir o problema de Journal Wrap no DC1 é necessário realizar um procedimento específico de recuperação para SYSVOL. No caso acima possuímos um SYSVOL em bom estado, que está armazenado no servidor DC2 e este pode ser utilizado para recuperar o SYSVOL problemático no DC1. Para isso é necessário executar o procedimento especificado no artigo:
Using the BurFlags registry key to reinitialize File Replication Service replica sets
No caso utilizamos o procedimento para fazer uma restauração “não autoritativa” através da designação do valor D2 no valor Burflags no registro.
Este procedimento faz com que o DC1 ignore o conteúdo local e inicie obtenha uma copia idêntica do conteúdo do SYSVOL do DC2.
Para assegurar que a replicação do SYSVOL está consistente entre os controladores de domínio busque pelo evento:
Event ID: 13516
Event Type: Informational
Message Text:
The File Replication Service is no longer preventing the computer %1 from becoming a domain controller. The system volume has been successfully initialized and the Netlogon service has been notified that the system volume is now ready to be shared as SYSVOL. Type "net share" to check for the SYSVOL share.
Conclusão
Aplicações que são dependentes do Active Directory como Exchange, dentre muitas outras, podem ser afetadas por problemas de configuração ou condições inesperadas como o Journal Wrap no FRS.
Muitas vezes observamos comportamentos estanhos como este que indicam que há algo de errado na configuração do ambiente. Recomendo uma validação proativa periódica do seu ambiente de Active Directory ambiente para validar se as configurações e dos componentes centrais do Windows estão sendo executadas em conformidade. Ferramentas de Monitoração como System Center Operations Manager, bem como verificações proativas como o Active Directory Risk Assesment Program (ADRAP) podem ajudar a evitar problemas de indisponibilidade e consequentemente perda de produtividade no seu ambiente Windows e aplicações dependentes.
Para maiores informações sobre ADRAP consulte o link abaixo: https://download.microsoft.com/download/5/8/e/58ededaf-4de0-4fd3-b500-8a8f6bbfe1f4/ADRAP_Datasheet_v1.0t_English.pdf