Windows 10: A Diretiva de Grupo não se aplica diretamente após a inicialização, é bem-sucedida mais tarde

Question

Meu problema é que a Política de Grupo não é aplicada quando um cliente é inicializado recentemente. Diretamente após a inicialização, o cliente envia uma mensagem de erro no log de eventos com a fonte "GroupPolicy (Microsoft-Windows-GroupPolicy)" e a ID do Evento 1058: "O processamento da Diretiva de Grupo falhou.". Na guia Detalhes, o ErrorCode é 50, que significa ERROR_NOT_SUPPORTED. Não é apenas um problema cosmético: as políticas realmente não são aplicadas corretamente: as unidades de rede mapeadas não estão lá, por exemplo. Depois de esperar um tempo, a execução de "gpupdate" funciona e as políticas são aplicadas normalmente: as unidades de rede mapeadas aparecem.

O cenário mais simples no qual eu consegui reproduzir o problema: Domínio recém-criado no recém-instalado Windows Server 2012R2, cliente é uma máquina Windows 10 de 64 bits recém-instalada. O domínio consiste apenas no controlador de um domínio e não possui nenhuma relação com outros domínios.

Como a mensagem de erro informa que o Windows não pode ler um arquivo .GPT do compartilhamento Sysvol do domínio, tentei acessar o mesmo arquivo a partir de um prompt de comando. E, de fato, quando eu abro um Prompt de Comando logo após a inicialização, recebo isso:

C:\Users\username>dir \domain.example.com\sysvol
The request is not supported.

Depois de esperar um minuto ou dois, a execução do mesmo comando fornecerá uma listagem de diretórios. Executar o gpupdate neste ponto funcionará bem.

Eu defini a configuração da Diretiva de Grupo "Sempre aguarde a rede na inicialização e no logon do computador" para "Ativada" e sei que essa diretiva é aplicada: no mesmo objeto de diretiva, uma configuração do Registro é especificada e quando verifique o registro no cliente a configuração especificada está lá.

Outros fatores que podem ser relevantes:

• O NTLM é restrito no domínio, mas isso não parece importar: mesmo depois de ativá-lo, atualizar políticas e reinicializar todas as máquinas, os sintomas permanecem os mesmos.
• Não importa se o servidor está configurado usando DHCP ou com uma configuração estática.
• O servidor DNS do domínio não oferece suporte a atualizações dinâmicas. Os registros necessários foram adicionados manualmente (em C: \ Windows \ System32 \ config \ netlogon.dns)
• A hibernação está desativada no cliente (usando powercfg /h off ), portanto, cada inicialização é uma inicialização completa, não uma inicialização rápida
• O tempo de espera do processamento da política de inicialização da política está definido como 120 segundos
• A conectividade ao DC funciona bem. Pings vai funcionar. Desativar o cliente, desabilitar minha conta no AD, ativar o cliente fará com que o cliente não me conecte: ele notará imediatamente que a conta está desativada.
• Além dessa questão, não vejo nada fora do comum.

Esta parece ser mais uma questão de SMB do que uma questão de política de grupo. Farejar a conexão no lado do servidor mostra algo interessante: Na primeira vez que executo o comando dir \domain.example.com\sysvol , o seguinte mostra no Microsoft Message Analyzer no DC:

1. O cliente configura uma conexão TCP com a porta 445 do DC e uma ComNegotiation é realizada com sucesso (DialectRevision: 0x02FF).
2. Imediatamente depois disso, um Negotiate é realizado com sucesso. o DialectRevision é 0x0302.
3. Imediatamente depois disso, o cliente fecha a conexão TCP com um TCP RST (??)

Toda vez que eu emito o comando e recebo o erro, as etapas 2 e 3 ocorrem.

Quando o comando começa a funcionar, as etapas 1 e 2 ocorrem, mas em vez de o cliente enviar um TCP RST, um SessionSetup é executado, depois ocorre um TreeConnect e, em seguida, um monte de conversas SMB (aparentemente normais).

Assim, parece que, de alguma forma, o cliente não irá falar adequadamente com o SMB ao DC até um ou dois minutos após o boot, o que faz com que o processamento da Diretiva de Grupo falhe.

Alguém sabe como posso depurar e resolver esse problema?

    

Answer 1

Eu consegui resolver esse problema sozinho. Para referência aqui está o que resolveu meu problema:

