il y a 1 an

Joindre Windows 10/11 à un domaine : DNS, Active Directory et diagnostic

Joindre un ordinateur Windows à un domaine Active Directory paraît simple :

indiquer le domaine
entrer un compte
redémarrer
terminé

Et lorsque toute l’infrastructure est correctement configurée, c’est effectivement presque aussi simple.

Mais derrière le sympathique message :

« Bienvenue dans le domaine chapal.lan »

Windows vient en réalité de mobiliser :

DNS ;
Active Directory ;
LDAP ;
Kerberos ;
Netlogon ;
RPC ;
SMB ;
un compte ordinateur ;
un secret partagé entre la machine et le domaine ;
et probablement plusieurs années de documentation Microsoft.

Autrement dit, cliquer sur :

Domaine : chapal.lan

est la partie visible.

Tout le reste se déroule derrière.

Une adhésion Active Directory réussie dépend avant tout de trois choses : DNS correct, contrôleur de domaine joignable et autorisations adaptées.

Le scénario utilisé dans cet article

Nous allons prendre comme exemple :

Domaine DNS Active Directory : chapal.lan

Contrôleur de domaine :
dc1.chapal.lan

Adresse du DC :
192.168.1.100

Poste client :
PC-COMPTA-01

Utilisateur du domaine :
chapalthebest

Nous supposerons également, pour certains exemples, que le nom NetBIOS du domaine est :

CHAPAL

Mais ce point devra être vérifié dans votre propre environnement.

Windows 10 en 2026 : précision importante

La procédure décrite reste techniquement applicable à Windows 10 capable de rejoindre Active Directory.

Mais Windows 10 22H2 standard a atteint sa fin de support le :

14 octobre 2025

En 2026, un nouveau poste devrait donc normalement être déployé sous une version prise en charge de :

Windows 11

sauf contexte particulier comme :

programme Extended Security Updates ;
édition LTSC disposant de son propre cycle ;
contrainte applicative temporaire documentée.

Joindre parfaitement au domaine un système qui ne reçoit plus les correctifs prévus n’est pas exactement la définition d’un projet de modernisation réussi.

Quelles éditions Windows peuvent rejoindre un domaine ?

Les éditions clientes compatibles comprennent notamment :

Windows Pro ;
Windows Pro N ;
Windows Pro Education ;
Windows Pro for Workstations ;
Windows Enterprise.

Selon génération et licence, certaines éditions Education sont également concernées.

En revanche :

Windows Home

ne permet pas l’adhésion classique à un domaine Active Directory.

Vous pouvez vérifier l’édition avec :

winver

ou :

Settings
→ System
→ About

Et en PowerShell :

Get-ComputerInfo |
    Select-Object WindowsProductName, WindowsVersion

Active Directory local et Microsoft Entra ID : ne cliquez pas sur le mauvais bouton

Windows moderne peut participer à plusieurs modèles d’identité.

Il faut notamment distinguer :

Active Directory Domain Services
AD DS
domaine local / on-premises

de :

Microsoft Entra ID
anciennement Azure AD
identité cloud

Dans cet article, notre objectif est :

chapal.lan
→ Active Directory Domain Services local

Dans les Paramètres Windows, ne sélectionnez donc pas :

Join this device to Microsoft Entra ID

si votre intention est de rejoindre le domaine AD local.

Il faut choisir :

Join this device to a local Active Directory domain

La différence tient à quelques mots.

L’architecture derrière tient à quelques milliers de pages de documentation.

Que signifie réellement « joindre un domaine » ?

Un ordinateur membre d’Active Directory n’est pas simplement un PC sur lequel un utilisateur du domaine peut entrer son mot de passe.

L’ordinateur possède lui-même une identité dans Active Directory.

Après l’adhésion, on trouve un objet :

PC-COMPTA-01$

Le caractère :

est associé à la représentation du compte ordinateur.

Conceptuellement :

Utilisateur :
CHAPAL\chapalthebest

Ordinateur :
CHAPAL\PC-COMPTA-01$

Le compte ordinateur possède son propre secret

Lors de l’adhésion, Windows établit une relation de confiance entre :

le poste
et
le domaine

Cette relation utilise notamment un mot de passe de compte ordinateur géré automatiquement.

L’administrateur ne tape normalement jamais ce mot de passe.

Windows le gère.

C’est ce mécanisme qui participe à la création du :

secure channel
canal sécurisé

entre le membre et le domaine.

Le fameux message « relation d’approbation échouée »

Lorsque le secret présent sur le poste et celui connu d’Active Directory ne correspondent plus correctement, on peut rencontrer :

« The trust relationship between this workstation and the primary domain failed. »

Ce message ne signifie pas nécessairement :

« Active Directory entier vient de mourir. »

Il peut simplement indiquer que le canal sécurisé du poste concerné est cassé.

Nous verrons plus loin comment le tester.

Conditions préalables

Avant de joindre :

PC-COMPTA-01

au domaine :

chapal.lan

vérifiez au minimum :

que l’édition Windows supporte l’adhésion au domaine ;
que le poste dispose d’un compte administrateur local fonctionnel ;
que le réseau vers les services Active Directory est opérationnel ;
que DNS peut résoudre le domaine et découvrir les DC ;
que l’heure du poste est raisonnablement correcte ;
que le nom de la machine est définitif ou au moins prévu ;
que le compte utilisé possède les permissions nécessaires pour joindre l’ordinateur.

Gardez toujours un administrateur local fonctionnel

Avant l’adhésion, assurez-vous de connaître un compte local capable d’administrer la machine.

Par exemple :

.\localadmin

ou :

PC-COMPTA-01\localadmin

Après la jointure, ce compte peut être précieux si :

le réseau tombe ;
le DNS est cassé ;
le secure channel est rompu ;
une GPO produit un résultat malheureux ;
le poste doit quitter le domaine.

Supprimer le seul accès local avant d’avoir testé correctement l’environnement domaine constitue une excellente manière de transformer un problème réseau en déplacement physique.

Étape 0 : choisir le bon nom de machine

Il est généralement préférable de nommer le poste correctement avant son adhésion.

Par exemple :

PC-COMPTA-01

plutôt que :

DESKTOP-R7FX3Q2

Une convention peut contenir :

type d’équipement ;
site ;
service ;
numéro d’inventaire.

Par exemple :

PC-PAR-FIN-014
LT-BRU-IT-022

Évitez cependant de créer des noms tellement sophistiqués qu’un administrateur doit consulter une documentation de huit pages pour savoir comment nommer un portable.

Afficher le nom actuel

