MENU
  1. Accueil
  2. Windows
  3. Windows11
  4. Windows 11 VM : résoudre les erreurs 0x525 & 0x54B lors de la jointure à Active Directory (DNS, FQDN, Kerberos, ports)

Windows 11 VM : résoudre les erreurs 0x525 & 0x54B lors de la jointure à Active Directory (DNS, FQDN, Kerberos, ports)

Windows11

Un PC Windows 11 en VM refuse de rejoindre un domaine Active Directory ? Voici une méthode pas‑à‑pas, pragmatique et éprouvée, pour diagnostiquer les erreurs 0x525 et 0x54B et réussir la jointure, avec commandes prêtes à l’emploi et check‑lists.

Sommaire

Impossible de joindre un domaine AD depuis une VM Windows 11

Vue d’ensemble du scénario

Vous essayez d’inscrire une VM Windows 11 dans le domaine HOMEDOMAIN (FQDN supposé : homedomain.local). La jointure échoue. Dans C:\Windows\debug\NetSetup.log on trouve notamment :

  • failed to find a DC having account 'W11-1$': 0x525 → 0x525 = 1317 = « The specified account does not exist » (compte machine introuvable).
  • failed to find a DC in the specified domain: 0x54b → 0x54B = 1355 = « The specified domain either does not exist or could not be contacted » (domaine introuvable ou injoignable).

Pourtant, un nltest /dsgetdc:homedomain renvoie bien le contrôleur de domaine 2016‑DC à 192.168.81.14. Ce paradoxe est classique : on peut « voir un DC » avec certains tests, tout en échouant la jointure pour des raisons de nommage, de DNS SRV, d’horloge, de ports, ou de droits.

Analyse rapide : causes probables

  1. Nom utilisé pour la jointure : tentative avec le NetBIOS name HOMEDOMAIN au lieu du FQDN homedomain.local. Cela déclenche fréquemment 1355 malgré des tests nltest « OK ».
  2. Résolution DNS AD/SRV : la jointure repose sur les enregistrements SRV (_ldap._tcp, _kerberos._tcp, etc.). DNS publics configurés sur le client ou SRV manquants → échec 1355.
  3. Dérive d’horloge (Kerberos) : au‑delà d’environ 5 minutes d’écart entre client et DC, l’authentification échoue.
  4. Ports/réseau : filtrage de DNS 53, Kerberos 88, RPC 135 + RPC dynamiques, LDAP 389, SMB 445 → jointure impossible.
  5. Compte machine (0x525) : l’objet ordinateur W11-1 n’existe pas, est désactivé ou l’utilisateur n’a pas les droits pour le créer.

Pourquoi nltest paraît « OK » mais la jointure échoue ?

Le DC Locator s’appuie sur des requêtes DNS et SRV. nltest /dsgetdc peut réussir (p. ex. une entrée mise en cache, ou un DNS qui répond partiellement), alors que la jointure, plus exigeante (Kerberos, LDAP, RPC, création d’objet AD), échoue. De plus, joindre en NetBIOS (HOMEDOMAIN) contourne les résolutions FQDN et peut conduire vers le mauvais mécanisme de localisation.

Plan d’action recommandé

Configurer et vérifier le DNS du client (fondamental)

Sur la carte réseau de la VM Windows 11, configurez uniquement des DNS internes AD : l’adresse du DC (192.168.81.14) en primaire, un second DNS AD interne si disponible. Aucun DNS public (8.8.8.8, 1.1.1.1, etc.).

ipconfig /all
Get-DnsClientServerAddress

Vérifiez les enregistrements critiques :

nslookup homedomain.local
nslookup 2016-DC.homedomain.local
nslookup -type=SRV _ldap._tcp.dc._msdcs.homedomain.local
nslookup -type=SRV _kerberos._tcp.homedomain.local

Résultats attendus : _ldap._tcp.dc._msdcs.homedomain.local doit renvoyer le ou les DC (ici 2016-DC) avec la bonne IP. Si les SRV manquent, corrigez la zone DNS AD sur le DC et forcez un nouvel enregistrement :

ipconfig /registerdns
ipconfig /flushdns

Joindre le domaine avec le FQDN

Utilisez toujours le FQDN (homedomain.local) plutôt que le nom NetBIOS (HOMEDOMAIN). Par interface graphique, entrez le FQDN. En ligne de commande :

