Tester une approbation Active Directory avec NLTEST

Dans un environnement Active Directory à plusieurs domaines, voir une approbation dans la console ne suffit pas à expliquer un échec d’accès. Mon exemple de laboratoire LABDOM/PRODDOM montrait plusieurs commandes nltest, mais il mélangeait inventaire des domaines, état d’un canal et validation de la relation. Voici comment lire ces résultats sans leur faire dire plus qu’ils ne prouvent.

Mis à jour le 28 octobre 2026 : les étapes, limites et sources ci-dessous ont été revérifiées. Les captures historiques sont signalées comme telles.

Commence par distinguer les trois contrôles

La référence Microsoft de NLTEST, consultée le 28 octobre 2026 distingue clairement /domain_trusts et /sc_query. La documentation actuelle de netdom trust ajoute /verify pour les secrets du canal d’une approbation précise. Aucun de ces résultats ne démontre à lui seul que les autorisations d’un dossier partagé sont correctes.

Commande	Ce qu’elle indique	Ce qu’elle ne prouve pas
nltest /domain_trusts	Liste des domaines approuvés visibles depuis la machine	Que l’authentification ou l’accès à un partage fonctionne
nltest /sc_query:DOMAINE	État du canal sécurisé lors de sa dernière utilisation	Une validation complète et actuelle de l’approbation
netdom trust A /domain:B /verify	Vérification des secrets du canal pour l’approbation ciblée	Les droits de l’utilisateur sur chaque ressource

Lister les domaines approuvés

Lance cette commande depuis une machine membre du domaine concerné, avec les droits nécessaires à ton environnement :

nltest /domain_trusts

Dans mon laboratoire d’origine, la sortie listait PRODDOM et DEVDOM avec les mentions Direct Outbound et Direct Inbound. Il s’agit d’un exemple historique, pas d’un résultat revérifié en production. Microsoft précise que la commande retourne une liste de domaines approuvés et accepte des filtres tels que /Direct_In et /Direct_Out (référence NLTEST, 28 octobre 2026).

Identifier un contrôleur et lire le canal sécurisé

Pour repérer les contrôleurs d’un domaine, l’exemple LABDOM utilisait :

nltest /dclist:LABDOM

Le résultat d’origine nommait SRVLAB01, SRVLAB02 et SRVLAB03. Pour interroger le canal vu depuis un serveur précis vers PRODDOM, l’article utilisait ensuite :

nltest /server:SRVLAB01 /sc_query:PRODDOM

La sortie historique affichait NERR_Success et SRVPROD01 comme contrôleur de confiance. La nuance compte : selon Microsoft, /sc_query rapporte l’état du canal la dernière fois qu’il a été utilisé. Une ligne « Success » ne valide donc ni tous les contrôleurs ni l’accès applicatif d’un utilisateur. Les exemples et noms de serveurs viennent du tutoriel de 2016 ; je ne prétends pas avoir exécuté ces commandes en 2026.

Vérifier la relation d’approbation elle-même

Pour une approbation précise, la commande documentée par Microsoft est netdom trust avec /verify. Remplace LABDOM et PRODDOM par les noms réels et lance-la dans une invite élevée, avec les autorisations nécessaires sur les deux domaines (Microsoft Learn, documentation consultée le 28 octobre 2026). Ne colle pas de mot de passe dans la ligne de commande : Microsoft accepte /passwordd:* et /passwordo:* pour les demander de façon interactive si des identifiants sont requis.

netdom trust LABDOM /domain:PRODDOM /verify

Attention à nltest /sc_verify:PRODDOM : malgré son nom, la référence Microsoft indique qu’il peut supprimer puis reconstruire un canal défaillant. Réserve-le à une intervention préparée, surtout sur un contrôleur de domaine. De même, Test-ComputerSecureChannel de PowerShell est destiné aux postes membres ; Microsoft avertit qu’il peut donner de faux positifs sur un contrôleur.

Un test d’accès complète le diagnostic

Après la vérification technique, essaie l’accès à la ressource avec un compte du domaine approuvé et contrôle les autorisations du partage ou de l’application. Une approbation saine ne crée pas les droits d’accès à ta place : la relation permet l’authentification, puis les permissions décident de l’accès. Si le test échoue, note le domaine source, le contrôleur contacté, le code d’erreur et le sens de l’approbation avant de modifier quoi que ce soit.

Pour replacer ce contrôle dans l’administration du domaine, consulte nos guides sur les rôles FSMO, le PDC Emulator et le pilier Windows, IT et sécurité.

Questions fréquentes

La commande nltest /domain_trusts teste-t-elle l’approbation ?

Non. Elle énumère les domaines approuvés ; elle ne démontre pas qu’un utilisateur peut ouvrir une ressource (Microsoft, documentation consultée le 28 octobre 2026).

Que signifie NERR_Success dans la sortie de /sc_query ?

La commande a rapporté un état de connexion réussi pour le canal affiché lors de sa dernière utilisation. Ce résultat ne remplace pas une vérification de l’approbation ciblée (Microsoft, 28 octobre 2026).

Puis-je lancer nltest /sc_verify sans risque sur un contrôleur ?

Il faut le traiter comme une opération d’administration : Microsoft indique que la commande peut reconstruire un canal défaillant et demande des droits administrateur (Microsoft, 28 octobre 2026).

Test-ComputerSecureChannel convient-il à un contrôleur de domaine ?

Non. Microsoft le réserve aux ordinateurs membres et avertit qu’il peut produire des faux positifs sur les contrôleurs de domaine (Microsoft, 28 octobre 2026).