hostname

ou :

$env:COMPUTERNAME

Renommer avec PowerShell

Dans une console élevée :

Rename-Computer -NewName "PC-COMPTA-01" -Restart

Après redémarrage :

hostname

doit afficher le nouveau nom.

DNS : le point le plus important

Active Directory dépend fortement de DNS.

Le client ne doit pas simplement être capable de traduire :

dc1.chapal.lan
→ 192.168.1.100

Il doit également découvrir les services Active Directory grâce à des enregistrements :

SRV

comme :

_ldap._tcp.dc._msdcs.chapal.lan

Ces enregistrements indiquent où trouver les contrôleurs de domaine appropriés.

Il n’existe plus de « PDC obligatoire » pour l’adhésion

Dans les anciens domaines Windows NT, on parlait réellement de :

PDC
Primary Domain Controller

et :

BDC
Backup Domain Controller

Ce modèle n’est plus celui d’Active Directory moderne.

Dans AD DS, plusieurs contrôleurs de domaine inscriptibles peuvent normalement répondre aux opérations.

Le client utilise :

DC Locator

pour trouver un contrôleur approprié.

Le PDC Emulator existe toujours

Active Directory possède cependant un rôle FSMO appelé :

PDC Emulator

Il remplit plusieurs fonctions importantes, notamment liées :

à certaines opérations de mot de passe ;
au temps du domaine ;
à certaines compatibilités historiques ;
à certaines opérations administratives.

Mais cela ne signifie pas :

« Chaque poste doit obligatoirement joindre le domaine via le PDC Emulator. »

Configurer les bons DNS

Dans notre exemple, supposons :

DC1 / DNS1 : 192.168.1.100
DC2 / DNS2 : 192.168.1.101

Le client devrait utiliser :

DNS préféré   : 192.168.1.100
DNS alternatif : 192.168.1.101

si ces deux DNS savent résoudre correctement :

chapal.lan

et ses enregistrements Active Directory.

Un DNS AD n’est pas forcément physiquement un DC

Dans de nombreuses petites infrastructures :

DC
=
DNS Active Directory

Mais conceptuellement, l’obligation est plutôt :

le client doit utiliser un DNS capable de résoudre correctement le namespace Active Directory.

Le rôle DNS est très fréquemment installé sur les contrôleurs de domaine parce que cette architecture est pratique et hautement intégrée.

Ne mettez pas 8.8.8.8 comme « secours » sur le client domaine

Une configuration comme :

DNS 1 : 192.168.1.100
DNS 2 : 8.8.8.8

est une mauvaise conception pour un membre Active Directory.

Le DNS public :

8.8.8.8

ne connaît pas :

_ldap._tcp.dc._msdcs.chapal.lan

et il n’a aucune raison de le connaître.

La bonne architecture

Poste Windows
    ↓
DNS interne AD
    │
    ├── chapal.lan → réponse locale
    │
    └── google.com → forwarder
                         ↓
                    DNS externe

Les clients interrogent donc leurs DNS internes.

Ce sont ces DNS qui transmettent les demandes externes lorsque nécessaire.

Afficher les DNS du client

ipconfig /all

Examinez notamment :

DNS Servers
DHCP Enabled
IPv4 Address
Default Gateway

Avec PowerShell :

Get-DnsClientServerAddress

Configurer les DNS avec PowerShell

Par exemple :

Set-DnsClientServerAddress `
    -InterfaceAlias "Ethernet" `
    -ServerAddresses 192.168.1.100,192.168.1.101

Vérifiez ensuite :