netdom join W11-1 /domain:homedomain.local /userd:HOMEDOMAIN\Compte_Admin /passwordd:* /reboot

Cette commande demande (au besoin) la création de l’objet ordinateur et redémarre la machine en fin de jointure.

Synchroniser l’heure (Kerberos)

Contrôlez l’écart d’horloge : l’authentification Kerberos tolère environ 300 secondes d’écart.

w32tm /query /status

Avant la jointure, vous pouvez forcer la VM à se synchroniser sur le DC :

w32tm /config /manualpeerlist:192.168.81.14 /syncfromflags:manual /update
w32tm /resync /nowait

Après la jointure, le client utilisera automatiquement la hiérarchie NTP du domaine.

Vérifier la connectivité et les ports

Testez les ports essentiels depuis la VM vers le DC :

Test-NetConnection 192.168.81.14 -Port 53
Test-NetConnection 192.168.81.14 -Port 88
Test-NetConnection 192.168.81.14 -Port 135
Test-NetConnection 192.168.81.14 -Port 389
Test-NetConnection 192.168.81.14 -Port 445

Assurez-vous d’autoriser la plage RPC dynamique (TCP 49152–65535) côté DC (pare‑feu local et réseau).

Gérer le compte ordinateur W11-1 si 0x525 persiste

  • Pré‑création : créez l’objet dans l’OU cible (ADUC ou New-ADComputer), puis relancez la jointure.
  • Objet existant mais défaillant : réinitialisez le compte (Reset Account) ou supprimez‑le/recréez‑le proprement.
  • Droits : l’utilisateur doit disposer du droit « Ajouter des stations de travail au domaine » ou de permissions déléguées sur l’OU de destination. Par défaut, l’attribut msDS-MachineAccountQuota (valeur 10) limite les créations d’ordinateurs par utilisateur standard.

Valider la santé du DC/DNS

Sur le contrôleur de domaine, exécutez :

dcdiag /test:dns /DnsRecordRegistration
dcdiag /v

Corrigez toute anomalie (SRV manquants, zones non intégrées à AD, échec de mise à jour dynamique, multi‑homing mal configuré, etc.).

Relancer la jointure et analyser les journaux

Après correctifs, relancez la jointure (UI ou netdom join). En cas d’échec, collectez :

  • NetSetup.log : C:\Windows\debug\NetSetup.log
  • Journal Système : événements Netlogon (par ex. 5719, 5783), LSASRV (40960/40961), GroupPolicy (1055, 1129), DNS Client (1014)
  • Résultats des commandes nltest, nslookup, Test‑NetConnection, w32tm

Tableaux de référence

Codes d’erreur et signification

CodeInterprétationPiste prioritaire
0x54B / 1355Le domaine n’existe pas ou est injoignableDNS SRV, ports vers DC, jointure en FQDN
0x525 / 1317Le compte spécifié n’existe pasObjet ordinateur absent/désactivé, droits de création

Ports à ouvrir pour la jointure AD

ServicePortProtocoleRemarques
DNS53TCP/UDPRésolution FQDN et requêtes SRV
Kerberos88TCP/UDPAuthentification domaine
RPC Endpoint Mapper135TCPNécessaire à de nombreux services AD
LDAP389TCP/UDPAnnuaire (port non‑SSL)
SMB445TCPPartages, Netlogon, scripts
RPC dynamiques49152–65535TCPAllouer côté DC si filtrage présent

Checklist rapide avant la jointure

ContrôleCommande / ActionRésultat attendu
DNS clientIP du DC seulement en DNSAucun DNS public
SRV ADnslookup -type=SRV _ldap._tcp.dc._msdcs.homedomain.localRetourne 2016‑DC
Heurew32tm /query /statusÉcart <= 5 min
PortsTest-NetConnection sur 53/88/135/389/445Connexion établie
Compte machinePré‑création ou droits Add WorkstationsObjet OK ou création autorisée
Nom de domaineUtiliser homedomain.localPas de NetBIOS seul

Diagnostics ciblés côté client

Valider la pile DNS

ipconfig /flushdns
Get-DnsClient | Where-Object {$_.ConnectionSpecificSuffix -ne $null} | 
  Select-Object InterfaceAlias, ConnectionSpecificSuffix

