STATUS_NO_LOGON_SERVERS entre domaines Active Directory : diagnostic complet (DNS, Kerberos, confiance)

Un serveur d’un domaine A (en confiance avec le domaine B) échoue à s’authentifier et retourne STATUS_NO_LOGON_SERVERS. Ce guide explique clairement qui est contacté, dans quel ordre, comment investiguer rapidement et comment corriger durablement (DNS, Kerberos, confiance, sites AD, NTP).

Vue d’ensemble de la question

Un serveur membre du domaine A doit accéder à une ressource du domaine B (confiance configurée). Au moment précis de l’échec, l’administrateur veut savoir quel contrôleur de domaine (DC) la machine tente de joindre : son DC local (domaine A) ou un DC du domaine partenaire (domaine B) ?

Réponse & solution

Signification de l’erreur

STATUS_NO_LOGON_SERVERS indique que aucun contrôleur de domaine n’a répondu assez vite à la demande d’authentification. Il peut s’agir d’une indisponibilité réseau, d’une résolution DNS défaillante, d’un service AD arrêté, d’une dérive d’horloge bloquant Kerberos, ou encore d’une topologie de sites qui force un détour vers un DC lent.

Ordre normal des contacts

1. Authentification locale : le serveur interroge d’abord un DC de son propre domaine (domaine A) pour résoudre les groupes, obtenir des tickets Kerberos, valider son canal sécurisé (secure channel), etc.
2. Authentification d’un objet du domaine partenaire :
   • Le serveur contacte son DC (domaine A).
   • Ce DC constate que l’objet appartient au domaine B (en confiance) et redirige la requête vers un DC du domaine B. Selon la nature de la confiance (inter-forêts, externe, sélective), il émet des références (Kerberos referral) ou relaie des échanges NTLM.
   Conclusion : l’échec peut provenir de l’impossibilité d’atteindre soit le DC local soit — après redirection — un DC du domaine de confiance.

Vue simplifiée du chemin d’authentification

Serveur (domaine A)
     │
     ├─ 1) DNS & Kerberos/NTLM → DC du domaine A
     │        └─ 2) Référence Kerberos / relais NTLM
     │
     └────────────→ DC du domaine B → Ressource B

Pistes de résolution rapides

Axe	Vérifications recommandées
Connectivité réseau	ICMP (ping) ; TCP 445 et 135 ; LDAP 389/636 ; Kerberos 88/464 ; RPC dynamiques 49152–65535 (selon OS) entre le serveur et tous les DC concernés (A et B).
DNS	Les enregistrements _ldap._tcp.dc._msdcs.<domaine> doivent se résoudre des deux côtés. Configurer des redirecteurs conditionnels ou une transmission DNS bidirectionnelle si nécessaire.
Relations de confiance	netdom trust /verify pour valider l’état, la direction et la synchronisation des secrets. Vérifier le type (externe vs forêt), la transitivité et la sélection d’authentification.
Répartition des sites AD	Associer correctement sous‑réseaux et sites afin d’éviter qu’un DC lointain (lien WAN saturé) soit choisi par défaut.
Horloge & Kerberos	Assurer < 5 minutes d’écart NTP entre tous les DC et le client (sinon erreurs KRB_AP_ERR_SKEW et retombée NTLM).
État des DC	dcdiag, repadmin /replsummary pour détecter réplications en panne et services AD stoppés.

Commandes utiles

• nltest /dsgetdc:<domaine> — Localise le DC réellement contacté (nom, site, drapeaux Kerberos/GC).
• nltest /sc_query:<domaine> — Vérifie la session sécurisée (secure channel) entre la machine et son DC.
• klist get <SPN> / klist tickets — Confirme la délivrance d’un ticket service du domaine partenaire.
• Test-ComputerSecureChannel -Verbose — Teste et corrige le canal sécurisé machine.
• Journaux : System & Directory‑Service sur le serveur et les DC ; filtrez les ID 5719, 5827, 5723, 40960/40961 (LSA), 4771/4769 (Kerberos), 14/15 (Time‑Service).

Bonnes pratiques