Get-DnsClientServerAddress `
    -InterfaceAlias "Ethernet"

DHCP est souvent le meilleur endroit pour distribuer les DNS

Si tous les postes d’un VLAN doivent utiliser :

192.168.1.100
192.168.1.101

il est généralement plus propre de configurer ces valeurs dans :

les options DHCP

plutôt que modifier manuellement cinquante postes.

IPv6 mérite aussi votre attention

Un Windows moderne peut utiliser :

IPv4 ;
IPv6.

Si IPv6 est actif et configuré dans l’infrastructure, ses serveurs DNS doivent eux aussi être cohérents avec Active Directory.

Ne désactivez pas IPv6 au hasard pour :

« simplifier Active Directory ».

Windows moderne utilise IPv6 nativement et de nombreux scénarios le supportent parfaitement.

Un problème de configuration se résout par une bonne configuration.

Pas nécessairement en retirant un protocole entier.

Tester DNS correctement

L’original proposait :

ping chapal.lan
ping dc1.chapal.lan
nslookup chapal.lan

Ces tests peuvent être utiles.

Mais aucun ne valide complètement la découverte Active Directory.

Pourquoi ping n’est pas un test AD suffisant

Un ping peut échouer simplement parce que :

ICMP est filtré

alors que :

DNS
LDAP
Kerberos
SMB
RPC

fonctionnent parfaitement.

Inversement :

ping dc1.chapal.lan

peut réussir alors que les enregistrements SRV Active Directory sont cassés.

Tester le FQDN du contrôleur

Resolve-DnsName dc1.chapal.lan

ou :

nslookup dc1.chapal.lan

Vous devez obtenir l’adresse attendue.

Tester les enregistrements SRV Active Directory

Avec PowerShell :

Resolve-DnsName `
    -Type SRV `
    _ldap._tcp.dc._msdcs.chapal.lan

Avec nslookup :

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

Vous devriez obtenir un ou plusieurs contrôleurs de domaine.

Par exemple :

_ldap._tcp.dc._msdcs.chapal.lan

SRV service location:
    priority = 0
    weight   = 100
    port     = 389
    svr hostname = dc1.chapal.lan

Kerberos possède aussi ses enregistrements SRV

Vous pouvez examiner :

Resolve-DnsName `
    -Type SRV `
    _kerberos._tcp.chapal.lan

ou :

Resolve-DnsName `
    -Type SRV `
    _kerberos._tcp.dc._msdcs.chapal.lan

Le meilleur test simple : nltest

Avant l’adhésion :

nltest /dsgetdc:chapal.lan /force

Un résultat correct ressemble conceptuellement à :

DC: \\dc1.chapal.lan
Address: \\192.168.1.100
Dom Name: chapal.lan
Forest Name: chapal.lan
Dc Site Name: Default-First-Site-Name
Flags: GC DS LDAP KDC TIMESERV WRITABLE DNS_DC ...

Cette commande demande explicitement au mécanisme DC Locator :

« Trouve-moi un contrôleur pour chapal.lan. »

C’est donc infiniment plus intéressant que :

ping google.com

pour déterminer si Active Directory fonctionne.

Forcer la recherche d’un KDC

nltest /dsgetdc:chapal.lan /force /kdc

peut être utile lorsqu’on diagnostique spécifiquement Kerberos.

Tester les principaux ports

Si le DNS fonctionne mais que la jointure échoue, examinez le pare-feu et le routage.

Par exemple :

Test-NetConnection dc1.chapal.lan -Port 53
Test-NetConnection dc1.chapal.lan -Port 88
Test-NetConnection dc1.chapal.lan -Port 135
Test-NetConnection dc1.chapal.lan -Port 389
Test-NetConnection dc1.chapal.lan -Port 445

Attention :

ces quelques tests ne couvrent pas à eux seuls tous les besoins d’Active Directory.

Le domain join utilise notamment des ports RPC dynamiques en plus des ports bien connus.

Ports importants pour une adhésion

Port	Protocole	Rôle
53	TCP/UDP	DNS
88	TCP et selon contexte UDP	Kerberos
389	TCP/UDP	LDAP / DC Locator
135	TCP	RPC Endpoint Mapper
445	TCP	SMB
Ports RPC dynamiques	TCP	Netlogon, SAMR et autres appels RPC

Sur les Windows modernes, la plage dynamique est généralement large.

Si un pare-feu réseau se trouve entre :

poste
et
contrôleurs de domaine

n’inventez pas une liste de ports minimaliste au hasard.

Utilisez les exigences Microsoft correspondant à l’architecture réelle.

Le DNS peut fonctionner et le firewall casser la jointure

Ce scénario :

Resolve-DnsName : OK
nltest : partiellement OK
domain join : FAIL

peut parfaitement provenir :

de RPC bloqué ;
de SMB bloqué ;
de LDAP bloqué ;
du routage ;
d’une ACL réseau.

Vérifier l’heure

Kerberos dépend fortement d’horloges cohérentes.

La configuration courante de domaine utilise une tolérance de :

5 minutes

pour la synchronisation nécessaire à Kerberos.

Mais il ne faut pas en déduire :

« Tant que je suis à 4 minutes 59, tout est parfait. »

Une infrastructure saine garde des horloges beaucoup plus proches.

Afficher l’heure

time /t
date /t

Plus utilement :

w32tm /query /status

et :

w32tm /query /source

Avant la jointure

Un poste encore en workgroup n’utilise pas encore la hiérarchie de temps du domaine.

Assurez-vous donc que :

date ;
heure ;
fuseau horaire ;

sont corrects.

Après la jointure

Les membres du domaine utilisent normalement la hiérarchie Windows Time du domaine.

On peut demander une resynchronisation :

w32tm /resync

si le service et sa configuration permettent l’opération.

Le compte de jointure n’est pas forcément le futur utilisateur

C’est une distinction importante.

Le compte :

chapalthebest

peut être :

un utilisateur qui se connectera quotidiennement au poste ;
un compte disposant aussi des droits de joindre les postes ;
ou simplement le compte utilisé dans votre exemple.

Mais il n’existe aucune obligation que :

compte utilisé pour joindre
=
compte du futur utilisateur

En production : déléguez les droits

Une meilleure architecture peut utiliser :

CHAPAL\svc-domainjoin

ou un groupe d’administrateurs délégués possédant uniquement les permissions nécessaires sur :

OU=Postes,DC=chapal,DC=lan

plutôt que :

Domain Admins

pour toutes les adhésions quotidiennes.

Le compte utilisateur ordinaire n’a pas besoin d’être Domain Admin

Pour ouvrir ensuite une session :

CHAPAL\chapalthebest

le compte doit simplement posséder les droits nécessaires pour s’authentifier et utiliser le poste selon vos stratégies.

Il n’a aucune raison de devenir administrateur du domaine simplement parce qu’il possède un clavier.

Droits de jointure : ne comptez pas aveuglément sur les valeurs par défaut

Active Directory possède historiquement un mécanisme :

Add workstations to domain

lié notamment à :

ms-DS-MachineAccountQuota

qui peut autoriser des utilisateurs à créer un certain nombre de comptes ordinateurs.

Pour une infrastructure professionnelle, préférez généralement :

une délégation explicite
sur l'OU prévue
à un groupe ou compte prévu

plutôt que compter sur une permission historique large.

Précréer l’objet ordinateur

Dans :

Active Directory Users and Computers
dsa.msc

vous pouvez créer :

PC-COMPTA-01

directement dans :

OU=Postes,DC=chapal,DC=lan

avant la jointure.

Cette technique est appelée :

prestaging
précréation / préapprovisionnement

Elle peut être intéressante pour :

placer immédiatement le poste dans la bonne OU ;
préparer les délégations ;
appliquer la structure administrative prévue.

Attention aux comptes ordinateurs préexistants

Windows moderne applique des contrôles renforcés lorsqu’une adhésion tente de réutiliser :

un compte ordinateur déjà existant

Le simple fait que :

PC-COMPTA-01

existe dans AD ne signifie pas que n’importe quel compte disposant historiquement de quelques permissions pourra automatiquement le réutiliser.

La propriété de l’objet et les délégations entrent en jeu.

Si la réutilisation échoue

Ne désactivez pas immédiatement les protections de sécurité.

Vérifiez :

qui a créé l’objet ordinateur ;
qui en est propriétaire ;
les permissions déléguées ;
la GPO de réutilisation des comptes ordinateurs si votre architecture l’utilise ;
le journal NetSetup.

Le journal indispensable : NetSetup.log

Windows journalise de nombreux détails du domain join dans :

C:\Windows\Debug\NetSetup.log

Après un échec, consultez ce fichier.

Par exemple :

notepad C:\Windows\Debug\NetSetup.log

ou PowerShell :

Get-Content C:\Windows\Debug\NetSetup.log -Tail 100

Ce journal est souvent infiniment plus utile que :

« J’ai réessayé trois fois et maintenant ça marche encore moins. »

Étape 1 : vérifier la configuration réseau

Commencez par :

ipconfig /all

Contrôlez :

l’adresse IP ;
le masque ;
la passerelle ;
les DNS ;
DHCP ;
le suffixe DNS si pertinent.

Exemple attendu :

IPv4 Address    : 192.168.1.50
Subnet Mask     : 255.255.255.0
Default Gateway : 192.168.1.1
DNS Servers     : 192.168.1.100
                  192.168.1.101

Étape 2 : valider DNS et DC Locator

Resolve-DnsName dc1.chapal.lan

Resolve-DnsName `
    -Type SRV `
    _ldap._tcp.dc._msdcs.chapal.lan

nltest /dsgetdc:chapal.lan /force

Si ces commandes échouent :

ne lancez pas encore la jointure.

Réparez d’abord :

DNS
routage
pare-feu
contrôleur de domaine

Étape 3 : vérifier l’heure

w32tm /query /status

Vérifiez également visuellement :

date ;
heure ;
timezone.

Étape 4 : joindre le domaine avec l’interface moderne

Sous les versions actuelles de Windows :

Settings
→ Accounts
→ Access work or school
→ Connect

Puis recherchez l’action :

Join this device to a local Active Directory domain

Saisissez :

chapal.lan

puis les identifiants autorisés à effectuer l’adhésion.

Méthode classique : sysdm.cpl

L’interface historique reste extrêmement pratique et stable.

Appuyez sur :

Win + R

puis :

sysdm.cpl

Ensuite :

Computer Name
→ Change
→ Member of
→ Domain

Saisissez :

chapal.lan

Identifiants de jointure

Vous pouvez fournir par exemple :

CHAPAL\chapalthebest

si :

le nom NetBIOS est bien CHAPAL ;
ce compte possède les permissions de jointure nécessaires.

Ou son UPN :

chapalthebest@chapal.lan

si c’est bien l’UPN de ce compte.

Le FQDN du domaine ne garantit pas son nom NetBIOS

Un domaine :

chapal.lan

peut très probablement avoir :

CHAPAL

comme nom NetBIOS.

Mais ce n’est pas une obligation mathématique.

Active Directory possède :

nom DNS du domaine
et
nom NetBIOS du domaine

qui sont des informations distinctes.

Le suffixe UPN peut lui aussi différer

De même, un utilisateur peut posséder :

chapalthebest@chapal.lan

mais une entreprise pourrait parfaitement configurer :

chapalthebest@chapal.example.com

comme UPN.

Ne déduisez donc pas automatiquement :

UPN = nom DNS du domaine

sans vérifier.

Si l’adhésion fonctionne

Windows affiche un message ressemblant à :

Bienvenue dans le domaine chapal.lan.

Il faut ensuite :

redémarrer

pour terminer correctement l’intégration.

La jointure avec PowerShell

Dans Windows PowerShell lancé en administrateur :

Add-Computer `
    -DomainName "chapal.lan" `
    -Credential (Get-Credential) `
    -Restart

