Per què un portàtil amb Protected Users necessita la VPN abans d’iniciar sessió

Un portàtil, un compte operatiu i una xarxa d’hotel sumen un bucle d’inici de sessió que cap reintent no trenca. El compte és a Protected Users, cosa que impedeix que Windows desi el verificador que necessitaria per autenticar l’usuari sense connexió. Qualsevol pla del tipus «inicia sessió primer, connecta el túnel després» té l’ordre invertit, i la protecció fa exactament el que promet. El que segueix assumeix un compte tradicional d’Active Directory en un amfitrió Windows compatible.

Què elimina realment la protecció

Normalment Windows desa un verificador en memòria cau perquè un compte de domini pugui iniciar sessió mentre el controlador de domini no és accessible. Protected Users ho bloqueja per al compte, cosa que elimina l’inici de sessió de domini sense connexió com a possibilitat en lloc de fer-lo poc fiable.

No és el problema habitual de memòria cau obsoleta, i els remeis habituals no s’hi apliquen. Iniciar sessió en línia repetidament, tornar a canviar la contrasenya o augmentar el recompte d’inicis de sessió desats no restabliran la capacitat, perquè cap d’aquestes accions no crea el verificador que la política es nega a desar. El compte es comporta tal com està dissenyat, i el disseny assumeix que la xarxa hi és quan Windows la demana. Tractar el símptoma com una fallada de memòria cau és com els equips acaben reconstruint un perfil que mai no estava espatllat.

Per què el túnel ha d’existir abans de l’escriptori

El dispositiu ha d’arribar a l’autenticació de domini en el moment en què Windows la demana, que és abans que existeixi cap sessió d’usuari. Un client VPN que només arrenca després que aparegui l’escriptori deixa un inici de sessió nou esperant un camí que no arriba mai. La dependència pertany a la màquina, no a un usuari que encara no ha iniciat sessió.

Feu servir un dispositiu d’inici de sessió previ compatible i acordat amb els responsables dels punts finals i de la identitat. Un túnel de dispositiu Always On VPN autenticat amb un certificat d’ordinador compleix el requisit quan el dispositiu gestionat satisfà els prerequisits d’aquest desplegament. La integració compatible d’un proveïdor amb la pantalla d’inici de sessió n’és una altra. Un perfil d’usuari corrent amb un activador automàtic no és cap de les dues, per molt semblant que sembli a la interfície del client.

El que aquest camí necessita és resolució de noms per al domini, un controlador de domini abastable i els protocols d’autenticació que el compte pugui fer servir, i cap indicador de «connectat» no ho proporciona. Les seves rutes i filtres han de portar els serveis d’identitat i res més que no calgui, perquè aquesta llista de prefixos és la superfície que un portàtil robat obté abans que ningú iniciï sessió. Les decisions de túnel dividit preses per al túnel d’usuari no es traslladen al túnel de dispositiu, així que reviseu-los per separat.

L’abastabilitat no és compatibilitat d’autenticació

Un túnel pot transportar paquets perfectament mentre l’autenticació de domini falla, perquè el mecanisme que s’intenta és un que el compte no pot fer servir. En un domini que aplica les restriccions del grup, NTLM no està disponible per als membres i Kerberos necessita un compte i una configuració compatibles amb AES. Un camí de paquets no pot reparar cap de les dues coses. Per això un ping net a un controlador de domini no és prova que l’inici de sessió funcioni.

També poden intervenir dos sistemes de credencials. La VPN pot autenticar-se contra un proveïdor d’identitat mentre Windows necessita per separat un inici de sessió de domini, i l’acceptació del primer no diu res del segon. «La VPN s’ha connectat» i «l’usuari ha iniciat sessió» són observacions separades, i arreglar una no implica l’altra.

Llegiu les evidències d’autenticació

Recolliu esdeveniments del client i d’un controlador de domini per al mateix intent, no només d’una banda. Els registres de Protected Users són a Applications and Services Logs\Microsoft\Windows\Authentication, i potser un administrador ha d’activar un registre abans que enregistri res. Correlacioneu les marques de temps amb el registre de connexió del propi túnel, perquè un error d’ordre sembla una fallada de credencials des de qualsevol de les dues bandes.

La primera ordre de sota llista tots els registres d’autenticació que el dispositiu exposa, així que llegiu el que existeix i no el que va anomenar una entrada de blog. La segona llegeix les entrades recents un cop sabeu el nom. Busqueu el paquet d’autenticació, el compte i la condició de fallada, perquè un camí de xarxa absent i un mecanisme rebutjat deixen evidències diferents i només una és un problema de VPN. Si el túnel va pujar després de l’intent, l’ordre era equivocat diguin el que diguin aquestes entrades.

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

Demostreu la frontera des d’una arrencada en fred

Executeu la prova des d’un estat tancat o acabat d’arrencar amb un compte limitat, i manteniu obert un camí de recuperació aprovat abans de canviar res per als usuaris privilegiats. Una prova en un escriptori ja en marxa no exerceix cap part del camí de codi que importa, i això explica la majoria d’informes d’una correcció que va aguantar fins al reinici següent. Després passeu pels quatre passos en aquest ordre.

1. Confirmeu que el dispositiu pot trobar un controlador de domini abans que ningú iniciï sessió, amb nltest /dsgetdc:corp.example.com.
2. Intenteu l’inici de sessió de domini i després pregunteu si s’ha obtingut algun tiquet, amb klist.
3. Llegiu el registre d’autenticació que enregistra el dispositiu, amb les dues ordres de dalt, i anoteu el paquet i la condició de fallada.
4. Confirmeu que la credencial de recuperació aprovada encara funciona des de la pantalla d’inici de sessió, perquè és l’única manera de tornar si la prova de frontera falla.

Obrir un recurs compartit amb credencials proporcionades tampoc no crea un inici de sessió interactiu sense connexió, així que no substitueix cap pas de dalt. Si l’organització necessita de debò iniciar sessió desconnectada, la resposta és un disseny compatible de compte i punt final triat deliberadament. Treure el compte del grup, o mantenir un inici de sessió d’emergència sense restriccions a cada portàtil, és una decisió de política d’identitat que un canvi de VPN no pot prendre per vosaltres.

La documentació de Protected Users descriu tant el comportament del verificador com les restriccions de domini de què depèn aquest disseny. Planifiqueu el procés de recuperació abans que ningú viatgi, perquè la prova d’arrencada en fred és l’únic lloc on s’exerceix.