• Ajouter au moins un DC du domaine partenaire comme conditional forwarder DNS (ou exposer une zone secondaire) ; éviter l’usage de serveurs DNS « grand public » pour les hôtes AD.
• Mettre en cache des itinéraires inter‑sites rapides (Site Links avec coûts pertinents) pour limiter la latence d’authentification.
• Automatiser un test de santé quotidien (script PowerShell) qui vérifie secure channel, NTP, résolution SRV, et présence des tickets Kerberos.
• Documenter la matrice de ports autorisés entre segments (LAN, DMZ, WAN) et la maintenir à jour.

Méthode d’investigation pas à pas

Étape 1 — Visibilité réseau

1. Depuis le serveur A : Test-NetConnection -ComputerName <dcA> -Port 88 Test-NetConnection -ComputerName <dcA> -Port 389 Test-NetConnection -ComputerName <dcB> -Port 88 Test-NetConnection -ComputerName <dcB> -Port 389 Si Kerberos (88) ou LDAP (389/636) échouent vers dcA, corriger en priorité. Si dcA est joignable mais pas dcB, focalisez‑vous sur la confiance et la routabilité entre domaines.
2. Vérifier les RPC dynamiques (fréquent en DMZ) : Test-NetConnection -ComputerName <dcA> -Port 445 Test-NetConnection -ComputerName <dcA> -Port 135 En cas de filtrage, envisagez de borner la plage RPC sur les DC et d’ouvrir précisément ces ports.

Étape 2 — DNS & SRV

1. Résolution des SRV : nslookup -type=SRV _ldap._tcp.dc._msdcs.<domaineA> nslookup -type=SRV _ldap._tcp.dc._msdcs.<domaineB> Absence de réponse = problème de transfert/redirecteur. Mettez en place des redirecteurs conditionnels réciproques ou des zones secondaires strictement nécessaires (pas de fuite inutile d’enregistrements).
2. Suffixes DNS de recherche : assurez‑vous que le serveur A sait résoudre les FQDN du domaine B (Primary DNS Suffix, Connection‑specific Suffix et Search List correctement configurés).

Étape 3 — Kerberos & temps

1. Horloge (NTP) : w32tm /query /status w32tm /query /peers Écart maximal recommandé : ±300 s. En cas de dérive, reconfigurez la hiérarchie de temps (PDC Emulators) et forcez une resynchronisation (w32tm /resync).
2. Tickets : klist purge klist get host/<serveurB>.<domaineB> klist tickets Échec de klist get : suspectez SPN manquant/incorrect, problème de confiance ou d’horloge.

Étape 4 — Confiance AD

1. État de la confiance : netdom trust <domaineA> /domain:<domaineB> /verify netdom trust <domaineA> /domain:<domaineB> /quarantine netdom trust <domaineA> /domain:<domaineB> /EnableSIDHistory Vérifiez le type (externe/forêt), la transitivité, la quarantaine (sélective) et le SID filtering. Une confiance cassée remonte souvent STATUS_NO_LOGON_SERVERS côté client.
2. Secure channel machine : nltest /sc_query:<domaineA> Test-ComputerSecureChannel -Verbose Si le canal est rompu : Test-ComputerSecureChannel -Repair -Credential <AdminDomA>.

Étape 5 — Journaux & Netlogon Debug

• Activez temporairement le log Netlogon (si nécessaire) : nltest /dbflag:0x2080ffff # reproduire le problème nltest /dbflag:0x0 Puis analysez %systemroot%\debug\netlogon.log pour identifier le DC ciblé, les referrals et les erreurs précises.
• Événements clefs (exemples) : Source / ID Signification Action Netlogon 5719 Impossible d’établir une session avec un DC. Réseau/DNS, secure channel. Netlogon 5723 Erreur d’authentification machine. Réinitialiser secure channel. KDC 4769/4771 Échecs Kerberos (pré-auth, skew, SPN). Temps, SPN, double‑hop. LSA 40960/40961 Problèmes NTLM/SSPI. Canal sécurisé, confiance, DNS. Time‑Service 14/15 Impossible de synchroniser l’heure. Corriger sources NTP.

Comprendre l’impact SMB/NTLM vs Kerberos

Si la ressource cible force Kerberos mais qu’aucun ticket n’est délivré (horloge en dérive, SPN incorrect, délégation mal configurée), le client tente une retombée NTLM. Dans ce cas, la dépendance au DC local est encore plus forte ; si ce dernier est injoignable, STATUS_NO_LOGON_SERVERS survient même si la ressource distante est accessible en réseau.

Comportement hors ligne et cache