Une fenêtre demande les identifiants du compte de jointure.

Spécifier directement l’OU

C’est particulièrement utile :

Add-Computer `
    -DomainName "chapal.lan" `
    -OUPath "OU=Postes,DC=chapal,DC=lan" `
    -Credential (Get-Credential) `
    -Restart

Le compte utilisé doit évidemment disposer des droits nécessaires pour créer ou réutiliser l’objet à cet endroit.

Joindre et renommer en une opération PowerShell

Selon le scénario :

Add-Computer `
    -DomainName "chapal.lan" `
    -NewName "PC-COMPTA-01" `
    -Credential (Get-Credential) `
    -Restart

Pour une procédure simple, renommer d’abord puis joindre reste toutefois souvent plus facile à diagnostiquer.

Afficher le résultat sans redémarrer immédiatement

Vous pouvez utiliser :

Add-Computer `
    -DomainName "chapal.lan" `
    -Credential (Get-Credential) `
    -PassThru `
    -Verbose

puis :

Restart-Computer

lorsque vous êtes prêt.

netdom join

L’outil :

netdom

peut également joindre une machine :

netdom join %COMPUTERNAME% ^
    /domain:chapal.lan ^
    /userd:CHAPAL\chapalthebest ^
    /passwordd:*

L’utilisation de :

/passwordd:*

demande le mot de passe sans l’écrire directement dans la ligne de commande.

Netdom n’est pas présent partout par défaut

Sur un poste client Windows, :

netdom.exe

peut nécessiter l’installation des outils Active Directory contenus dans :

RSAT
Remote Server Administration Tools

Si :

'netdom' is not recognized...

cela ne signifie donc pas que votre domaine a disparu.

L’outil peut simplement ne pas être installé.

Pourquoi PowerShell est souvent plus pratique

Pour un poste Windows moderne, :

Add-Computer

possède plusieurs avantages :

gestion propre des credentials ;
OUPath ;
renommage ;
restart ;
verbose ;
automatisation PowerShell.

Après le redémarrage : ouvrir une session domaine

À l’écran de connexion :

Other user
Autre utilisateur

vous pouvez utiliser :

CHAPAL\chapalthebest

si :

CHAPAL

est bien le nom NetBIOS du domaine.

Ou :

chapalthebest@chapal.lan

si cet UPN existe.

Forcer explicitement une connexion locale

Pour utiliser un compte local après l’adhésion :

.\localadmin

ou :

PC-COMPTA-01\localadmin

Le :

.\

signifie ici :

« utilise la machine locale comme autorité de compte ».

Cette notation est extrêmement utile lorsque Windows insiste pour vous proposer le domaine alors que vous devez dépanner localement.

Le premier login crée un nouveau profil

La première connexion de :

CHAPAL\chapalthebest

crée généralement un profil Windows correspondant à cette identité.

Par exemple :

C:\Users\chapalthebest

Mais le nom exact du dossier peut varier, notamment en cas de conflit avec un profil existant.

Joindre le domaine ne migre pas automatiquement l’ancien profil local

Supposons que l’utilisateur travaillait avant avec :

PC-COMPTA-01\chapalthebest

puis se connecte avec :

CHAPAL\chapalthebest

Pour Windows, ce sont deux identités différentes.

Elles possèdent notamment des :

SID différents

L’ancien bureau, les paramètres et certaines données ne sont donc pas automatiquement fusionnés avec le nouveau profil domaine.

Local et domaine peuvent avoir exactement le même nom visible

Vous pouvez avoir :

PC-COMPTA-01\paul

et :

CHAPAL\paul

Il s’agit de deux comptes différents.

Le nom :

paul

est identique.

Le SID et l’autorité de sécurité ne le sont pas.

Vérifier avec whoami

Après connexion :

whoami

devrait par exemple afficher :

chapal\chapalthebest

Afficher l’UPN

whoami /upn

Par exemple :

chapalthebest@chapal.lan

Afficher le nom qualifié

whoami /fqdn

permet d’obtenir la représentation Active Directory qualifiée de l’identité lorsque disponible.

Afficher les groupes du jeton

whoami /groups

Très utile pour vérifier :

