Windows 10: a diretiva de grupo falha ao aplicar-se diretamente após a inicialização, é bem-sucedida posteriormente

Meu problema é que a Diretiva 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 a origem "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 uma questão esté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 são exibidas.

O cenário mais simples em que pude reproduzir o problema: O domínio recém-criado no Windows Server 2012R2 recém-instalado, o cliente é uma máquina de 64 bits do Windows 10 recém-instalada. O domínio consiste em apenas um controlador de 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 no 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 o seguinte:

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

Depois de esperar um minuto ou dois, executar o mesmo comando fornecerá uma lista de diretórios. A execução do gpupdate neste momento funcionará bem.

Eu defini a configuração de Diretiva de Grupo "Sempre aguarde a rede na inicialização e no logon do computador" como "Ativado" e sei que essa diretiva é aplicada: no mesmo objeto de diretiva, uma configuração de Registro é especificada e quando eu checo 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, atualizando políticas e reinicializando 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 suporta Atualizações Dinâmicas. Os registros necessários foram adicionados manualmente (em C: \ Windows \ System32 \ config \ netlogon.dns)
• A hibernação é 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 de processamento da política de inicialização da política é definido como 120 segundos
• A conectividade com o DC funciona bem. Pings vai funcionar. Desligar o cliente, desabilitar minha conta no AD, ativar o cliente fará com que o cliente não faça o logon: ele notará imediatamente que a conta está desabilitada.
• Além desse problema, não percebo nada fora do comum.

Parece ser mais um problema de SMB do que um problema de Diretiva de Grupo. Detectar a conexão no lado do servidor mostra algo interessante: Na primeira vez em que executo o comando dir \\domain.example.com\sysvol, o seguinte é exibido no Microsoft Message Analyzer no controlador de domínio :

1. O cliente configura uma conexão TCP à porta 445 do controlador de domínio e uma negociação comum é executada com êxito (DialectRevision: 0x02FF).
2. Imediatamente depois disso, um Negociar é realizado com sucesso. A 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 obtenho 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, um TreeConnect e muitas conversas SMB (aparentemente normais).

Portanto, parece que, de alguma forma, o cliente não conversará adequadamente o SMB com o controlador de domínio até um ou dois minutos após a inicialização, e isso causará falha no processamento da Diretiva de Grupo.

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

A partir do Windows 8, a Microsoft introduziu essa noção de "inicialização rápida", na qual, quando você desliga o sistema operacional, eles hibernam o consumo de memória do sistema operacional da mesma forma que o Hibernate trabalha em cenários normais de hibernação. Isso resulta em um SO mais rápido, mas também tem o efeito colateral de desativar o processamento GP por computador na inicialização. Provavelmente é isso que você está vendo e isso pode ser desativado desativando a diretiva em Configuração do Computador \ Diretivas \ Modelos Administrativos \ Sistema \ Desligamento \ Requer o uso de inicialização rápida

Se isso não resolver o problema, é mais provável que seja um problema de sincronização da pilha de rede, em que o processamento GP para o computador começará antes que a pilha de rede seja totalmente inicializada. Isso existe desde o XP e a partir do Windows 7, a Microsoft adicionou uma diretiva em Configuração do Computador \ Diretivas \ Modelos Administrativos \ Sistema \ Diretiva de Grupo \ Tempo de Espera de Processamento da Diretiva 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

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

Primeiro, eu estava errado ao desabilitar todos os bloqueios do NTLM resultando nos mesmos sintomas. Isso resultou em um sintoma diferente , que passou a ter o mesmo efeito. Sem nenhuma política de bloqueio do NTLM em vigor, o dircomando agora resultou em um erro de acesso negado. A Diretiva 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 sabia que tinha um problema mais comum. Apesar. Aparentemente, os clientes 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 algo na maneira 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 Diretiva de Grupo "Hardened UNC Paths" para os clientes Windows 10 como este:

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

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

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, além de 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 MS15-011 criado para! Não apenas copie / cole 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 MS15-011.

Tentei várias sugestões, incluindo alterações no registro e alterações na política de grupo local, nenhuma das quais resolveu as unidades mapeadas por problemas ainda estavam com o X inicializado. Um gpupdate o corrigia todas as vezes, mas essa era uma etapa adicional para o usuário.

O que acabou consertando foi o mapeamento manual das unidades de rede, substituindo as entradas de GPO em cada uma delas. Não há necessidade de desconectar e substituir; eu os mapei da mesma forma que foram mapeados, apenas manualmente.

Apenas para sua informação, para qualquer pessoa que encontre esse segmento, desativar o fortalecimento UNC através da configuração de autenticação mútua como 0 está desativando parte da sua segurança. Estamos executando o mesmo problema com os clientes win7 e eu estava tentando trabalhar com a Microsoft. Eles me disseram que é um bug, mas até agora não me deram uma maneira de rastrear quando o bug será solucionado.

Consulte este outro tópico para obter 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