Falta a diretiva de grupo na VPN? Verifique o âmbito antes do túnel

Algo que se aplicava na rede do escritório deixa de se aplicar na semana em que um utilizador começa a trabalhar por VPN, e o túnel leva a culpa antes de alguém abrir um relatório. A diretiva de grupo decide que definições chegam ao utilizador e ao computador Windows, vai buscar o material ao domínio e executa o processamento do lado do cliente, e estes três passos falham de três formas diferentes. O túnel só muda o caminho que o cliente tem. Percorrer as verificações por ordem evita que um problema de permissões de ficheiros seja perseguido como um problema de encaminhamento.

Comece pela definição, não pelo túnel

Anote uma GPO esperada e uma definição concreta dentro dela, e depois decida se essa definição vive na Configuração de Utilizador ou na Configuração de Computador. Isto pressupõe um cliente Windows autorizado e associado ao domínio numa VPN aprovada, não um dispositivo não gerido ou apenas na nuvem que é convertido em membro do domínio. A resposta sobre o âmbito decide quem pode ler o resultado e se é necessária elevação, por isso resolva isso antes de executar seja o que for.

Pergunte ao administrador do domínio que ligação, localização de objeto, filtros de segurança e filtros WMI devem estar em jogo. Alterar esses controlos para que um teste passe é outro projeto com outro responsável.

Leia o relatório com a conta a quem pertence a definição

Na sessão do próprio utilizador afetado, execute whoami /user e depois gpresult /scope user /r. A conta que autenticou a VPN não é automaticamente a conta Windows cuja diretiva está a ler, e uma verificação a partir de uma conta de administrador responde a outra pergunta. Guarde a linha de base com um novo nome de ficheiro, como %TEMP%\vpn-policy-user-before.html. A referência do gpresult documenta os comutadores de âmbito e de saída, e vale a pena saber que gerar um relatório não atualiza nada.

A diretiva de computador tem o seu próprio âmbito e contexto de permissões, por isso inspecione-a em separado com a elevação necessária. Juntar os dois âmbitos num só relatório é a forma como uma definição de utilizador é declarada em falta quando nunca esteve nesse âmbito.

A descoberta não é acesso: primeiro os registos SRV, depois SMB

Com a VPN aprovada ligada, confirme que o cliente resolve os controladores de domínio pelo caminho DNS previsto; um site público que carrega não diz nada sobre a descoberta de controladores. Para o domínio ilustrativo corp.example, nslookup -type=SRV _ldap._tcp.dc._msdcs.corp.example responde à pergunta que realmente tem. Um registo de serviço devolvido é apenas prova de descoberta, porque o endereço do controlador selecionado ainda tem de ser alcançável com a autenticação exigida e os serviços de diretório permitidos. O material da diretiva chega depois do SYSVOL, que é uma leitura SMB contra esse controlador concreto e não um teste ICMP.

Uma prova mais fraca confunde-se facilmente com uma prova. Uma resposta ICMP de um controlador, ao lado de uma leitura recusada de um modelo de diretiva, produz um relatório que parece vazio por uma razão que ninguém ligou ainda.

Mantenha coerentes as permissões do serviço AD, os caminhos de retorno e a sincronização horária da implementação, em vez de as substituir por uma abertura geral da firewall ou um servidor DNS público. Os dados de diretiva que diferem entre controladores são uma questão de replicação para o proprietário do diretório.

Uma atualização, dois relatórios, uma comparação

Com o caminho provado, peça a atualização relevante com gpupdate /target:user e leia o resultado em vez de o assumir. A atualização predefinida aplica a diretiva alterada enquanto /force pede uma reaplicação; nenhuma das duas corrige DNS, permissões de ficheiros ou filtragem. Algumas extensões só ficam concluídas num início de sessão posterior ou noutro evento em primeiro plano, por isso uma única execução não é um veredicto. Acrescentar comutadores de terminação de sessão ou reinício à sessão de um utilizador remoto como diagnóstico de rotina deita fora o que ele tinha aberto.

Gere um segundo relatório com outro nome de ficheiro e compare o tempo de processamento, a GPO esperada, o seu estado aplicado ou recusado e a própria definição. Um relatório de uma sessão anterior bem-sucedida não prova nada sobre esta atualização. Uma diretiva filtrada aponta para a aplicabilidade e não para o transporte, o que muda quem é dono do passo seguinte.

Ligue a falha a uma única atividade

No Visualizador de Eventos, comece pelo aviso ou erro de diretiva de grupo no registo do sistema e depois passe ao registo operacional GroupPolicy em Registos de Aplicações e Serviços. Filtre esse registo operacional pelo identificador de atividade da atualização que acabou de executar, porque uma atualização nova recebe um identificador novo e misturá-lo com os eventos de ontem produz uma conclusão confiante e errada. Registe a hora, o contexto de utilizador ou computador, o controlador selecionado, a GPO, o código de erro e a dependência falhada.

Esse registo é aquilo sobre o que o proprietário da rede ou do diretório pode agir. Estar ligado à VPN e ter executado gpupdate várias vezes não são provas, e nenhuma das duas sobrevive a uma passagem de testemunho.

Mantenha os relatórios HTML privados, porque expõem nomes internos, pertenças a grupos e configuração de segurança. Uma vez confirmada a definição, remova as permissões temporárias que acrescentou em vez de as deixar no lugar.