Domain Users ;
groupes métier ;
groupes administratifs ;
groupes ajoutés récemment.

Le poste apparaît où dans Active Directory ?

Par défaut, une jointure classique sans OU explicitement spécifiée peut placer le compte ordinateur dans :

CN=Computers,DC=chapal,DC=lan

Le détail important est :

CN=Computers

et non :

OU=Computers

Computers est un conteneur, pas une OU

Dans une installation Active Directory standard :

Computers

est un conteneur système.

Or les GPO peuvent être liées à :

un site ;
un domaine ;
une OU.

Pas directement au conteneur :

CN=Computers

Créez une vraie OU pour les postes

Par exemple :

chapal.lan
└── Postes
    ├── Direction
    ├── Comptabilite
    ├── Informatique
    └── Portables

Le poste :

PC-COMPTA-01

pourrait alors être placé dans :

OU=Comptabilite,
OU=Postes,
DC=chapal,
DC=lan

Pourquoi les OU sont importantes

Elles permettent notamment :

les GPO ;
les délégations administratives ;
une organisation cohérente des objets ;
le ciblage de certaines opérations.

Active Directory Users and Computers devient beaucoup plus agréable lorsque tous les postes de l’entreprise ne vivent pas depuis 2008 dans :

Computers

avec des noms comme :

PC1
PC2
JOHN-PC
DESKTOP-Q42XR9A
OLD-PC-DONTDELETE

Déplacer le poste après l’adhésion

Dans :

dsa.msc

vous pouvez déplacer :

PC-COMPTA-01

vers la bonne OU.

Les GPO liées à cette OU pourront alors s’appliquer selon :

l’héritage ;
la sécurité ;
les filtres ;
le traitement des stratégies.

Rediriger le conteneur par défaut

Un administrateur du domaine peut également définir une OU comme emplacement par défaut pour certaines créations de comptes ordinateurs :

redircmp "OU=Postes,DC=chapal,DC=lan"

Cette opération modifie le comportement par défaut du domaine.

Elle doit donc être réfléchie et documentée.

Vérifications post-adhésion

Après le redémarrage et une connexion domaine réussie :

whoami

puis :

systeminfo | findstr /B /C:"Domain"

peuvent fournir des informations utiles.

PowerShell :

Get-CimInstance Win32_ComputerSystem |
    Select-Object Name, Domain, PartOfDomain

Exemple :

Name         Domain      PartOfDomain
----         ------      ------------
PC-COMPTA-01 chapal.lan  True

Découvrir le DC utilisé

echo %LOGONSERVER%

peut par exemple afficher :

\\DC1

Mais cette variable concerne le contexte de connexion utilisateur.

Pour interroger directement DC Locator :

nltest /dsgetdc:chapal.lan

Afficher le site Active Directory

nltest /dsgetsite

Par exemple :

Bruxelles

Le site détecté dépend normalement du sous-réseau IP associé dans :

Active Directory Sites and Services

Pourquoi les Sites Active Directory comptent

Dans une infrastructure multi-sites :

Paris
Bruxelles
Lyon

on préfère généralement que :

PC Bruxelles
→ DC Bruxelles

plutôt que :

PC Bruxelles
→ VPN
→ DC Paris

sans raison particulière.

DC Locator utilise notamment les informations de sites pour privilégier des contrôleurs adaptés.

Tester le secure channel

Après l’adhésion :

Test-ComputerSecureChannel

Un résultat sain :

True

Avec détails :

Test-ComputerSecureChannel -Verbose

Réparer un secure channel

Pour un poste membre, si le diagnostic confirme un problème :

Test-ComputerSecureChannel `
    -Repair `
    -Credential (Get-Credential)

puis testez à nouveau :

Test-ComputerSecureChannel -Verbose

Cette réparation est souvent préférable au réflexe :

sortir du domaine
redémarrer
rejoindre
redémarrer
prier

qui crée davantage de changements que nécessaire.

nltest et secure channel

On peut aussi rencontrer :

nltest /sc_verify:chapal.lan

pour vérifier le canal sécurisé avec le domaine.

Tester les GPO

Pour mettre à jour les stratégies :

gpupdate

ou si un diagnostic le justifie :

gpupdate /force

Mais :

/force

ne signifie pas :

« Répare toutes les GPO qui ont été mal conçues. »

Il demande principalement une réapplication plus complète des stratégies.

Afficher les stratégies reçues

gpresult /r

Pour un rapport HTML :

gpresult /h C:\Temp\gpresult.html

Le rapport permet d’examiner notamment :

les GPO appliquées ;
les GPO refusées ;
le contexte utilisateur ;
le contexte ordinateur.

Le profil réseau DomainAuthenticated

Après une connexion correcte au domaine et la détection du contrôleur approprié, Windows peut identifier le réseau comme :

DomainAuthenticated

Vérifiez avec :

Get-NetConnectionProfile

Exemple :

Name             : chapal.lan
InterfaceAlias   : Ethernet
NetworkCategory  : DomainAuthenticated

Si un poste membre reste constamment en :

Public

ou :

Private

alors qu’il devrait détecter le domaine, examinez notamment :

DNS ;
DC Locator ;
LDAP ;
connectivité vers le domaine.

Ne forcez pas artificiellement le profil « Domain » par une astuce de registre trouvée sur Internet.

Le profil de domaine doit être détecté par Windows grâce à l’authentification réseau appropriée.

Accès aux ressources du domaine

Une fois membre, le poste peut accéder selon les permissions à :

\\serveur\partage

Par exemple :

\\srv-files\Projets

Il peut également recevoir :

imprimantes ;
scripts ;
certificats ;
paramètres de sécurité ;
mappages de lecteurs ;
logiciels ;
configurations Windows ;

par l’intermédiaire notamment des GPO et d’autres systèmes de gestion.

Joindre un domaine ne donne pas automatiquement accès à tout

L’appartenance à :

chapal.lan

ne signifie pas :

« Tous les fichiers, serveurs et imprimantes sont maintenant ouverts. »

L’autorisation dépend toujours :

des groupes ;
des ACL NTFS ;
des permissions SMB ;
des GPO ;
des règles applicatives.

Le domaine ne rend pas automatiquement l’utilisateur administrateur local

Un utilisateur comme :

CHAPAL\chapalthebest

peut être un utilisateur standard du poste.

Et c’est généralement très bien ainsi.

Si certains comptes doivent administrer les postes, gérez cela explicitement via :

groupes ;
GPO ;
politiques de gestion des administrateurs locaux.

Ajouter tous les utilisateurs à :

Administrators