Primeiro, eu estava errado em que desabilitar todos os bloqueios do NTLM resultou nos mesmos sintomas. Resultou em um sintoma diferente , que por acaso teve o mesmo efeito. Sem quaisquer diretivas de bloqueio do NTLM em vigor, o comando dir agora resultava em um erro de acesso negado. A Política de Grupo ainda não se aplica, o que faz sentido: o SYSVOL ainda não estava acessível.

Um pouco de pesquisa na web me disse que eu sei que tinha um problema mais comum. Apesar. Aparentemente, os clientes do Windows 10 podem ter problemas para acessar o compartilhamento SYSVOL dos controladores de domínio (e talvez o compartilhamento NETLOGON também). Supostamente, o Windows 10 mudou alguma coisa na maneira como ele acessa esses compartilhamentos, o que pode resultar em problemas. A solução alternativa é desabilitar o Restabelecimento de Caminho UNC no cliente para esses compartilhamentos, definindo a Diretiva de Grupo "Caminhos UNC Endurecidos" para os clientes do Windows 10 da seguinte forma:

\*\SYSVOL RequireMutualAuthentication=0,RequireIntegrity=0,RequirePrivacy=0
\*\NETLOGON RequireMutualAuthentication=1,RequireIntegrity=1

(Se você estiver tendo problemas para acessar o compartilhamento Netlogon de clientes Windows 10, pode ajudar a definir todos os três parâmetros como zero para esse compartilhamento também.)

Consulte o artigo da Microsoft sobre o MS15-011 para obter mais informações. Ele contém uma boa descrição das implicações de segurança de alterar essa configuração, bem como etapas detalhadas de como alterar a política.

Aviso : observe que as configurações acima desativam algumas ou todas as proteções contra o problema de segurança para o qual o MS15-011 foi criado. Não copie / cole cegamente, mas tome uma decisão informada com base nos riscos envolvidos. Além disso, esse problema provavelmente será resolvido em algum momento no futuro. Quando isso acontecer, não se esqueça de definir essa política para os valores recomendados, conforme descrito no boletim MS15-011.

    

Answer 2

Começando com o Windows 8, a Microsoft introduziu essa noção de "inicialização rápida", em que, quando você encerra o SO, eles hibernam a memória do sistema operacional da mesma forma que o Hibernate funciona em cenários normais de hibernação. Isso resulta no sistema operacional mais rápido, mas também tem o efeito colateral de desativar o processamento GP por computador na inicialização. Isso é provavelmente o que você está vendo e isso pode ser desabilitado, desabilitando a política em Configuração do Computador \ Políticas \ Modelos Administrativos \ Sistema \ Desligamento \ Requer o uso de inicialização rápida

Se isso não resolver o problema, é mais provável que ocorra um problema de temporização de pilha de rede, no qual o processamento de GP para o computador está sendo desativado antes que a pilha de rede seja totalmente inicializada. Isso ocorre desde o XP e, a partir do Windows 7, a Microsoft adicionou uma política em Configuração do Computador \ Políticas \ Modelos Administrativos \ Sistema \ Diretiva de Grupo \ Tempo de Espera do Processamento de Políticas de Inicialização, onde você pode aumentar o tempo que o GP aguarda antes de iniciar. Tente configurá-lo para 60 segundos e ver se isso ajuda.

Darren

    

Answer 3

Eu tentei várias sugestões, incluindo alterações no registro e alterações na política de grupo local, nenhuma das quais resolveu o problema - as unidades mapeadas ainda eram eliminadas na inicialização. Um gpupdate consertaria isso toda vez, mas isso era um passo adicional para o usuário.

O que acabou corrigindo foi mapear manualmente as unidades de rede, substituindo as entradas de GPO em cada uma delas. Não há necessidade de desconectar e substituir, eu os mapeei da mesma forma que eles foram mapeados, apenas manualmente.

    

Answer 4

Apenas para todas as pessoas que encontrarem este tópico, desativar o hardening UNC via configuração auth mútua como 0 está desativando parte da sua segurança. Estamos executando o mesmo problema com clientes win7, e eu estava tentando trabalhar com a Microsoft nele. Eles me disseram que é um bug, mas até agora não me deram uma maneira de rastrear quando o bug será corrigido.

Veja este outro tópico para mais informações link