Windows met en cache certaines informations d’authentification interactives, mais ces caches ne servent pas pour des connexions réseau inter‑domaines qui doivent être validées par un DC actuel. Si tous les DC pertinents sont injoignables, l’accès échoue.

Scénarios typiques et symptômes

Scénario	Symptômes	Diagnostic rapide	Correctif
DMZ vers AD interne	Accès aléatoires, erreurs 5719/40960	Ports RPC dynamiques bloqués	Ouvrir 135 + plage RPC bornée, 88/389/445
Sites AD mal mappés	Latence extrême, timeouts	nltest /dsgetdc montre un DC lointain	Associer sous‑réseaux ↔ sites, ajuster coûts
Dérive NTP	KRB_AP_ERR_SKEW, retombée NTLM	Events Time‑Service 14/15	Corriger sources NTP, resync
SPN manquant	Kerberos « KDC_ERR_S_PRINCIPAL_UNKNOWN »	setspn -Q, klist	setspn -S sur le compte service
Confiance cassée	Échec inter‑domaines uniquement	netdom trust /verify	Recréer/ressaisir les secrets de confiance

Matrice de ports à vérifier

Service	Port/Proto	De → Vers	Remarques
Kerberos	88/TCP, 88/UDP	Client → DC	« Ticketing » ; sensibles au temps
LDAP	389/TCP, 389/UDP	Client/DC/serveur → DC	Annuaire et referrals
LDAPS	636/TCP	Client → DC	LDAP chiffré (certificats)
RPC Endpoint Mapper	135/TCP	Client → DC	Nécessaire à de nombreux appels AD
RPC dynamiques	49152–65535/TCP	Client ↔ DC	Peut être borné côté DC
SMB/CIFS	445/TCP	Client ↔ DC	Accès SYSVOL/NETLOGON, GPO, scripts
DNS	53/TCP, 53/UDP	Client/DNS ↔ DNS autoritaire	Résolution SRV/FQDN inter‑domaines
NTP	123/UDP	Client ↔ Source de temps	Indispensable à Kerberos

Identifier précisément le DC contacté

Exécutez :

nltest /dsgetdc:<domaineA>
nltest /dsgetdc:<domaineB>

Cherchez les champs : DC: \\<Nom>, Address, Dom Guid, Our Site Name, Flags (notamment GC, LDAP, KDC). Ces sorties confirment le DC réellement utilisé et le site perçu par le client.

Playbook de correction

1. Rétablir la résolution DNS entre A et B (redirecteurs conditionnels réciproques, zones secondaires ciblées). Vérifier _ldap._tcp.dc._msdcs pour chaque domaine.
2. Garantir la synchronisation temporelle (PDCe → référence externe fiable, membres → leur DC local). Forcer la resynchronisation.
3. Corriger la topologie de sites (associer les sous‑réseaux, ajuster les coûts de liens, forcer une réplication si nécessaire).
4. Vérifier la confiance (type, transitivité, SID filtering, sélective vs large). Réinitialiser les secrets au besoin.
5. Rétablir le secure channel des machines impactées (PowerShell ou nltest).
6. Valider Kerberos : klist, setspn (corriger les SPN), gpupdate (GPO d’authentification).
7. Surveiller : mettre en place une vérification quotidienne (voir script ci‑dessous).

Script de test quotidien (exemple PowerShell)

# Vérification santé AD inter-domaines
$domains = @('<domaineA>', '<domaineB>')
$result = foreach ($d in $domains) {
  $dc = (nltest /dsgetdc:$d) 2>&1
  [pscustomobject]@{
    Domain = $d
    DCLine = ($dc | Select-String 'DC:').Line
    Site   = ($dc | Select-String 'Our Site Name').Line
    Time   = (w32tm /query /status | Select-String 'Phase Offset').Line
    Secure = (nltest /sc_query:$d | Select-String 'trusted|secure channel').Line
  }
}
$result | Format-Table -Auto
# Optionnel: alerte si absence de DC / dérive >= 5 min

Sécurité : bonnes pratiques de périmètre

• Ne jamais exposer « en grand » les ports AD sur Internet. Préférez un VPN site‑à‑site ou un tunnel chiffré (IPSec) entre réseaux.
• En DMZ, hébergez un Réplica en lecture seule (RODC) si l’architecture le permet et ouvrez seulement les ports nécessaires.
• Pour les confiances externes, envisagez LDAP‑S (636) et durcissez NTLM (Channel Binding, SMB signing).