pour éviter des tickets au support réduit effectivement certains tickets.

Il en crée simplement de plus intéressants plus tard.

Erreur : « Le domaine spécifié n’existe pas ou n’a pas pu être contacté »

C’est l’un des grands classiques.

Commencez par :

ipconfig /all

Puis :

Resolve-DnsName `
    -Type SRV `
    _ldap._tcp.dc._msdcs.chapal.lan

Puis :

nltest /dsgetdc:chapal.lan /force

Si ces opérations échouent, examinez :

DNS ;
VLAN ;
VPN ;
pare-feu ;
DC ;
zone DNS Active Directory.

Le piège : Internet fonctionne, donc DNS fonctionne

Un poste peut parfaitement résoudre :

google.com

avec :

1.1.1.1

tout en étant absolument incapable de résoudre :

_ldap._tcp.dc._msdcs.chapal.lan

Internet fonctionnel ne signifie donc pas :

DNS Active Directory fonctionnel

Erreur : « Access denied »

Vérifiez :

le nom du compte ;
son mot de passe ;
ses droits de création du compte ordinateur ;
les délégations sur l’OU ;
l’existence préalable éventuelle de l’objet ordinateur ;
les règles modernes de réutilisation de comptes ordinateurs.

Un Domain Admin ne devrait pas être votre solution universelle

Tester une fois avec un compte privilégié peut éventuellement aider à isoler un problème de délégation.

Mais la solution finale ne devrait pas devenir :

donner Domain Admin à la personne qui installe les PC

uniquement parce que :

« Avec ça, ça marche. »

Le moindre privilège s’applique aussi lorsque Windows affiche une boîte de dialogue de credentials.

Erreur de réutilisation du compte ordinateur

Vous pouvez rencontrer un scénario :

PC-COMPTA-01 existe déjà dans AD
+
nouvelle installation de Windows
+
tentative de jointure
+
refus

Les versions modernes de Windows renforcent volontairement la réutilisation des objets ordinateurs existants.

Consultez :

C:\Windows\Debug\NetSetup.log

avant de décider que :

Active Directory est cassé

Ne supprimez pas automatiquement l’objet existant

Un ancien objet ordinateur peut posséder :

des délégations ;
des groupes ;
des certificats ou associations ;
des dépendances de gestion ;
un historique utile.

Déterminez d’abord pourquoi il existe et pourquoi sa réutilisation échoue.

Erreur de temps / Kerberos

Vérifiez :

w32tm /query /status
w32tm /query /source

et éventuellement :

w32tm /resync

Une horloge incorrecte peut provoquer des erreurs d’authentification qui ressemblent à un problème de mot de passe.

Kerberos considère le temps comme un élément de sécurité.

Il n’accepte pas :

« On est mardi à peu près. »

Erreur : la relation d’approbation entre cette station et le domaine a échoué

Commencez par vous connecter avec :

un compte local administrateur ;
ou un compte domaine utilisant encore des credentials en cache si cela fonctionne.

Puis :

Test-ComputerSecureChannel -Verbose

Si le résultat est :

False

et que DNS/DC sont sains :

Test-ComputerSecureChannel `
    -Repair `
    -Credential (Get-Credential)

peut réparer le canal sur un poste membre.

Pourquoi un secure channel peut casser

Parmi les causes possibles :

restauration d’une vieille image ;
clone mal préparé ;
compte ordinateur réinitialisé ;
réinstallation avec ancien objet ;
désynchronisation du mot de passe machine ;
opérations AD incorrectes.

Un snapshot de VM ancien peut créer ce genre de surprise

Vous restaurez :

VM d'il y a trois mois

mais Active Directory connaît :

l'état actuel

Le poste restauré peut alors revenir avec des informations d’authentification qui ne correspondent plus à ce qu’attend le domaine.

Les snapshots sont utiles.

Le temps, malheureusement, continue malgré eux.

Les GPO ne s’appliquent pas

Commencez par :

gpresult /r

puis :

gpresult /h C:\Temp\gpo.html

Vérifiez :

OU du poste ;
liens GPO ;
Security Filtering ;
WMI Filter éventuel ;
héritage ;
DNS ;
accès SYSVOL ;
DC utilisé.

Un poste resté dans Computers peut surprendre

Si vous avez lié :

GPO-Postes-Compta

à :

OU=Comptabilite

mais que :

PC-COMPTA-01

se trouve toujours dans :

CN=Computers

la GPO liée à l’OU Comptabilite ne va pas se téléporter jusqu’à lui par sympathie.

Tester SYSVOL

Après jointure :

dir \\chapal.lan\SYSVOL

et :

dir \\chapal.lan\NETLOGON

peuvent aider à contrôler l’accès aux ressources essentielles distribuées par les DC.

Le premier login à distance : attention

Pour créer le profil et mettre en cache correctement les credentials d’un nouvel utilisateur domaine, le poste doit généralement pouvoir joindre un contrôleur de domaine lors de la première authentification.

Un portable fraîchement joint au bureau puis envoyé immédiatement chez l’utilisateur sans mécanisme VPN adapté peut donc présenter un problème :

Utilisateur domaine
jamais connecté auparavant
+
aucun accès au DC
=
connexion impossible

Cas des utilisateurs distants

Prévoyez selon votre architecture :

VPN avant ouverture de session ;
Always On VPN ;
connexion initiale sur site ;
autre mécanisme de gestion approprié.

Une fois que l’utilisateur s’est connecté correctement et que ses credentials sont mis en cache, certaines connexions hors ligne peuvent fonctionner.

Mais les ressources réseau et nouvelles informations d’authentification restent dépendantes de la connectivité au domaine.

DNS via VPN

Le VPN doit permettre :

d’atteindre les DC ;
d’utiliser la résolution DNS Active Directory appropriée ;
de transporter les protocoles nécessaires.

Un VPN qui fournit :

route vers 192.168.1.0/24

mais laisse le client utiliser uniquement :

8.8.8.8

peut donner un résultat fascinant :

les serveurs existent
mais personne ne sait comment les trouver

Quitter le domaine

Avant de sortir une machine du domaine :

assurez-vous de disposer d’un administrateur local fonctionnel.

Après la sortie, un compte uniquement domaine :

CHAPAL\chapalthebest

ne constitue plus une identité locale de la machine.

Quitter via l’interface graphique

Dans :

sysdm.cpl
→ Computer Name
→ Change

sélectionnez :

Workgroup

et indiquez par exemple :

WORKGROUP

Fournissez les credentials nécessaires à la sortie si demandés.

Puis redémarrez.

