Oleks IT Blog

Dans les tutoriels précédents, on a posé toutes les briques de base : Installation de Windows Server 2025 et Windows 11 sur Proxmox, puis configuration complète du serveur comme contrôleur de domaine Active Directory, avec DNS et DHCP.
Bref, toute l’infrastructure est prête.
Dans ce tutoriel, on arrive à la dernière étape logique — et souvent la plus satisfaisante : joindre un poste Windows 11 au domaine et vérifier que tout fonctionne comme prévu.

Avant d’aller plus loin, assure-toi que les étapes précédentes sont bien terminées :

• le contrôleur de domaine Windows Server 2025 est opérationnel ;
• DNS et DHCP fonctionnent correctement ;
• un utilisateur de domaine existe déjà ;
• et surtout, Windows 11 est connecté au même réseau que le contrôleur de domaine.

Sous Proxmox, cette étape est très simple. On peut vérifier sur quel réseau est connectée la carte réseau de la VM Windows 11 et, au besoin, éteindre la machine pour la rattacher au bon bridge interne — dans mon cas vmbr1, le même que celui du contrôleur de domaine — puis redémarrer la VM.

Une fois démarré sur le bon réseau, Windows 11 reçoit automatiquement une adresse IP fournie par le serveur DHCP du domaine.

À partir de là, tout est en place pour passer à l’intégration du poste client. C’est à ce moment précis qu’Active Directory prend tout son sens : authentification centralisée, gestion des utilisateurs et base solide pour la suite (GPO, sécurité, automatisation, etc.).

Étape 1 — Vérifier que Windows 11 reçoit bien une IP (DHCP)

Avant même de penser « domaine », on veut une base réseau clean. Si Windows 11 ne reçoit pas une IP via DHCP, la jointure va juste tourner en rond.
Sur Windows 11, ouvre un terminal PowerShell (pas besoin admin), puis lance :

ipconfig /all

Ici, l’objectif est simple : confirmer que Windows 11 a bien reçu une config réseau du DHCP du Windows Server 2025. Comme j’ai démarré mon scope à .100, je dois retrouver quelque chose du genre :

IPv4 : 10.10.0.100
Masque : /24 (255.255.255.0)
Gateway : 10.10.0.1
DNS : 10.10.0.10
Suffixe DNS : lab.local

Si on voit ça, cela signifie que Windows 11 a bien reçu une configuration réseau du serveur DHCP. Le poste client est dans le bon réseau, utilise le bon DNS et peut poursuivre la suite de la configuration.

Si on voit une IP en 169.254.x.x (APIPA)
Ça signifie que Windows s’est auto-attribué une adresse IP parce que le serveur DHCP n’a pas répondu, soit parce que le service DHCP côté serveur ne fonctionne pas, soit parce que la machine Windows est connectée à un autre réseau (mauvais bridge Proxmox).

On peut déjà forcer un renouvellement :

ipconfig /release
ipconfig /renew

Mini-check Internet

Tant qu’on est là, on valide aussi que le NAT Proxmox fait bien son job et que le client sort sur Internet :

ping google.com

Si ça répond, réseau + NAT OK. Si ça ne répond pas, on règle ça maintenant, sinon tout le reste sera bancal.

Étape 2 — Tester le réseau et le DNS avant la jointure

À ce stade, il est indispensable de valider les autres éléments de la configuration réseau. Ces vérifications sont critiques : une erreur à ce niveau peut empêcher la jointure au domaine, mais aussi provoquer des problèmes plus subtils par la suite (authentification lente, erreurs DNS, GPO qui ne s’appliquent pas).
Sur Windows 11, ouvrir PowerShell en tant qu’administrateur, puis effectuer les tests suivants.

Tester la passerelle NAT (Proxmox)

ping 10.10.0.1

Ce test confirme que le poste client peut joindre la passerelle NAT fournie par Proxmox et que la connectivité réseau de base est fonctionnelle.

