Diagnostiquer une VM Linux Azure qui ne joint pas Active Directory

Une VM Linux Azure qui ne parvient pas à joindre Active Directory ne doit pas être diagnostiquée en relançant realm join avec des options différentes. Dans un spoke Azure, l’échec peut venir du DNS du VNet, d’une route vers le hub, d’un firewall, d’un NSG, d’un resolver mal choisi, d’une dérive horaire, d’un compte de jointure ou d’une configuration SSSD incomplète. La méthode la plus fiable consiste à remonter la chaîne dans l’ordre réel.

Le scénario est simple. Une VM Linux est déployée dans Azure. Le domaine Active Directory est dans un réseau hybride ou dans un hub. La VM doit rejoindre le domaine pour utiliser des groupes AD dans l’administration système. La jointure échoue avec une erreur Kerberos, LDAP, domaine introuvable ou timeout. L’objectif est de trouver où la chaîne casse avant de modifier la configuration locale.

1. Vérifier ce que la VM utilise vraiment

La première étape consiste à relever le resolver, les routes et le nom complet de la machine. Dans Azure, la configuration du VNet, cloud-init, NetworkManager ou systemd-resolved peuvent donner un résultat différent de ce qui était prévu.

ip route show
cat /etc/resolv.conf
resolvectl status 2>/dev/null || systemd-resolve --status 2>/dev/null || true
hostname -f || true

Si la VM utilise 168.63.129.16, elle s’appuie sur le DNS Azure. Si elle utilise des IP privées, ces IP doivent correspondre aux DNS internes ou aux forwarders prévus. Dans les deux cas, il faut tester la réponse effective du resolver.

DNS="10.10.0.10"
DOMAIN="corp.example.local"

nslookup $DOMAIN $DNS
nslookup -type=SRV _ldap._tcp.$DOMAIN $DNS
nslookup -type=SRV _kerberos._tcp.$DOMAIN $DNS

Si les enregistrements SRV ne répondent pas, la jointure ne sert à rien. Le problème est d’abord DNS. Il faut corriger le resolver du VNet, un conditional forwarder, une règle Azure DNS Private Resolver ou l’enregistrement des contrôleurs de domaine.

2. Tester les chemins réseau utiles

Quand le DNS répond, il faut vérifier les flux vers un contrôleur de domaine. Les premiers ports à contrôler sont DNS, Kerberos, LDAP, SMB et Kerberos password change.

DC="dc01.corp.example.local"

nc -vz $DC 53
nc -vz $DC 88
nc -vz $DC 389
nc -vz $DC 445
nc -vz $DC 464

Un timeout renvoie souvent à une route manquante, une UDR, un NSG, un firewall dans le hub ou un retour asymétrique. Un refus immédiat oriente plutôt vers un service non disponible ou un filtrage explicite. Dans Azure, le chemin retour est aussi important que le chemin aller.

3. Contrôler l’heure avant Kerberos

Kerberos supporte mal la dérive horaire. Une VM dont l’heure est incorrecte peut produire une erreur d’authentification alors que le compte est valide.

timedatectl status
chronyc tracking 2>/dev/null || true
chronyc sources -v 2>/dev/null || true

Si l’heure n’est pas cohérente, il faut corriger la synchronisation avant de continuer. Modifier SSSD dans ce cas ne fait qu’ajouter du bruit.

4. Tester Kerberos seul

Avant la jointure, kinit permet de savoir si le poste peut obtenir un ticket Kerberos. C’est un test plus précis que realm join.

REALM="CORP.EXAMPLE.LOCAL"
USER="join-user"

kinit $USER@$REALM
klist
kdestroy

Cannot find KDC pointe souvent vers DNS ou le routage. Une erreur de préauthentification renvoie plutôt au compte, au mot de passe ou à une stratégie Kerberos. Une erreur de type clock skew renvoie à l’heure.

5. Valider realmd et la découverte du domaine

Une fois DNS, ports et Kerberos validés, on peut regarder les outils de jointure.

DOMAIN="corp.example.local"

realm discover $DOMAIN
adcli info $DOMAIN
systemctl status realmd --no-pager 2>/dev/null || true
systemctl status sssd --no-pager 2>/dev/null || true

Si adcli info fonctionne mais realm discover échoue, il faut vérifier les paquets et les logs realmd. Si les deux échouent alors que DNS et Kerberos sont bons, il faut regarder LDAP et les dépendances de la distribution.

6. Lancer une jointure contrôlable

La jointure doit utiliser un compte dédié et une OU prévue pour les machines Linux si l’organisation en possède une.

DOMAIN="corp.example.local"
JOIN_USER="join-user"
COMPUTER_OU="OU=Linux,OU=Servers,DC=corp,DC=example,DC=local"

sudo realm join "$DOMAIN" --user="$JOIN_USER" --computer-ou="$COMPUTER_OU" --verbose

En cas d’échec, les logs doivent être lus avant toute relance.

journalctl -u realmd -n 200 --no-pager 2>/dev/null || true
journalctl -u sssd -n 200 --no-pager 2>/dev/null || true
sudo tail -n 120 /var/log/sssd/*.log 2>/dev/null || true

7. Valider l’usage final

Un succès de jointure ne suffit pas. Il faut vérifier que SSSD fonctionne et que les utilisateurs et groupes AD sont résolus.

DOMAIN="corp.example.local"
TEST_USER="user@$DOMAIN"
TEST_GROUP="linux-admins@$DOMAIN"

realm list
sssctl config-check
sssctl domain-status $DOMAIN
getent passwd "$TEST_USER"
getent group "$TEST_GROUP"

Si realm list est correct mais getent ne retourne rien, le problème se situe souvent dans SSSD, NSS, le format des noms ou la résolution des groupes. Si les groupes se résolvent mais que l’accès final échoue, il faut regarder PAM, la configuration SSH, les groupes autorisés et la création du répertoire home.

Conclusion

La bonne séquence est stable : contexte local, DNS SRV, ports AD, heure, Kerberos, découverte du domaine, jointure, logs, puis validation SSSD. Cet ordre évite de modifier la VM au hasard alors que la cause se trouve souvent dans Azure, dans le hub réseau ou dans le DNS interne. Une erreur realm join n’est que le symptôme visible ; le diagnostic utile consiste à localiser précisément le maillon cassé.