Vous perdez régulièrement l’accès au domaine AD depuis une VM Windows Server 2019 exécutée dans vSphere ? Cette fiche pas‑à‑pas explique comment diagnostiquer la panne « le domaine n’est pas disponible » et éradiquer définitivement la cause, qu’elle soit réseau, VMware Tools, DNS ou canal sécurisé.
Vue d’ensemble du problème
- Lors d’une connexion interactive, le message d’erreur affiche : « We can’t sign you in with this credential because your domain isn’t available… ».
- Aucun autre serveur ni poste du même réseau ne rencontre le symptôme.
- Un simple redémarrage de la VM suffit à rétablir l’authentification… jusqu’à la prochaine coupure.
- Un rapide contrôle montre pourtant un horodatage correct et une résolution DNS apparemment saine.
Analyse des causes possibles
| Piste | Vérifications clés | Résultat attendu si problème |
|---|---|---|
| Perte de connectivité réseau transitoire | ping continu vers chaque DC, pathping, journaux ESXi/VDS | Paquets perdus, latence fluctuante |
| DNS mal résolu au moment critique | nslookup dc1.contoso.local, ipconfig /displaydns | Échecs sporadiques de résolution |
| Canal sécurisé machine ↔ DC rompu | Test-ComputerSecureChannel –Verbose, nltest /sc_verify | Retour « False » ou erreur 5 |
| Mot de passe du compte ordinateur expiré | net user <Nom_machine$> /domain | Date pwdLastSet trop ancienne |
| Service Netlogon arrêté ou instable | Observateur d’événements Système : ID 5719/5722 | Échecs de connexion au DC |
| Version VMware Tools / pilote vmxnet3 obsolète | Comparaison avec dernière build ESXi | Timeouts réseau, warnings driver |
| NIC en mode économie d’énergie | Gestionnaire de périphériques → Onglet Alimentation | Désactivation du lien logique aléatoire |
| Surcharge ponctuelle des contrôleurs de domaine | dcdiag /v, supervision CPU/RAM DC | Pics corrélés aux heures de blocage |
| Snapshots, reverts ou clones mal maîtrisés | Historique vSphere, traces sysprep | Recréation répétée du canal sécurisé |
Pourquoi le canal sécurisé est souvent coupable
Chaque machine membre possède un mot de passe d’ordinateur renouvelé toutes les 30 jours. Si la VM reste arrêtée plus longtemps, ou si un snapshot est restauré après le changement de mot de passe côté DC, les tickets Kerberos ne sont plus valides ; Netlogon rejette alors la demande de session. Un simple redémarrage force parfois la renégociation, d’où l’illusion que « ça revient tout seul ». C’est pourtant un signal fort qu’il faut réparer le canal sécurisé plutôt que de multiplier les redémarrages.
Plan de remédiation pas‑à‑pas
1. Vérifier et réparer immédiatement le canal sécurisé
# Diagnostic en lecture seule
Test-ComputerSecureChannel -Verbose
# Réparation automatique
Test-ComputerSecureChannel -Repair -Verbose
# ou
nltest /sc\_reset\:CONTOSO Une réparation réussie restaure instantanément l’accès au domaine. Si elle échoue, retirez provisoirement la machine du domaine, redémarrez, puis rejoignez‑le à nouveau.
2. Corréler les journaux d’événements
- Système : ID 5719, 5783 (Netlogon), 40960/40961 (LSA) indiquent un problème d’authentification ou de localisation de DC.
- Sécurité : échecs Kerberos 0xC000006D, 0xC000018B confirment la négociation ratée.
- Application : ID 1014 DNS Client Events révèle des temporisations de résolution.
3. Surveiller la latence réseau en continu
Exécutez ping -t vers chacun des contrôleurs de domaine et exportez le résultat dans un fichier CSV. Un simple graphique mettra en évidence des pics de latence ou des pertes de paquets au moment précis où Netlogon déclenche l’erreur 5719.
4. Stabiliser la couche virtuelle
- Mettez à jour VMware Tools et le pilote vmxnet3 à la version recommandée pour votre hôte ESXi.
- Désactivez toute option d’économie d’énergie (Energy-Efficient Ethernet, Wake‑on‑LAN) dans les propriétés avancées de l’adaptateur.
- Vérifiez que l’ordre de démarrage réseau de la VM référence en premier la carte connectée au VLAN corporate.
- Contrôlez la MTU du vSwitch : des trames jumbo non supportées peuvent fragmenter les paquets Kerberos (UDP 88).
5. Sécuriser et tracer la synchronisation temporelle
# Forcer une source unique et fiable, ici le DC principal
w32tm /config /manualpeerlist:"dc1.contoso.local 0x8" /syncfromflags:manual /reliable:no /update
# Purger puis resynchroniser
w32tm /resync /force
# Exporter l'état détaillé
w32tm /query /status /verbose
Un décalage supérieur à 5 minutes entre la VM et le DC invalide immédiatement tous les tickets Kerberos. Surveillez la dérive horaire et activez le verrouillage de fréquence NTP (slew mode) pour éviter les corrections brusques.
6. Auditer la santé des contrôleurs de domaine
dcdiag /e /c /v /f:C:\Temp\dcdiag_full.txt
repadmin /replsummary
repadmin /queue
Une réplication AD en erreur ou un contrôleur saturé allonge les temps de réponse LDAP : Netlogon peut alors déclarer le DC indisponible, même si les paquets ICMP passent.
7. Mettre en place des alertes proactives
Un script PowerShell planifié toutes les 15 minutes peut exécuter Test-ComputerSecureChannel et envoyer une alerte e‑mail ou Telegram lorsqu’il retourne False. Les solutions de supervision comme Zabbix, PRTG ou Centreon disposent déjà de modèles d’écoute des ID 5719/5722 Netlogon.
Correctifs de fond
| Cause confirmée | Correctif définitif |
|---|---|
| Mot de passe du compte ordinateur expiré | Conservez la valeur par défaut « 30 jours » de la stratégie Domain member: Maximum machine account password age. Évitez de maintenir la VM éteinte plus d’un mois ou recyclez le mot de passe manuellement avant l’arrêt prolongé. |
| Service Netlogon instable | Ajoutez une dépendance au service LanmanWorkstation afin que Netlogon démarre après l’établissement du réseau, ou créez un déclencheur de redémarrage automatique lorsqu’il passe à l’état STOPPED. |
| VLAN ou trunk mal configuré | Uniformisez les paramètres de port sur tous les commutateurs physiques ; désactivez STP PortFast si le port hébergeant l’hôte ESXi est déjà protégé contre les boucles. |
| Serveur DNS externe défini en tertiaire | Supprimez toute référence à 8.8.8.8 ou autres DNS publics sur la carte réseau de la VM ; ne conservez que les IP des DC internes. |
| Snapshots restaurés trop anciens | Réduisez la durée de vie des snapshots à 72 h maximum ; pour les clones, exécutez sysprep /generalize afin de générer un nouveau SID de machine. |
Bonnes pratiques pour prévenir toute récidive
- Documentation : notez systématiquement la date de création des snapshots et prévoyez leur suppression dans votre runbook.
- Seuils de supervision : configurez des alertes dès 5 % de paquets perdus ou 200 ms de latence moyenne vers les DC.
- Haute disponibilité DC : déployez au moins deux contrôleurs sur des hôtes VMware différents ; désactivez l’affinité DRS pour ne pas les regrouper.
- Sauvegarde de l’état système : programmez
wbadmin start systemstatebackupchaque semaine afin de pouvoir restaurer rapidement un DC. - Tests périodiques : insérez une tâche mensuelle d’exécution de
Test-ComputerSecureChanneldans vos job PowerShell DSC ou Ansible.
Ressources complémentaires utiles
- KB5021131 — NLA fails due to secure channel issues (mise à jour 2023).
- Microsoft Docs — Secure Channel Broken – How to troubleshoot.
- Livre blanc VMware — Windows Timekeeping in Virtual Machines.
Conclusion
Dans l’immense majorité des cas, la perte intermittente d’appartenance au domaine est liée à un canal sécurisé cassé ou à une fragilité réseau masquée. En appliquant la matrice de vérification puis le plan de remédiation détaillé ci‑dessus, vous éliminerez durablement les messages « domain not available » et restaurerez une authentification AD fiable pour vos serveurs Windows Server 2019 virtualisés.