Por que un portátil con Protected Users necesita a VPN antes de iniciar sesión

Un portátil, unha conta operativa e unha rede de hotel suman un bucle de inicio de sesión que ningún reintento rompe. A conta está en Protected Users, o que impide que Windows garde o verificador que necesitaría para autenticar o usuario sen conexión. Calquera plan do tipo «inicie sesión primeiro, conecte o túnel despois» ten a orde invertida, e a protección fai exactamente o que promete. O seguinte supón unha conta tradicional de Active Directory nun host de Windows compatible.

Que elimina realmente a protección

Normalmente Windows almacena na caché un verificador para que unha conta de dominio poida iniciar sesión mentres un controlador de dominio non é accesible. Protected Users bloquéao para a conta, o que elimina o inicio de sesión de dominio sen conexión como posibilidade en lugar de facelo pouco fiábel.

Non é o problema habitual dunha caché obsoleta, e os remedios habituais non se aplican. Iniciar sesión en liña repetidamente, cambiar o contrasinal outra vez ou elevar o reconto de inicios de sesión almacenados non restauran a capacidade, porque ningunha desas accións crea o verificador que a política se nega a gardar. A conta compórtase como está deseñada, e o deseño supón que a rede está presente cando Windows a pide. Tratar o síntoma como un fallo de caché é como os equipos acaban reconstruíndo un perfil que nunca estivera roto.

Por que o túnel debe existir antes do escritorio

O dispositivo ten que alcanzar a autenticación de dominio no momento en que Windows a pide, que é antes de que exista calquera sesión de usuario. Un cliente VPN que só arrinca cando aparece o escritorio deixa un inicio de sesión novo esperando unha ruta que nunca chega. A dependencia pertence á máquina, non a un usuario que aínda non iniciou sesión.

Use un esquema compatible de inicio de sesión previo acordado cos responsables dos puntos finais e da identidade. Un túnel de dispositivo Always On VPN autenticado cun certificado de equipo cumpre o requisito cando o dispositivo xestionado satisfai os requisitos previos dese despregamento. A integración compatible dun provedor na pantalla de inicio de sesión é outra opción. Un perfil de usuario corrente cun disparador automático non é ningunha das dúas, por moito que se pareza na interface do cliente.

O que esa ruta necesita é resolución de nomes para o dominio, un controlador de dominio alcanzable e os protocolos de autenticación que a conta poida usar, e ningún indicador de «conectado» proporciona nada diso. As súas rutas e filtros deben transportar os servizos de identidade e nada máis que non sexa necesario, porque esa lista de prefixos é a superficie que obtén un portátil roubado antes de que ninguén inicie sesión. As decisións de túnel dividido tomadas para o túnel de usuario non se trasladan ao túnel de dispositivo, así que revise ambos por separado.

A alcanzabilidade non é compatibilidade de autenticación

Un túnel pode transportar paquetes perfectamente mentres a autenticación de dominio falla, porque o mecanismo que se intenta é un que a conta non pode usar. Nun dominio que aplica as restricións do grupo, NTLM non está dispoñible para os membros e Kerberos necesita unha conta e unha configuración compatibles con AES. Unha ruta de paquetes non pode reparar ningunha das dúas. Por iso un ping limpo a un controlador de dominio non é proba de que o inicio de sesión vaia funcionar.

Tamén poden intervir dous sistemas de credenciais. A VPN pode autenticarse contra un provedor de identidade mentres Windows necesita por separado un inicio de sesión de dominio, e a aceptación do primeiro non di nada do segundo. «A VPN conectouse» e «o usuario iniciou sesión» son observacións separadas, e arranxar unha non implica a outra.

Lea as evidencias de autenticación

Recolla eventos do cliente e dun controlador de dominio para o mesmo intento, non só dun lado. Os rexistros de Protected Users están en Applications and Services Logs\Microsoft\Windows\Authentication, e pode que un administrador teña que activar un rexistro antes de que rexistre algo. Correlacione as marcas de tempo co rexistro de conexión do propio túnel, porque un erro de orde parece un fallo de credenciais desde calquera dos dous lados.

O primeiro comando de abaixo enumera todos os rexistros de autenticación que o dispositivo expón, así que lea o que existe e non o que nomeou unha entrada de blog. O segundo le as entradas recentes unha vez que coñece o nome. Busque o paquete de autenticación, a conta e a condición de fallo, porque unha ruta de rede ausente e un mecanismo rexeitado deixan evidencias distintas e só unha delas é un problema de VPN. Se o túnel subiu despois do intento, a orde era incorrecta digan o que digan esas entradas.

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

Demostre o límite desde un arranque en frío

Executa a proba desde un estado pechado ou acabado de arrincar cunha conta limitada, e manteña aberta unha ruta de recuperación aprobada antes de cambiar nada para os usuarios privilexiados. Unha proba nun escritorio xa en marcha non exercita ningunha parte da ruta de código que importa, e iso explica a maioría dos informes dunha corrección que aguantou ata o seguinte reinicio. Despois percorra os catro pasos nesta orde.

1. Confirme que o dispositivo pode atopar un controlador de dominio antes de que ninguén inicie sesión, con nltest /dsgetdc:corp.example.com.
2. Intente o inicio de sesión de dominio e despois pregunte se se obtivo algún ticket, con klist.
3. Lea o rexistro de autenticación que rexistra o dispositivo, cos dous comandos de arriba, e anote o paquete e a condición de fallo.
4. Confirme que a credencial de recuperación aprobada segue funcionando desde a pantalla de inicio de sesión, porque é a única forma de volver se a proba do límite falla.

Abrir un recurso compartido con credenciais proporcionadas tampouco crea un inicio de sesión interactivo sen conexión, así que non substitúe ningún paso de arriba. Se a organización necesita de verdade iniciar sesión desconectada, a resposta é un deseño compatible de conta e punto final elixido deliberadamente. Sacar a conta do grupo, ou manter un inicio de sesión de emerxencia sen restricións en cada portátil, é unha decisión de política de identidade que un cambio de VPN non pode tomar por vostede.

A documentación de Protected Users describe tanto o comportamento do verificador como as restricións de dominio das que depende este deseño. Planifique o proceso de recuperación antes de que ninguén viaxe, porque a proba de arranque en frío é o único lugar onde se exercita.