Por que um portátil com Protected Users precisa da VPN antes do início de sessão

Um portátil, uma conta funcional e uma rede de hotel juntos formam um ciclo de início de sessão que nenhuma nova tentativa quebra. A conta está no Protected Users, o que impede o Windows de guardar o verificador de que precisaria para autenticar o utilizador offline. Qualquer plano do tipo «inicie sessão primeiro, ligue o túnel depois» tem a ordem invertida, e a proteção faz exatamente o que promete. O que se segue pressupõe uma conta tradicional do Active Directory num anfitrião Windows suportado.

O que a proteção realmente remove

Normalmente o Windows coloca um verificador em cache para que uma conta de domínio possa iniciar sessão enquanto um controlador de domínio está inacessível. O Protected Users bloqueia isso para a conta, o que remove o início de sessão de domínio offline como possibilidade em vez de o tornar pouco fiável.

Este não é o problema habitual de uma cache desatualizada, e os remédios habituais não se aplicam. Iniciar sessão online repetidamente, mudar a palavra-passe outra vez ou aumentar a contagem de inícios de sessão em cache não restauram a capacidade, porque nenhuma dessas ações cria o verificador que a política se recusa a guardar. A conta comporta-se como foi concebida, e a conceção assume que a rede está presente quando o Windows a pede. Tratar o sintoma como uma falha de cache é a forma como as equipas acabam a reconstruir um perfil que nunca esteve avariado.

Por que o túnel tem de existir antes do ambiente de trabalho

O dispositivo tem de alcançar a autenticação de domínio no momento em que o Windows a pede, o que acontece antes de existir qualquer sessão de utilizador. Um cliente VPN que só arranca depois de o ambiente de trabalho aparecer deixa um novo início de sessão à espera de um caminho que nunca chega. A dependência pertence à máquina, não a um utilizador que ainda não iniciou sessão.

Use um esquema suportado de pré-início de sessão, acordado com os responsáveis dos pontos finais e da identidade. Um túnel de dispositivo Always On VPN autenticado com um certificado de computador qualifica-se quando o dispositivo gerido cumpre os pré-requisitos dessa implementação. A integração suportada de um ecrã de início de sessão por um fornecedor é outra opção. Um perfil de utilizador comum com um acionador automático não é nenhum dos dois, por muito parecido que pareça na interface do cliente.

Esse caminho precisa de resolução de nomes para o domínio, de um controlador de domínio alcançável e dos protocolos de autenticação que a conta pode usar, e nenhum indicador de «ligado» fornece nada disso. As suas rotas e filtros devem transportar os serviços de identidade e nada mais que não seja necessário, porque essa lista de prefixos é a superfície que um portátil roubado obtém antes de alguém iniciar sessão. As decisões de túnel dividido tomadas para o túnel de utilizador não passam para o túnel de dispositivo, por isso reveja os dois em separado.

Alcançabilidade não é compatibilidade de autenticação

Um túnel pode transportar pacotes na perfeição enquanto a autenticação de domínio falha, porque o mecanismo tentado é um que a conta não pode usar. Num domínio que aplica as restrições do grupo, o NTLM não está disponível para os membros e o Kerberos requer uma conta e uma configuração compatíveis com AES. Um caminho de pacotes não consegue reparar nenhum deles. É por isso que um ping limpo a um controlador de domínio não é prova de que o início de sessão vai funcionar.

Podem também estar em jogo dois sistemas de credenciais. A VPN pode autenticar-se contra um fornecedor de identidade enquanto o Windows necessita separadamente de um início de sessão de domínio, e a aceitação pelo primeiro nada diz sobre o segundo. «A VPN ligou-se» e «o utilizador iniciou sessão» são observações distintas, e corrigir uma não implica a outra.

Leia as evidências de autenticação

Recolha eventos do cliente e de um controlador de domínio para a mesma tentativa, e não apenas de um lado. Os registos do Protected Users estão em Applications and Services Logs\Microsoft\Windows\Authentication, e um administrador pode ter de ativar um registo antes de este registar algo. Relacione os carimbos temporais com o registo de ligação do próprio túnel, porque um erro de ordem parece uma falha de credenciais de ambos os lados.

O primeiro comando abaixo lista todos os registos de autenticação que o dispositivo expõe, para que leia o que existe e não o que um texto de blogue nomeou. O segundo lê as entradas recentes depois de saber o nome. Procure o pacote de autenticação, a conta e a condição de falha, porque um caminho de rede ausente e um mecanismo rejeitado deixam evidências diferentes e só uma delas é um problema de VPN. Se o túnel subiu depois da tentativa, a ordem estava errada digam o que disserem essas entradas.

Get-WinEvent -ListLog *Authentication*
Get-WinEvent -LogName Microsoft-Windows-Authentication/Operational -MaxEvents 20

Prove o limite a partir de um arranque a frio

Execute o teste a partir de um estado terminado ou acabado de arrancar com uma conta limitada, e mantenha aberta uma via de recuperação aprovada antes de alterar o que quer que seja para utilizadores privilegiados. Um teste num ambiente de trabalho já em execução não exercita nenhuma parte do caminho de código que importa, e isso explica a maioria dos relatos de uma correção que aguentou até ao reinício seguinte. Depois percorra os quatro passos nesta ordem.

1. Confirme que o dispositivo consegue encontrar um controlador de domínio antes de alguém iniciar sessão, com nltest /dsgetdc:corp.example.com.
2. Tente o início de sessão de domínio e depois pergunte se foi obtido algum bilhete, com klist.
3. Leia o registo de autenticação que o dispositivo grava, com os dois comandos acima, e anote o pacote e a condição de falha.
4. Confirme que a credencial de recuperação aprovada ainda funciona a partir do ecrã de início de sessão, porque é a única via de regresso se o teste do limite falhar.

Abrir uma partilha de ficheiros com credenciais fornecidas também não cria um início de sessão interativo offline, pelo que não substitui nenhum dos passos acima. Se a organização precisa mesmo de início de sessão sem ligação, a resposta é uma conceção compatível de conta e ponto final escolhida deliberadamente. Retirar a conta do grupo, ou manter um início de sessão de emergência sem restrições em cada portátil, é uma decisão de política de identidade que uma alteração de VPN não pode tomar por si.

A documentação do Protected Users descreve tanto o comportamento do verificador como as restrições de domínio de que esta conceção depende. Planeie o processo de recuperação antes de alguém viajar, porque o teste de arranque a frio é o único lugar onde é exercitado.