Quitter avec PowerShell

Remove-Computer `
    -UnjoinDomainCredential (Get-Credential) `
    -WorkgroupName "WORKGROUP" `
    -Restart

Avant cette opération :

testez réellement :

.\localadmin

et pas seulement votre mémoire du mot de passe datant de l’installation.

Netdom remove

Lorsque Netdom est disponible :

netdom remove %COMPUTERNAME% ^
    /domain:chapal.lan ^
    /userd:CHAPAL\administrateur ^
    /passwordd:*

puis redémarrez.

Ne mettez jamais un mot de passe directement dans un script de jointure

Évitez :

/passwordd:MonSuperMotDePasse

ou :

$Password = "MonSuperMotDePasse"

dans un fichier `.ps1` partagé.

Préférez :

/passwordd:*

ou :

Get-Credential

ou un mécanisme de déploiement sécurisé adapté à l’entreprise.

Le fichier NetSetup.log : premier réflexe en cas d’échec sérieux

Rappel :

C:\Windows\Debug\NetSetup.log

Examinez les dernières lignes :

Get-Content `
    C:\Windows\Debug\NetSetup.log `
    -Tail 200

On peut y trouver des indications sur :

DC choisi ;
résolution DNS ;
création du compte ordinateur ;
réutilisation d’un objet ;
erreurs réseau ;
codes Windows.

Diagnostic méthodique d’une jointure impossible

Utilisez cet ordre :

1. Édition Windows
2. Adresse IP
3. DNS
4. SRV Active Directory
5. DC Locator
6. Heure
7. Ports / firewall
8. Compte de jointure
9. Objet ordinateur existant
10. NetSetup.log

Cette méthode est légèrement plus efficace que :

changer le DNS
redémarrer
désactiver le firewall
redémarrer
réinitialiser Winsock
redémarrer
supprimer le PC dans AD
redémarrer
accuser Microsoft

Checklist avant l’adhésion

Vérifier que Windows est une édition compatible.
S’assurer que Windows est encore supporté et à jour.
Conserver un compte administrateur local fonctionnel.
Définir un nom de machine cohérent.
Vérifier l’adresse IP et la passerelle.
Configurer uniquement les DNS internes capables de résoudre Active Directory.
Tester le FQDN d’un DC.
Tester les SRV _ldap._tcp.dc._msdcs.
Tester nltest /dsgetdc.
Vérifier l’heure.
Vérifier les permissions du compte de jointure.
Vérifier si un compte ordinateur existe déjà.
Décider dans quelle OU le poste doit finir.

Checklist immédiatement après l’adhésion

Redémarrer.
Se connecter avec un utilisateur domaine.
Vérifier whoami.
Vérifier le domaine avec PowerShell.
Vérifier le secure channel.
Vérifier l’OU de l’objet ordinateur.
Vérifier les GPO.
Tester SYSVOL et NETLOGON.
Tester les ressources réseau.
Conserver ou gérer correctement l’accès administrateur local.

Commandes essentielles

Commande	Utilité
`ipconfig /all`	Afficher IP, passerelle et DNS
`Resolve-DnsName dc1.chapal.lan`	Résoudre le DC
`Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.chapal.lan`	Découvrir les SRV Active Directory
`nltest /dsgetdc:chapal.lan /force`	Tester DC Locator
`nltest /dsgetsite`	Afficher le site AD détecté
`w32tm /query /status`	Examiner Windows Time
`whoami`	Afficher l’identité actuelle
`whoami /upn`	Afficher l’UPN
`whoami /groups`	Afficher les groupes du jeton
`gpresult /r`	Afficher les GPO appliquées
`gpresult /h fichier.html`	Créer un rapport GPO détaillé
`Test-ComputerSecureChannel`	Tester le canal sécurisé
`Get-NetConnectionProfile`	Examiner le profil réseau
`sysdm.cpl`	Interface classique de jointure

Procédure minimale propre

Si vous connaissez déjà Active Directory et voulez simplement la séquence :

ipconfig /all

Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.chapal.lan

nltest /dsgetdc:chapal.lan /force

w32tm /query /status

Puis, en PowerShell administrateur :

Add-Computer `
    -DomainName "chapal.lan" `
    -OUPath "OU=Postes,DC=chapal,DC=lan" `
    -Credential (Get-Credential) `
    -Restart

Après redémarrage :

whoami

Test-ComputerSecureChannel -Verbose

gpresult /r

Procédure GUI minimale

1. Configurer les DNS internes
2. Tester nltest /dsgetdc:chapal.lan
3. Exécuter sysdm.cpl
4. Computer Name → Change
5. Domain → chapal.lan
6. Fournir le compte de jointure
7. Redémarrer
8. Se connecter avec CHAPAL\utilisateur ou son UPN
9. Vérifier l'OU et les GPO

Cas pratique complet

Nous avons :

Poste :
PC-COMPTA-01

Adresse :
192.168.1.50/24

Passerelle :
192.168.1.1

DNS :
192.168.1.100
192.168.1.101

Domaine :
chapal.lan

DC :
dc1.chapal.lan

1. Contrôle IP

ipconfig /all

2. Contrôle DNS

Resolve-DnsName dc1.chapal.lan

Resolve-DnsName `
    -Type SRV `
    _ldap._tcp.dc._msdcs.chapal.lan

3. Contrôle DC Locator

nltest /dsgetdc:chapal.lan /force

4. Contrôle temporel

w32tm /query /status

5. Jointure

Add-Computer `
    -DomainName "chapal.lan" `
    -OUPath "OU=Comptabilite,OU=Postes,DC=chapal,DC=lan" `
    -Credential (Get-Credential "CHAPAL\chapalthebest") `
    -Restart

Cette commande suppose que :

CHAPAL\chapalthebest

possède réellement les permissions de jointure nécessaires.

6. Première connexion

CHAPAL\chapalthebest

ou :

chapalthebest@chapal.lan

si ces deux représentations correspondent bien au compte réel.

7. Contrôle

whoami

Test-ComputerSecureChannel -Verbose

gpresult /r

Le cas de chapal.lan

Notre domaine :

chapal.lan

est parfaitement utilisable comme exemple ou dans une infrastructure existante correctement maîtrisée.

Mais pour concevoir un nouveau domaine Active Directory de production, il est aujourd’hui préférable d’utiliser un namespace basé sur un domaine DNS réellement contrôlé par l’organisation.

Par exemple, si l’entreprise possède :

chapal.example

elle pourrait utiliser :

ad.chapal.example

ou :

corp.chapal.example

selon sa stratégie.

Pourquoi éviter les suffixes inventés dans un nouveau projet ?

Utiliser un namespace enregistré ou un sous-domaine contrôlé réduit les risques de :

collision de noms ;
fusion future avec une autre organisation ;
problèmes avec certaines applications ;
complexité DNS.

Mais ne renommez pas un domaine Active Directory existant :

chapal.lan

simplement parce que vous venez de lire ce paragraphe.

Un renommage de domaine est un projet d’infrastructure.

Pas une correction orthographique.

Les erreurs conceptuelles les plus fréquentes

« Il faut joindre le PDC »

Non.

Le client utilise DC Locator pour découvrir un DC approprié.

Le PDC Emulator est un rôle FSMO, pas l’unique porte d’entrée du domaine.

« Le DNS doit être l’IP du DC »

Souvent, oui, parce que le DC héberge également DNS.

Mais la vraie exigence est :

DNS capable de résoudre correctement Active Directory

« Je mets Google DNS en secondaire au cas où »

Non.

Utilisez plusieurs DNS internes AD.

Les DNS internes résolvent ensuite Internet via leurs forwarders.

« Ping fonctionne donc AD fonctionne »

Non.

Testez :

SRV
DC Locator
LDAP
Kerberos
RPC
SMB

selon le problème.

« Ping échoue donc le DC est mort »

Pas forcément.

ICMP peut être filtré.

« Computers est une OU »

Non.

Par défaut :

CN=Computers

est un conteneur.

« Je peux lier une GPO à Computers »

Pas directement au conteneur CN standard.

Créez des OU adaptées.

« L’utilisateur final doit être celui qui joint le poste »

Non.

Le compte de jointure et le compte utilisateur quotidien peuvent être distincts.

« Il faut utiliser Domain Admin »

Non.

Utilisez des permissions déléguées adaptées.

« Le nom NetBIOS est forcément CHAPAL »

Probable pour :

chapal.lan

mais pas garanti.

Vérifiez le domaine.

« Le UPN est forcément @chapal.lan »

Pas nécessairement.

Des suffixes UPN alternatifs peuvent être configurés.

« Joindre le domaine migre mon profil local »

Non.

Compte local et compte domaine ont des SID différents.

« La jointure a réussi donc les GPO sont forcément bonnes »

Non.

La jointure prouve que la jointure a réussi.

Les GPO possèdent leur propre carrière.

« Si la trust relationship casse, il faut toujours sortir/rejoindre »

Non.

Testez et réparez d’abord le secure channel lorsque c’est approprié.

« Windows 10 Pro est toujours normalement supporté »

Plus en 2026 pour Windows 10 22H2 standard.

Prévoyez Windows 11 ou une stratégie de support particulière.

Une méthode professionnelle de déploiement

Pour quelques postes :

GUI
ou
Add-Computer

peut suffire.

Pour plusieurs centaines :

il faut plutôt penser :

convention de nommage ;
OU ;
délégation ;
DHCP ;
DNS ;
GPO ;
déploiement automatisé ;
gestion des administrateurs locaux ;
BitLocker ;
inventaire ;
Intune ou autre plateforme selon architecture ;
éventuellement hybrid join / Entra selon stratégie.

L’adhésion au domaine n’est que le début

Après :

Bienvenue dans le domaine chapal.lan

commence réellement le travail :

OU correcte
↓
GPO
↓
groupes
↓
permissions
↓
applications
↓
sécurité
↓
supervision

Un domaine n’est pas intéressant uniquement parce que les utilisateurs peuvent écrire :

CHAPAL\alice

sur l’écran de connexion.

Son intérêt réside dans la gestion centralisée qui suit.

Résumé de diagnostic

Symptôme	Premier suspect
Domaine introuvable	DNS / DC Locator
DC résolu mais jointure impossible	Pare-feu / RPC / permissions
Access denied	Compte de jointure / délégation
Compte ordinateur existe déjà	Réutilisation / ownership / hardening
Authentification Kerberos étrange	DNS / heure / SPN selon contexte
Trust relationship failed	Secure channel
GPO absente	OU / filtrage / DNS / SYSVOL
Profil réseau non DomainAuthenticated	Détection DC / LDAP / DNS
Utilisateur distant jamais connecté	Accès au DC avant première ouverture de session

Les commandes à retenir

ipconfig /all

Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.chapal.lan

nltest /dsgetdc:chapal.lan /force

w32tm /query /status

sysdm.cpl

whoami
whoami /upn
whoami /groups

Test-ComputerSecureChannel -Verbose

gpresult /r

Get-NetConnectionProfile

Conclusion : pas de DNS, pas de royaume

Joindre un PC Windows au domaine :

chapal.lan

ne consiste pas simplement à renseigner un nom dans une fenêtre.

Le processus repose sur :

DNS
↓
DC Locator
↓
contrôleur de domaine
↓
compte ordinateur
↓
secure channel
↓
authentification
↓
GPO
↓
ressources du domaine

Retenez surtout :

Windows Home ne rejoint pas un domaine AD classique ;
Windows 10 22H2 standard est désormais hors support ;
un membre du domaine doit utiliser des DNS internes capables de résoudre Active Directory ;
les DNS publics ne doivent pas servir de secours direct aux DNS AD du poste ;
les enregistrements SRV sont plus importants qu’un simple ping ;
DC Locator choisit un contrôleur approprié : le PDC Emulator n’est pas l’unique DC à contacter ;
l’heure doit être correctement synchronisée pour Kerberos ;
le compte de jointure n’a pas besoin d’être l’utilisateur final ni Domain Admin ;
les permissions de jointure doivent être déléguées proprement ;
les comptes ordinateurs existants sont soumis aux protections modernes de réutilisation ;
CN=Computers n’est pas une OU ;
joindre un domaine ne migre pas automatiquement un profil local ;
Test-ComputerSecureChannel permet de diagnostiquer la relation de confiance ;
et NetSetup.log est l’un des premiers endroits à consulter lorsque la jointure échoue.

Le principe fondamental reste néanmoins délicieusement simple :

pas de DNS Active Directory correct, pas de domaine fonctionnel.

Vous pouvez disposer :

d'un DC magnifique
de vingt GPO
de Kerberos
de DFS
d'un administrateur certifié
et d'un logo Active Directory encadré au mur

si le poste demande :

_ldap._tcp.dc._msdcs.chapal.lan

à un DNS public qui lui répond :

je n'ai aucune idée de ce dont vous parlez

la jointure s’arrêtera là.

Et, pour une fois, Windows aura une excellente excuse.

Post Views: 9