Tester le serveur AD / DNS

ping 10.10.0.10

Une réponse valide indique que le client peut communiquer avec le contrôleur de domaine et le serveur DNS.

Tester la résolution DNS du domaine

nslookup lab.local 10.10.0.10
nslookup srv-dc1.lab.local 10.10.0.10

Ces commandes permettent de vérifier que :

• la zone DNS du domaine est correctement résolue ;
• le nom du contrôleur de domaine correspond bien à la configuration réelle.

En cas d’échec de nslookup

Si l’une de ces commandes échoue, les causes les plus fréquentes sont :

• le serveur DNS configuré sur Windows 11 n’est pas 10.10.0.10 ;
• le nom de domaine ou le nom du contrôleur de domaine ne correspond pas à celui configuré côté Active Directory.

Dans ce cas, il est nécessaire de corriger la configuration DNS avant de poursuivre, car une jointure au domaine sans résolution DNS fonctionnelle est vouée à l’échec.

 

Étape 3 — Renommer le poste Windows 11

Cette étape n’est pas strictement obligatoire, mais elle est fortement recommandée. Dans un parc informatique, un nom de machine clair facilite énormément l’identification des postes, la gestion quotidienne, le dépannage et l’application des stratégies (GPO).
Sur Windows 11, ouvrir les Settings, puis se rendre dans System → About.
Cliquer sur Rename this PC et définir un nom explicite. Par exemple :

W11-01

Une fois le nouveau nom appliqué, redémarrer le poste afin que le changement soit pris en compte par le système.
Après le redémarrage, le poste est prêt pour la jointure au domaine avec une identité claire et cohérente.

 

Étape 4 — Joindre le poste Windows 11 au domaine

Une fois la configuration réseau validée et le poste correctement nommé, on peut passer à l’étape clé : la jointure au domaine Active Directory.
Sur Windows 11, ouvrir les Settings, puis aller dans System → About.
Dans la section Related settings, cliquer sur Domain or workgroup (ou Advanced system settings, selon la version).
Dans l’onglet Computer Name, cliquer sur Change…, puis sélectionner Domain et saisir le nom du domaine :

lab.local

 

Lorsque Windows le demande, entrer les identifiants d’un compte autorisé à joindre des machines au domaine, par exemple :

LAB\Administrator

(ou tout autre compte membre des Domain Admins).
Après validation, un message de bienvenue confirme que le poste a bien été ajouté au domaine lab.local.
À ce stade, il est important de noter que cela ne correspond pas encore à une connexion avec un compte de domaine : cette étape sert uniquement à rattacher la machine à Active Directory.
Il faut alors redémarrer le poste pour finaliser l’opération.
Ce n’est qu’après ce redémarrage que Windows 11 devient réellement membre du domaine et qu’il sera possible de se connecter avec un utilisateur Active Directory.

Option B (PowerShell)

Il est également possible de joindre le poste au domaine directement via PowerShell, ce qui peut être plus rapide et plus pratique dans un contexte de lab ou d’automatisation.
Ouvrir PowerShell en tant qu’administrateur, puis exécuter la commande suivante :

Add-Computer -DomainName "lab.local" -Credential "LAB\Administrator" -Restart

Une fenêtre d’authentification s’ouvre alors pour saisir le mot de passe du compte domaine.
Après validation, le poste est automatiquement joint au domaine et redémarre pour appliquer les changements.

Étape 5 — Première connexion dans le domaine

Après le redémarrage du poste, Windows 11 est maintenant membre du domaine lab.local.
Pour la toute première connexion avec un compte Active Directory, il faut changer légèrement la manière de se connecter.
Sur l’écran de login de Windows 11, sélectionner Other user.
Cela permet de saisir manuellement les identifiants d’un compte de domaine, plutôt que d’utiliser un compte local déjà présent sur la machine.
Deux formats sont possibles pour la connexion :

• LAB\oleks
• [email protected]

