Windows 10: a Política de Grupo não é aplicada diretamente após a inicialização, mas é 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 publica uma mensagem de erro no log de eventos com origem "GroupPolicy (Microsoft-Windows-GroupPolicy)" e ID de evento 1058: "Falha no processamento da Política de Grupo. [...]". Na guia Detalhes, o ErrorCode é 50, que significa ERROR_NOT_SUPPORTED. Não é apenas uma questão cosmética: 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 pouco, 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 em que consegui reproduzir o problema: Domínio recém-criado no Windows Server 2012R2 recém-instalado, o cliente é uma máquina Windows 10 de 64 bits recém-instalada. O domínio consiste em apenas um controlador de domínio e não tem nenhuma relação com outros domínios.

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

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

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

Eu configurei a configuração de Política de Grupo "Sempre esperar pela rede na inicialização e logon do computador" como "Ativado" e sei que esta política é aplicada: no mesmo objeto de política uma configuração de Registro é especificada e quando verifico 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 habilitá-lo, atualizar as 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 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 (de C:\Windows\System32\config\netlogon.dns)
• A hibernação está desabilitada no cliente (usando powercfg /h off), então cada inicialização é uma inicialização completa, não uma inicialização rápida
• A política Tempo de espera de processamento da política de inicialização está definida como 120 segundos
• A conectividade com o DC funciona bem. Os pings funcionarão. Desligar o cliente, desabilitar minha conta no AD, ligar o cliente fará com que o cliente não me faça login: ele percebe imediatamente que a conta está desabilitada.
• Além desse problema, não noto nada fora do comum.

Este parece ser mais um problema de SMB do que um problema 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 é exibido no Microsoft Message Analyzer no DC:

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

Sempre que emito o comando e recebo o erro, ocorrem as etapas 2 e 3.

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 um TreeConnect e, em seguida, ocorre muita conversa SMB (aparentemente normal).

Portanto, parece que de alguma forma o cliente não comunicará corretamente o SMB com o DC até um ou dois minutos após a inicialização, e isso causa falha no processamento da Política de Grupo.

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

Answer 1

Começando com o Windows 8, a Microsoft introduziu esta noção de "inicialização rápida", onde, quando você desliga o sistema operacional, eles hibernam o consumo de memória do sistema operacional, assim como o Hibernate funciona em cenários normais de hibernação. Isso faz com que o sistema operacional fique mais rápido, mas também tem o efeito colateral de desabilitar o processamento GP por computador na inicialização. Provavelmente é isso que você está vendo e pode ser desabilitado desabilitando a política em Configuração do Computador\Políticas\Modelos Administrativos\Sistema\Desligamento\Exigir uso de inicialização rápida

Se isso não resolver o problema, provavelmente é um problema de tempo de pilha de rede, em que o processamento GP do computador é iniciado antes que a pilha de rede seja totalmente inicializada. Isso existe 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\Política de Grupo\Tempo de espera de processamento da política de inicialização onde você pode aumentar o tempo que o GP espera antes de iniciar. Tente configurá-lo para 60 segundos e veja se isso ajuda.

Darren

Answer 2

Eu consegui resolver esse problema sozinho. Parareferênciaaqui está o que resolveu meu problema:

Primeiro, eu estava errado ao dizer que desabilitar todo o bloqueio do NTLM resultou nos mesmos sintomas. Resultou em umdiferentesintoma, que teve o mesmo efeito. Sem nenhuma política de bloqueio NTLM em vigor, o dircomando agora resultava em um erro de acesso negado. A Política de Grupo ainda não se aplicaria, 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. no entanto. Aparentemente, os clientes Windows 10 podem ter problemas para acessar o compartilhamento SYSVOL dos controladores de domínio (e talvez também o compartilhamento NETLOGON). Supostamente o Windows 10 mudou algo na forma como acessa esses compartilhamentos, o que pode resultar em problemas. A solução alternativa é desabilitar o UNC Path Hardening no cliente para esses compartilhamentos, definindo a Política de Grupo "Hardened UNC Paths" para os clientes Windows 10 assim:

\\*\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, isso também pode ajudar a definir todos os três parâmetros como zero para esse compartilhamento.)

Veja oartigo da Microsoft sobre MS15-011Para maiores informações. Ele contém uma boa descrição das implicações de segurança da alteração dessa configuração, bem como etapas detalhadas de como alterar a política.

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

Answer 3

Apenas para sua informação, para qualquer pessoa que encontrar este tópico, desativar o fortalecimento UNC por meio da configuração de autenticação mútua como 0 está desativando parte da sua segurança. Estamos enfrentando o mesmo problema com clientes win7 e eu estava tentando trabalhar com a Microsoft nisso. Eles me disseram que é um bug, mas até agora não me deram uma maneira de saber quando o bug será resolvido.

Veja este outro tópico para mais informações https://social.technet.microsoft.com/Forums/en-US/6a20e3f6-728a-4aa9-831a-6133f446ea08/gpos-do-not-apply-on-windows-10-enterprise-x64

Answer 4

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 estavam com X na inicialização. Um gpupdate sempre resolveria isso, mas essa era uma etapa adicional para o usuário.

O que acabou resolvendo 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 foram mapeados, apenas manualmente.