Pourquoi un portable Protected Users a besoin du VPN avant l’ouverture de session

Un portable, un compte opérationnel et un réseau d’hôtel forment une boucle d’ouverture de session qu’aucune nouvelle tentative ne casse. Le compte est dans Protected Users, ce qui empêche Windows de stocker le vérificateur dont il aurait besoin pour authentifier l’utilisateur hors ligne. Tout plan du type « connectez-vous d’abord, branchez le tunnel ensuite » a l’ordre inversé, et la protection fait exactement ce qu’elle promet. Ce qui suit suppose un compte Active Directory classique sur un hôte Windows pris en charge.

Ce que la protection retire réellement

Windows met normalement un vérificateur en cache pour qu’un compte de domaine puisse ouvrir une session lorsque le contrôleur de domaine est injoignable. Protected Users le bloque pour le compte, ce qui supprime l’ouverture de session de domaine hors ligne comme possibilité au lieu de la rendre peu fiable.

Ce n’est pas le problème habituel d’un cache périmé, et les remèdes habituels ne s’appliquent pas. Se connecter en ligne à plusieurs reprises, changer à nouveau le mot de passe ou relever le nombre d’ouvertures de session mises en cache ne rétabliront pas la capacité, car aucune de ces actions ne crée le vérificateur que la stratégie refuse de stocker. Le compte se comporte comme prévu, et la conception suppose que le réseau est présent lorsque Windows le demande. Traiter le symptôme comme une panne de cache, c’est ainsi que les équipes finissent par reconstruire un profil qui n’avait jamais été cassé.

Pourquoi le tunnel doit exister avant le bureau

L’appareil doit joindre l’authentification de domaine au moment où Windows la demande, c’est-à-dire avant qu’une session utilisateur existe. Un client VPN qui ne démarre qu’une fois le bureau apparu laisse une nouvelle ouverture de session attendre un chemin qui n’arrive jamais. La dépendance appartient à la machine, pas à un utilisateur qui ne s’est pas encore connecté.

Utilisez un dispositif d’avant-ouverture de session pris en charge et convenu avec les responsables des postes de travail et de l’identité. Un tunnel d’appareil Always On VPN authentifié par un certificat d’ordinateur convient lorsque l’appareil géré satisfait aux prérequis de ce déploiement. L’intégration prise en charge d’un écran d’ouverture de session par un fournisseur en est une autre. Un profil utilisateur ordinaire doté d’un déclencheur automatique n’est ni l’un ni l’autre, aussi ressemblant soit-il dans l’interface du client.

Ce chemin a besoin d’une résolution de noms pour le domaine, d’un contrôleur de domaine joignable et des protocoles d’authentification que le compte peut utiliser, et aucun indicateur « connecté » ne fournit cela. Ses routes et filtres doivent transporter les services d’identité et rien d’autre qui ne soit nécessaire, car cette liste de préfixes est la surface qu’un portable volé obtient avant que quiconque se connecte. Les décisions de tunnel divisé prises pour le tunnel utilisateur ne s’appliquent pas au tunnel d’appareil, examinez donc les deux séparément.

La joignabilité n’est pas la compatibilité d’authentification

Un tunnel peut transporter parfaitement les paquets alors que l’authentification de domaine échoue, parce que le mécanisme tenté est un que le compte n’a pas le droit d’utiliser. Dans un domaine qui applique les restrictions du groupe, NTLM n’est pas disponible pour les membres et Kerberos exige un compte et une configuration compatibles AES. Un chemin de paquets ne peut réparer ni l’un ni l’autre. C’est pourquoi un ping propre vers un contrôleur de domaine ne prouve pas que l’ouverture de session fonctionnera.

Deux systèmes d’informations d’identification peuvent aussi être en jeu. Le VPN peut s’authentifier auprès d’un fournisseur d’identité tandis que Windows a besoin séparément d’une ouverture de session de domaine, et l’acceptation du premier ne dit rien du second. « Le VPN est connecté » et « l’utilisateur est connecté » sont des observations distinctes, et corriger l’une n’implique pas l’autre.

Lisez les preuves d’authentification

Recueillez des événements du client et d’un contrôleur de domaine pour la même tentative, et pas d’un seul côté. Les journaux Protected Users se trouvent sous Applications and Services Logs\Microsoft\Windows\Authentication, et un administrateur devra peut-être activer un journal avant qu’il n’enregistre quoi que ce soit. Corrélez les horodatages avec le journal de connexion du tunnel lui-même, car une erreur d’ordre ressemble à un défaut d’informations d’identification des deux côtés.

La première commande ci-dessous liste tous les journaux d’authentification que l’appareil expose, de sorte que vous lisiez celui qui existe et non celui qu’un billet de blog a nommé. La seconde lit les entrées récentes une fois le nom connu. Cherchez le package d’authentification, le compte et la condition d’échec, car un chemin réseau absent et un mécanisme refusé laissent des preuves différentes et une seule des deux est un problème de VPN. Si le tunnel s’est levé après la tentative, l’ordre était faux quoi qu’en disent ces entrées.

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

Prouvez la limite depuis un démarrage à froid

Exécutez le test depuis un état déconnecté ou fraîchement démarré avec un compte limité, et gardez ouverte une voie de récupération approuvée avant de modifier quoi que ce soit pour les utilisateurs privilégiés. Un test sur un bureau déjà en marche n’exerce aucune partie du chemin de code qui compte, ce qui explique la plupart des rapports sur un correctif qui a tenu jusqu’au redémarrage suivant. Parcourez ensuite les quatre étapes dans cet ordre.

1. Confirmez que l’appareil peut trouver un contrôleur de domaine avant que quiconque se connecte, avec nltest /dsgetdc:corp.example.com.
2. Tentez l’ouverture de session de domaine, puis demandez si un ticket a été obtenu, avec klist.
3. Lisez le journal d’authentification que l’appareil enregistre, avec les deux commandes ci-dessus, et notez le package et la condition d’échec.
4. Confirmez que l’identifiant de récupération approuvé fonctionne toujours depuis l’écran d’ouverture de session, car c’est le seul retour possible si le test de limite échoue.

Ouvrir un partage de fichiers avec des identifiants fournis ne crée pas non plus d’ouverture de session interactive hors ligne, ce n’est donc pas un substitut à l’une des étapes ci-dessus. Si l’organisation a réellement besoin d’une ouverture de session sans connexion, la réponse est une conception compatible de compte et de poste de travail choisie délibérément. Retirer le compte du groupe, ou garder une ouverture de session d’urgence sans restriction sur chaque portable, est une décision de politique d’identité qu’un changement de VPN ne peut pas prendre pour vous.

La documentation Protected Users décrit à la fois le comportement du vérificateur et les restrictions de domaine dont dépend cette conception. Planifiez le processus de récupération avant que quiconque voyage, car le test de démarrage à froid est le seul endroit où il est exercé.