Les deux sont équivalents : le premier utilise le nom NetBIOS du domaine, le second le nom DNS complet.
Dans un environnement professionnel, les deux formats sont couramment utilisés.
Entrer ensuite le mot de passe du compte Active Directory, puis valider.
Lors de cette première connexion, Windows peut prendre un peu plus de temps que d’habitude : le profil utilisateur de domaine est en cours de création sur la machine (dossier utilisateur, paramètres initiaux, stratégies éventuelles).

Une fois la session ouverte, la connexion au domaine est confirmée :
le poste Windows 11 est bien intégré à Active Directory et l’utilisateur s’authentifie désormais via le contrôleur de domaine.

À partir de là, le client est pleinement opérationnel dans le domaine :

GPO, comptes centralisés, authentification et administration peuvent maintenant être exploités comme dans une vraie infrastructure d’entreprise.

 

Étape 6 — Vérifications après la jointure au domaine

Une fois la première connexion réussie avec un compte Active Directory, il est important de faire quelques vérifications simples pour confirmer que le poste Windows 11 est correctement intégré au domaine et qu’il communique bien avec le contrôleur de domaine.

On commence par ouvrir PowerShell (une session utilisateur suffit).

Vérifier l’identité de l’utilisateur connecté

La commande suivante permet de confirmer que la session est bien ouverte avec un compte de domaine, et non un compte local :

whoami

Le résultat doit afficher quelque chose comme :

lab\oleks

Cela confirme que l’authentification s’est faite via Active Directory.

Vérifier l’appartenance au domaine

Ensuite, on vérifie que la machine elle-même est bien membre du domaine :

systeminfo | findstr /B /C:"Domain"

La sortie doit indiquer lab.local.
Si c’est le cas, la jointure au domaine est effective au niveau système.

Vérifier que le DNS du domaine est bien utilisé

Le bon fonctionnement d’Active Directory repose entièrement sur le DNS.
On s’assure donc que le poste utilise bien le serveur DNS du domaine :

Dans les informations réseau, on doit retrouver :

Serveur DNS : 10.10.0.10

Suffixe DNS : lab.local

Cela garantit que toutes les résolutions de noms AD passent par le contrôleur de domaine.

Vérifier la communication avec le contrôleur de domaine

Enfin, on demande explicitement à Windows de localiser un contrôleur de domaine pour le domaine lab.local :

nltest /dsgetdc:lab.local

Si la commande retourne SRV-DC1.lab.local avec l’adresse 10.10.0.10 et se termine par
The command completed successfully, alors tout est parfaitement aligné.
À ce stade, la jointure est totalement fonctionnelle :
le poste est membre du domaine, l’utilisateur est authentifié via Active Directory, et la communication avec le contrôleur de domaine est opérationnelle.

Problèmes courants et points de dépannage

Si la jointure échoue avec le message « DNS name does not exist », c’est presque toujours un problème de DNS : le client n’utilise pas 10.10.0.10 comme serveur DNS. Dans un lab AD, si le DNS n’est pas le DC, la jointure casse immédiatement.
Si Windows 11 est branché sur vmbr0 au lieu de vmbr1, tu te retrouves dans un autre réseau. Résultat : la machine ne voit tout simplement pas 10.10.0.10, donc elle ne peut ni résoudre lab.local, ni trouver le contrôleur de domaine.
Si le Windows Firewall est activé côté serveur, vérifie que les règles des rôles AD DS / DNS / DHCP ont bien été ouvertes automatiquement. En général c’est le cas, mais si tu as appliqué des règles “hardening” ou des GPO trop strictes, ça peut bloquer les échanges (DNS, Kerberos, RPC) et provoquer des erreurs bizarres au moment de joindre ou de se loguer.

Et voilà 🙂 Windows 11 est maintenant correctement joint au domaine Active Directory. Nous avons également passé en revue les problèmes les plus courants et les vérifications essentielles pour les résoudre rapidement.

Bonne chance !