FAQ rapide

Q : Est‑ce que le client contacte directement un DC du domaine B ?
R : Non, il contacte d’abord son DC du domaine A. C’est ce dernier qui effectue/induit la redirection (Kerberos referral) vers un DC de B.

Q : Pourquoi l’erreur apparaît‑elle alors que le réseau vers la ressource B fonctionne ?
R : Parce que l’authentification dépend des DC (A et B). Une simple connectivité IP vers la ressource ne suffit pas ; il faut que les DC soient joignables et correctement référencés (DNS, Kerberos).

Q : Un cache d’identifiants peut‑il « sauver » l’accès ?
R : Non pour l’inter‑domaines : l’accès réseau doit être validé en temps réel par un DC.

Checklist express

• Réseau : 88/389/445/135 ouverts du serveur A vers DC‑A et DC‑B.
• DNS : Résolution des SRV _ldap._tcp.dc._msdcs pour A et B OK.
• Temps : Écart < 5 min entre A, B et leurs DC.
• Confiance : netdom trust /verify sans erreur.
• Secure channel : Test-ComputerSecureChannel OK.
• Kerberos : klist get du SPN cible OK.
• Sites AD : Sous‑réseaux correctement associés au site attendu.

Exemples d’analyses concrètes

Cas 1 — DC local indisponible

Symptômes : nltest /sc_query:<domaineA> échoue ; événements 5719/5723.
Conclusion : le client ne peut pas contacter son DC ; toute tentative (même vers B) finit en STATUS_NO_LOGON_SERVERS.
Correctif : rétablir connectivité vers DC‑A, réparer secure channel, vérifier DNS interne.

Cas 2 — Référence vers domaine B impossible

Symptômes : nltest /dsgetdc:<domaineA> OK, mais nltest /dsgetdc:<domaineB> échoue.
Conclusion : problème de confiance, DNS inter‑domaines ou filtrage réseau vers DC‑B.
Correctif : réparer la confiance (netdom), ouvrir les ports vers DC‑B, ajouter des redirecteurs DNS.

Cas 3 — Dérive temporelle > 5 minutes

Symptômes : événements Kerberos 4771 et Time‑Service 14/15, klist get échoue.
Correctif : corriger NTP, resynchroniser, relancer une authentification ; réessayer.

Annexe — Rappels de commandes utiles

# Localisation des DC
nltest /dsgetdc:<domaineA>
nltest /dsgetdc:<domaineB>

# Secure channel (lecture & réparation)

nltest /sc_query:
PowerShell: Test-ComputerSecureChannel -Repair -Credential 

# Confiance

netdom trust  /domain: /verify

# Santé AD

dcdiag /v
repadmin /replsummary
repadmin /showrepl

# Kerberos

klist purge
klist get             # ex: cifs/serveurB.domaineB
setspn -Q 
setspn -S  

# Temps

w32tm /query /status
w32tm /resync

# DNS SRV

nslookup -type=SRV _ldap._tcp.dc._msdcs. 

Conclusion

Dans un contexte de domaines en confiance, un client sollicite d’abord son DC local, qui émet ensuite une référence vers un DC du domaine partenaire. L’erreur STATUS_NO_LOGON_SERVERS signalera donc une incapacité à joindre l’un de ces DC (local ou distant) dans le délai imparti. En appliquant la démarche ci‑dessus (réseau, DNS, confiance, sites, Kerberos, temps, santé des DC), vous éliminerez la majorité des causes et rétablirez une authentification inter‑domaines fiable.

---

Informations complémentaires pertinentes

• Compatibilité SMB / NTLM vs. Kerberos : si la ressource cible force Kerberos mais qu’aucun ticket n’est délivré (horloge ou SPN incorrect), le client retombe sur NTLM, qui dépend encore plus du DC local ; d’où l’apparition fréquente de STATUS_NO_LOGON_SERVERS.
• Comportement hors ligne : Windows conserve (cache) quelques informations d’authentification interactives, mais ce cache n’est pas utilisé pour les connexions réseau inter‑domaines ; dès que toutes les copies DC sont injoignables, l’accès échoue.
• Sécurité : ne jamais ouvrir en permanence tous les ports AD à Internet ; privilégier un VPN site‑à‑site ou une DMZ LDAP/LDAP‑S pour la confiance externe.