Por qué un portátil con Protected Users necesita la VPN antes de iniciar sesión

Un portátil, una cuenta operativa y una red de hotel suman un bucle de inicio de sesión que ningún reintento rompe. La cuenta está en Protected Users, lo que impide que Windows guarde el verificador que necesitaría para autenticar al usuario sin conexión. Cualquier plan del tipo «inicie sesión primero, conecte el túnel después» tiene el orden invertido, y la protección hace exactamente lo que promete. Lo siguiente supone una cuenta tradicional de Active Directory en un host de Windows compatible.

Qué elimina realmente la protección

Normalmente Windows almacena en caché un verificador para que una cuenta de dominio pueda iniciar sesión mientras un controlador de dominio no es accesible. Protected Users lo bloquea para la cuenta, lo que elimina el inicio de sesión de dominio sin conexión como posibilidad en lugar de hacerlo poco fiable.

No es el problema habitual de una caché obsoleta, y los remedios habituales no se aplican. Iniciar sesión en línea repetidamente, cambiar la contraseña otra vez o elevar el recuento de inicios de sesión almacenados no restaurarán la capacidad, porque ninguna de esas acciones crea el verificador que la directiva se niega a guardar. La cuenta se comporta como está diseñada, y el diseño supone que la red está presente cuando Windows la pide. Tratar el síntoma como un fallo de caché es como los equipos acaban reconstruyendo un perfil que nunca estuvo roto.

Por qué el túnel debe existir antes del escritorio

El dispositivo tiene que alcanzar la autenticación de dominio en el momento en que Windows la pide, que es antes de que exista cualquier sesión de usuario. Un cliente VPN que solo arranca cuando aparece el escritorio deja un inicio de sesión nuevo esperando una ruta que nunca llega. La dependencia pertenece a la máquina, no a un usuario que aún no ha iniciado sesión.

Use un esquema compatible de inicio de sesión previo acordado con los responsables de los puntos finales y de la identidad. Un túnel de dispositivo Always On VPN autenticado con un certificado de equipo cumple el requisito cuando el dispositivo administrado satisface los prerrequisitos de ese despliegue. La integración compatible de un proveedor en la pantalla de inicio de sesión es otra opción. Un perfil de usuario corriente con un desencadenador automático no es ninguna de las dos, por mucho que se parezca en la interfaz del cliente.

Lo que esa ruta necesita es resolución de nombres para el dominio, un controlador de dominio alcanzable y los protocolos de autenticación que la cuenta pueda usar, y ningún indicador de «conectado» proporciona nada de eso. Sus rutas y filtros deben transportar los servicios de identidad y nada más que no sea necesario, porque esa lista de prefijos es la superficie que obtiene un portátil robado antes de que nadie inicie sesión. Las decisiones de túnel dividido tomadas para el túnel de usuario no se trasladan al túnel de dispositivo, así que revise ambos por separado.

La alcanzabilidad no es compatibilidad de autenticación

Un túnel puede transportar paquetes perfectamente mientras la autenticación de dominio falla, porque el mecanismo que se intenta es uno que la cuenta no puede usar. En un dominio que aplica las restricciones del grupo, NTLM no está disponible para los miembros y Kerberos necesita una cuenta y una configuración compatibles con AES. Una ruta de paquetes no puede reparar ninguna de las dos cosas. Por eso un ping limpio a un controlador de dominio no es prueba de que el inicio de sesión vaya a funcionar.

También pueden intervenir dos sistemas de credenciales. La VPN puede autenticarse contra un proveedor de identidad mientras Windows necesita por separado un inicio de sesión de dominio, y la aceptación del primero no dice nada del segundo. «La VPN se ha conectado» y «el usuario ha iniciado sesión» son observaciones separadas, y arreglar una no implica la otra.

Lea las evidencias de autenticación

Recoja eventos del cliente y de un controlador de dominio para el mismo intento, no solo de un lado. Los registros de Protected Users están en Applications and Services Logs\Microsoft\Windows\Authentication, y puede que un administrador tenga que activar un registro antes de que registre algo. Correlacione las marcas de tiempo con el registro de conexión del propio túnel, porque un error de orden parece un fallo de credenciales desde cualquiera de los dos lados.

El primer comando de abajo enumera todos los registros de autenticación que el dispositivo expone, así que lea el que existe y no el que nombró una entrada de blog. El segundo lee las entradas recientes una vez que conoce el nombre. Busque el paquete de autenticación, la cuenta y la condición de fallo, porque una ruta de red ausente y un mecanismo rechazado dejan evidencias distintas y solo una de ellas es un problema de VPN. Si el túnel subió después del intento, el orden era incorrecto digan lo que digan esas entradas.

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

Demuestre el límite desde un arranque en frío

Ejecute la prueba desde un estado cerrado o recién arrancado con una cuenta limitada, y mantenga abierta una ruta de recuperación aprobada antes de cambiar nada para los usuarios privilegiados. Una prueba en un escritorio ya en marcha no ejercita ninguna parte de la ruta de código que importa, y eso explica la mayoría de los informes de una corrección que aguantó hasta el siguiente reinicio. Después recorra los cuatro pasos en este orden.

1. Confirme que el dispositivo puede encontrar un controlador de dominio antes de que nadie inicie sesión, con nltest /dsgetdc:corp.example.com.
2. Intente el inicio de sesión de dominio y luego pregunte si se obtuvo algún vale, con klist.
3. Lea el registro de autenticación que registra el dispositivo, con los dos comandos de arriba, y anote el paquete y la condición de fallo.
4. Confirme que la credencial de recuperación aprobada sigue funcionando desde la pantalla de inicio de sesión, porque es la única forma de volver si la prueba del límite falla.

Abrir un recurso compartido con credenciales proporcionadas tampoco crea un inicio de sesión interactivo sin conexión, así que no sustituye ningún paso de arriba. Si la organización necesita de verdad iniciar sesión desconectada, la respuesta es un diseño compatible de cuenta y punto final elegido deliberadamente. Sacar la cuenta del grupo, o mantener un inicio de sesión de emergencia sin restricciones en cada portátil, es una decisión de política de identidad que un cambio de VPN no puede tomar por usted.

La documentación de Protected Users describe tanto el comportamiento del verificador como las restricciones de dominio de las que depende este diseño. Planifique el proceso de recuperación antes de que nadie viaje, porque la prueba de arranque en frío es el único lugar donde se ejercita.