# Facultatif : imposer le suffixe primaire si nécessaire

wmic computersystem where name="%computername%" call joindomainorworkgroup name="homedomain.local"

Si le suffixe DNS principal du client n’est pas défini ou diverge, certaines résolutions peuvent échouer. Évitez de cumuler des suffixes non nécessaires.

Tester la découverte de DC

nltest /dsgetdc:homedomain.local /force
nltest /dclist:homedomain
nltest /dnsgetdc:homedomain.local

/dnsgetdc permet de forcer l’usage DNS lors de la découverte.

Valider la création de l’objet ordinateur

# Si vous disposez des RSAT
New-ADComputer -Name "W11-1" -SamAccountName "W11-1$" -Path "OU=Workstations,DC=homedomain,DC=local"

Si la création échoue, revoyez vos droits ou la valeur de msDS-MachineAccountQuota.

Nettoyer une tentative de jointure incomplète

netdom remove W11-1 /domain:homedomain.local /force
# puis nouvelle tentative
netdom join W11-1 /domain:homedomain.local /userd:HOMEDOMAIN\Compte_Admin /passwordd:*

Diagnostics côté DC

Vérifier DNS et enregistrements SRV

dcdiag /test:dns /DnsRecordRegistration
ipconfig /registerdns
Get-WinEvent -LogName "DNS Server" -MaxEvents 50 | Format-Table TimeCreated, Id, Message -Auto

Surveiller les erreurs de mise à jour dynamique, les zones non intégrées à AD, ou un DC multi‑homé avec enregistrements incohérents.

Contrôler Netlogon et Kerberos

Get-WinEvent -LogName System -FilterXPath "*[System[Provider[@Name='NETLOGON']]]" -MaxEvents 50 |
  Format-Table TimeCreated, Id, Message -Auto

Get-WinEvent -LogName System -FilterXPath "\*\[System\[Provider\[@Name='LSASRV']]]" -MaxEvents 50 |
Format-Table TimeCreated, Id, Message -Auto

Éviter les pièges de l’hébergement virtualisé

  • Mode réseau VM : préférez Bridged ou un réseau interne où le DC est accessible directement. En NAT, vérifiez routes et filtrages (notamment RPC dynamiques).
  • Horloge VM : désactivez la synchronisation horaire « outil hyperviseur » si elle entre en conflit avec NTP Windows.
  • Snapshots : un retour en arrière peut restaurer un compte ordinateur désynchronisé (mauvais password de canal sécurisé). Réinitialisez le compte dans ADUC et rejoignez à nouveau.

Comprendre ce qui se passe sous le capot

DC Locator, FQDN et SRV

Lors d’une jointure, le client interroge le DNS pour les enregistrements _ldap._tcp.dc._msdcs.<domaine> afin d’identifier un contrôleur de domaine répondant. Avec un FQDN, la résolution s’appuie sur ces enregistrements. Avec un nom NetBIOS seul, Windows peut tenter des mécanismes hérités (WINS/NetBIOS), souvent absents dans les environnements modernes, d’où les erreurs 1355.

Kerberos et tolérance d’horloge

Kerberos protège contre la relecture en tenant compte de l’horodatage des tickets ; au‑delà d’environ 5 minutes d’écart, l’authentification échoue. C’est pourquoi « ça ping » n’est jamais un indicateur suffisant de la capacité à joindre un domaine : il faut un temps correct, des SRV valides, et des ports ouverts.

Canal sécurisé et compte ordinateur

Un poste joint au domaine entretient un mot de passe de compte ordinateur (canal sécurisé) renouvelé automatiquement. Si l’objet AD est absent, désactivé, ou si un snapshot VM réintroduit un secret obsolète, l’authentification côté DC échoue (0x525). La réparation consiste à réinitialiser l’objet ordinateur et rejouer la jointure.

Procédure express reproduisible

  1. Sur la VM, configurez le DNS : 192.168.81.14 uniquement.
  2. Vérifiez SRV : nslookup -type=SRV _ldap._tcp.dc._msdcs.homedomain.local.
  3. Alignez l’heure : w32tm /config /manualpeerlist:192.168.81.14 /syncfromflags:manual /update puis w32tm /resync.
  4. Testez les ports : Test-NetConnection vers 53/88/135/389/445.
  5. Pré‑créez ou réinitialisez W11-1 si besoin, vérifiez les droits.
  6. Joignez avec le FQDN : netdom join W11-1 /domain:homedomain.local ....
  7. Redémarrez, contrôlez les journaux Netlogon et NetSetup.log.

