Joindre un domaine via un VPN utilisateur, puis survivre au redémarrage

Vous pouvez exécuter une jonction au domaine via un VPN point à site. Ce que cette connexion ne peut généralement pas faire, c’est rester active pendant le redémarrage qui suit, lorsque le premier utilisateur du domaine tente de se connecter. Je déroule désormais la jonction en trois étapes : prouver le chemin et la découverte alors qu’un administrateur local est connecté, exécuter la jonction, puis tester la première ouverture de session de domaine avant de remettre l’ordinateur portable. Chaque étape comporte un test qui échoue à un endroit différent.

Séparer ces étapes, c’est ce qui évite que le projet se termine par un portable joint avec succès et inutilisable.

Avant de vous connecter : édition, administrateur local, DNS

La machine a besoin d’une édition qui prend en charge la jonction au domaine et d’un administrateur local autorisé à l’exécuter. Le VPN doit être actif dans la même session, car la jonction s’exécute dans le contexte de sécurité que vous utilisez.

Pointez le client vers le DNS de l’annuaire de l’organisation, ni vers un résolveur public ni vers une entrée du fichier hosts. La jonction doit trouver les enregistrements de service puis atteindre les hôtes que ces enregistrements nomment. Un suffixe obsolète ou un résolveur public envoie la découverte complètement ailleurs.

Vérifiez aussi l’horloge. Kerberos ne tolère aucun décalage horaire, et un portable resté hors ligne un mois est une source fréquente d’erreurs de jonction déroutantes.

Confirmez que le domaine est découvrable, pas seulement joignable par ping

Résolvez l’enregistrement LDAP SRV du domaine avant de tenter la jonction. Pour un environnement illustratif à domaine unique nommé ad.corp.example, la requête est :

Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.ad.corp.example

Un enregistrement renvoyé est nécessaire mais pas suffisant. Résolvez chaque nom de DC qu’il liste et confirmez que vous atteignez les services requis par le tunnel. Un ping vers le nom de domaine ne prouve presque rien sur la découverte.

Autorisez les dépendances AD documentées : authentification, trafic SMB et RPC, plus la synchronisation de l’heure. Vérifiez chacune par rapport aux règles de pare-feu réellement déployées. Publier les ports du contrôleur de domaine sur Internet n’est pas un raccourci qui vaille la peine d’être envisagé.

Exécutez la jonction et lisez l’erreur

Utilisez la commande de jonction prise en charge ou la boîte de dialogue système, et capturez le texte exact de l’erreur. « Le domaine spécifié n’existe pas ou n’a pas pu être contacté » pointe vers la découverte ou l’accessibilité, pas vers les informations d’identification.

Si un objet portant le même nom existe déjà, ne le supprimez pas par réflexe. Il peut s’agir d’un compte pré-créé, et le durcissement netjoin restreint certains cas de réutilisation selon la propriété et la stratégie. Demandez au propriétaire de l’annuaire d’inspecter ou de corriger l’objet.

Une jonction réussie est le point médian, pas la ligne d’arrivée. L’étape suivante est celle que l’utilisateur teste réellement.

Planifiez la première ouverture de session de domaine

Une jonction terminée ne crée pas d’informations d’identification mises en cache pour chaque utilisateur du domaine. À l’écran de connexion initial, le portable a besoin d’un chemin vers un DC avant qu’aucun utilisateur ne se soit connecté. Si votre VPN utilisateur ne démarre qu’après la connexion, ce chemin manque. C’est une lacune de conception, pas un bogue du client.

Utilisez un flux de travail pris en charge avant connexion ou un tunnel d’appareil, un chemin de site existant ou une alternative approuvée pour cette première connexion. Testez ensuite toute la séquence : redémarrez, atteignez l’écran d’identification, connectez-vous en tant qu’utilisateur de domaine prévu et confirmez que le tunnel se comporte comme prévu.

Le changement d’utilisateur et la persistance du VPN varient selon le client. Ne partez pas du principe qu’une connexion démarrée en tant qu’administrateur local survivra dans la session d’un autre utilisateur.

Conservez un accès local de récupération

Préservez un chemin de récupération local approuvé avant de remettre le portable. Si la première connexion au domaine échoue, vous voulez un moyen de revenir qui ne dépende pas du même tunnel qui vient d’échouer.

Notez ce que vous avez prouvé : résolution SRV, accessibilité du DC, l’erreur de jonction, la méthode de première connexion et le compte de récupération. Cette trace fait la différence entre une construction reproductible et un portable qui ne fonctionne qu’au bureau.