Dépannage approfondi

Vérifier le suffixe DNS et le nom d’ordinateur

sysdm.cpl
# Onglet Nom de l’ordinateur
# Vérifier «&nbsp;Domaine&nbsp;» et suffixe DNS primaire dans les paramètres avancés

Un suffixe primaire incohérent peut provoquer des requêtes vers un domaine erroné.

Forcer la résolution via le DC

Resolve-DnsName 2016-DC.homedomain.local -Server 192.168.81.14
Resolve-DnsName _ldap._tcp.dc._msdcs.homedomain.local -Type SRV -Server 192.168.81.14

Si Resolve-DnsName échoue en pointant directement le DC, votre problème est DNS/DC (et non client).

Nettoyer la pile réseau

ipconfig /flushdns
nbtstat -R
netsh winsock reset
netsh int ip reset

Utilisez‑les avec prudence : un reset IP/Winsock impose généralement un redémarrage.

Écarter les conflits d’adresses

arp -a
ping 192.168.81.14
tracert 192.168.81.14

Un conflit ARP ou un routage inattendu vers le DC empêche la jointure. Sur des VLANs, assurez‑vous que le trafic TCP/UDP nécessaire est autorisé au‑delà du ping.

Cas des environnements multi‑domaines ou forêts

Si HOMEDOMAIN n’est qu’un alias (UPN suffix) et que le FQDN DNS réel est différent, utilisez toujours le FQDN AD réel (DC=...,DC=...) pour la jointure. Les suffixes UPN ne suffisent pas aux couches DNS.

FAQ

Faut‑il désactiver IPv6 pour joindre un domaine ?

Non. AD moderne fonctionne en IPv4 et IPv6. Ne désactivez IPv6 que si vous maîtrisez tous les impacts (DNS AAAA, GPO, services). Concentrez‑vous d’abord sur les SRV, le FQDN et l’horloge.

Un DNS public en secondaire peut‑il rester configuré ?

Non pour les machines jointes au domaine. Le client doit utiliser exclusivement les serveurs DNS AD, qui eux-mêmes relayent Internet via des forwarders ou les root hints.

Le message « Le domaine n’existe pas » alors que nltest répond, c’est normal ?

Oui, parce que la jointure consomme plus qu’une simple découverte : Kerberos, LDAP, RPC, création d’objet AD. Un maillon défaillant (SRV, ports, heure) suffit à échouer.

Comment savoir si le compte ordinateur est le problème ?

L’erreur 0x525 dans NetSetup.log et un événement Netlogon côté DC pointent vers un objet absent/désactivé. Solution : pré‑créer ou réinitialiser l’objet, puis joindre en FQDN.

Exemples concrets : scripts et commandes utiles

Script PowerShell de diagnostic éclair

# À exécuter sur la VM Windows 11
$DomainFqdn = "homedomain.local"
$DcIp = "192.168.81.14"

Write-Host "=== DNS du client ==="
Get-DnsClientServerAddress | Where-Object {$\_.Address -ne \$null} | Format-Table

Write-Host "=== SRV LDAP/Kerberos ==="
Resolve-DnsName "\_ldap.\_tcp.dc.\_msdcs.\$DomainFqdn" -Type SRV -Server \$DcIp
Resolve-DnsName "\_kerberos.\_tcp.\$DomainFqdn" -Type SRV -Server \$DcIp

Write-Host "=== Connectivité ports ==="
53,88,135,389,445 | ForEach-Object { Test-NetConnection \$DcIp -Port $\_ | Select-Object ComputerName,RemotePort,TcpTestSucceeded }

Write-Host "=== Statut temps ==="
w32tm /query /status

Write-Host "=== DC Locator ==="
nltest /dnsgetdc:\$DomainFqdn

Script PowerShell pour forcer DNS interne et suffixe

# Adapter "Ethernet" au nom de l'interface si besoin
$IfAlias = "Ethernet"
Set-DnsClientServerAddress -InterfaceAlias $IfAlias -ServerAddresses @("192.168.81.14")
Set-DnsClient -InterfaceAlias $IfAlias -ConnectionSpecificSuffix "homedomain.local" -UseSuffixWhenRegistering $true
ipconfig /flushdns

Commande d’épreuve de force de jointure

netdom join %COMPUTERNAME% /domain:homedomain.local /OU:"OU=Workstations,OU=Paris,DC=homedomain,DC=local" /userd:HOMEDOMAIN\Compte_Admin /passwordd:* /reboot

Spécifier l’OU cible évite que l’objet atterrisse par défaut dans Computers.

Pièges fréquents et solutions

  • DNS publics en secours : supprimez‑les. Même « en secondaire », ils perturbent les SRV.
  • VPN fractionné : un split‑tunnel mal réglé fait sortir les requêtes DNS/srv vers Internet. Forcez le DNS AD via le VPN.
  • DC multi‑homé : des enregistrements A/SRV « parasites » pointent vers une mauvaise interface. Fixez les priorités ou filtrez l’enregistrement dynamique.
  • Zone DNS sans mises à jour dynamiques : autorisez les mises à jour sécurisées pour que le DC publie ses SRV.
  • Horloge VM asynchrone : désactivez la synchro de l’hyperviseur qui écrase NTP Windows.
  • Nom NetBIOS mal orthographié : le FQDN écarte l’ambiguïté et suit les recommandations modernes.
  • Limite de création d’ordinateurs : msDS-MachineAccountQuota atteint → demandez un compte avec droits ou pré‑créez l’objet.

Étude de cas : « nltest OK, jointure KO »

Contexte : nltest /dsgetdc:homedomain renvoie 2016‑DC 192.168.81.14. Tentative de jointure en HOMEDOMAIN → 0x54B. Le client utilisait en DNS primaire le routeur (avec forwarders Internet) et en secondaire le DC. Les requêtes SRV partaient parfois vers l’Internet (qui ne connaît pas votre domaine AD) : jointure impossible. Correction : DNS primaire = DC uniquement, suppression du DNS routeur, jointure via homedomain.local → succès.

Résumé opérationnel

  • Configurer DNS AD uniquement sur la VM et vérifier les SRV _ldap/_kerberos.
  • Joindre en FQDN : homedomain.local, pas le NetBIOS.
  • Aligner l’heure (tolérance Kerberos ~ 5 min).
  • Valider les ports 53, 88, 135, 389, 445 + RPC dynamiques.
  • Pré‑créer ou réinitialiser le compte ordinateur si 0x525 persiste.
  • Sur le DC, exécuter dcdiag /test:dns et corriger toute anomalie.

En suivant ce plan, vous supprimez les causes les plus courantes des combinaisons 0x525 / 0x54B et, dans l’immense majorité des cas, vous réussissez la jointure d’un poste Windows 11 (VM) à un domaine Active Directory.

Annexes utiles

Commandes de vérification post‑jointure

whoami /fqdn
echo %LOGONSERVER%
nltest /sc_verify:homedomain.local
gpupdate /force

/sc_verify valide le canal sécurisé (compte ordinateur). gpupdate confirme la communication GPO.

Exemple de lecture de NetSetup.log

2025/09/01 10:12:15: NetpDoDomainJoin: entering...
2025/09/01 10:12:15: NetpGetLsaPrimaryDomain: status: 0x0
2025/09/01 10:12:16: NetpDsGetDcName: failed to find a DC in the specified domain: 0x54b
2025/09/01 10:12:16: NetpJoinDomain: status of connecting to DC: 0x54b
2025/09/01 10:12:17: NetpValidateName: checking to see if 'W11-1' is valid as type 1 name
2025/09/01 10:12:17: NetpCheckDomainNameIsValid: 'HOMEDOMAIN' is a valid NetBIOS name for domain
2025/09/01 10:12:18: NetpGetComputerObjectDn: failed to find a DC having account 'W11-1$': 0x525

Ce pattern illustre un double problème : localisation de DC en NetBIOS et compte machine absent. Rejoindre en FQDN et créer/réinitialiser l’objet résout le cas.

En bref : DNS AD only → SRV OK → FQDN → heure synchronisée → ports ouverts → compte ordinateur valide → dcdiag propre → jointure réussie.

Windows11
Active Directory DNS Windows 11 Kerberos troubleshooting netdom
Sommaire