Dans le tutoriel précédent, on a déjà vu comment installer Windows Server 2025 sur Proxmox ou sur VMware Workstation et préparer une VM propre. Dans cet article, on continue logiquement : on va transformer ce serveur en contrôleur de domaine complet, avec DNS et DHCP. Et dans le prochain tutoriel, on fera la dernière étape logique : joindre un client Windows 11 au domaine et valider que toute l’infrastructure fonctionne correctement.
J’avais déjà fait, il y a quelque temps, une série de tutoriels où je configurais Windows Server 2019 comme contrôleur de domaine, mais dans ce scénario le serveur jouait aussi le rôle de routeur. Il avait deux cartes réseau (LAN et WAN) et tout le trafic passait par lui. C’est une approche intéressante pour un lab et pour certains cas bien précis, et on la voit encore parfois en production. Mais dans la majorité des environnements d’entreprise, le routage est séparé : on a un routeur ou un firewall dédié — pfSense pour des petites structures, ou des solutions plus avancées pour les infrastructures plus grosses, souvent avec de la redondance.
C’est pour ça que dans ce tutoriel, on va utiliser une approche plus proche de la réalité terrain. Proxmox fournit déjà un réseau interne avec NAT, qui donne accès à Internet, mais sans DHCP. Le Windows Server 2025 sera connecté à ce réseau, configuré avec une IP statique, puis on installera dessus DNS, DHCP et Active Directory Domain Services. À partir de là, le serveur prendra en charge la distribution des adresses IP et deviendra le point central pour l’authentification du domaine.
La logique globale reste très similaire à celle de Windows Server 2019, mais il y a plusieurs différences importantes : les prérequis ont évolué, certains comportements ont changé, et surtout, je vais volontairement privilégier PowerShell autant que possible, au lieu de tout faire via le GUI. En pratique, c’est plus rapide, plus clair, et beaucoup plus proche de ce qu’on fait en production ou en automatisation.
Concrètement, on va déployer Windows Server 2025 dans le réseau interne vmbr1 (10.10.0.0/24) avec NAT via Proxmox, configurer une adresse statique 10.10.0.10/24 avec comme gateway 10.10.0.1, installer les rôles AD DS, DNS et DHCP, puis créer un scope DHCP pour que les clients — par exemple un Windows 11 — reçoivent automatiquement une IP, le bon DNS, et puissent joindre le domaine sans problème.
Côté réseau, le contexte est important : vmbr1 est un bridge interne avec NAT vers vmbr0, exactement comme dans mon guide sur le réseau interne NAT dans Proxmox. Proxmox s’occupe du routage et du NAT, mais ne distribue aucune adresse IP. Cette responsabilité est volontairement laissée à Windows Server. J’utilise aussi le réseau 10.10.0.0/24 pour éviter tout conflit avec le réseau domestique ou professionnel auquel le host Proxmox est connecté — c’est un détail, mais ça évite beaucoup de problèmes.
Bref, on est sur un scénario simple, propre et très réaliste, parfait pour un lab, mais aussi directement transposable dans une vraie infrastructure.
Étape 1 — Donner une identité réseau claire au serveur
Avant d’aller plus loin, on commence par une étape essentielle : attribuer une adresse IP statique à notre Windows Server 2025. Dans un environnement Active Directory, le contrôleur de domaine doit toujours être joignable à la même adresse — c’est non négociable.
Depuis les paramètres réseau de Windows Server 2025 (Network & Internet → Ethernet), on passe l’assignation IP en mode Manual. On définit alors l’adresse 10.10.0.10 avec un masque /24, ce qui place le serveur directement dans le réseau interne 10.10.0.0/24. La passerelle par défaut est 10.10.0.1, qui correspond au bridge vmbr1 de Proxmox et assure la sortie vers l’extérieur via le NAT.
Pour le DNS, on anticipe déjà la suite : le serveur se pointe lui-même en DNS primaire (10.10.0.10). Même si le rôle DNS n’est pas encore installé à ce stade, cette configuration évite bien des surprises lors de la promotion en contrôleur de domaine. Un DNS public (comme 1.1.1.1) peut rester en secondaire temporairement, mais le cœur de la résolution doit rester local.
Une fois les paramètres appliqués, le serveur dispose maintenant d’une configuration réseau propre, stable et parfaitement adaptée à son futur rôle de pilier du domaine.
Validation rapide — vérifier que le réseau fonctionne vraiment
Une fois l’adresse IP statique configurée, il est important de ne pas continuer « à l’aveugle ». Avant d’installer les rôles serveur, on s’assure que la connectivité réseau est saine et que la machine peut joindre à la fois la passerelle Proxmox et Internet.
On ouvre d’abord une Invite de commandes ou PowerShell et on vérifie que les paramètres réseau ont bien été appliqués. La commande suivante permet de confirmer l’adresse IP, le masque, la passerelle et les serveurs DNS :
ipconfig /all
Si tout est correct, on doit y retrouver l’adresse 10.10.0.10, la passerelle 10.10.0.1 ainsi que le DNS pointant vers le serveur lui-même.
On teste ensuite la connectivité vers la passerelle du réseau interne, ce qui valide le lien entre la VM et Proxmox et test vers l’extérieur permet de confirmer que le NAT fonctionne correctement et que le serveur a bien accès à Internet :
ping 10.10.0.1 ping google.com
Si ces tests sont concluants, la base réseau est saine
Étape 2 — Renommer le serveur avant d’aller plus loin
Avant d’installer les rôles Active Directory, il est fortement recommandé de donner au serveur un nom clair et définitif. Une fois le serveur promu en contrôleur de domaine, changer son nom devient beaucoup plus complexe et déconseillé.
Depuis Server Manager, ouvrez la section Local Server, puis cliquez sur le nom actuel du serveur pour accéder aux System Properties. Dans l’onglet Computer Name, utilisez le bouton Change pour définir un nouveau nom. Dans cet exemple, le serveur est renommé SRV-DC1, un nom simple et explicite qui reflète clairement son rôle de contrôleur de domaine.
Validez les changements, puis redémarrez le serveur afin que le nouveau nom soit pleinement pris en compte par le système. Une fois le redémarrage terminé, le serveur est prêt pour l’installation des rôles AD DS, DNS et DHCP.
Étape 3 — Installer les rôles AD DS, DNS et DHCP
Maintenant que le serveur dispose d’un nom propre et d’une configuration réseau stable, on peut passer à l’étape clé : l’installation des rôles qui feront de cette machine le cœur de notre domaine.
Classiquement, on pourrait tout faire via l’interface graphique de Server Manager, en cliquant sur Add roles and features, en sélectionnant une installation basée sur les rôles, puis en cochant Active Directory Domain Services, DNS Server et DHCP Server. Cette méthode fonctionne très bien, mais elle implique plusieurs écrans et confirmations successives.
Dans un contexte de lab ou d’automatisation, il est souvent plus simple et plus rapide d’utiliser PowerShell. Une seule commande permet d’installer l’ensemble des rôles nécessaires, ainsi que leurs outils de gestion :
Install-WindowsFeature AD-Domain-Services,DNS,DHCP -IncludeManagementTools
Après l’exécution de la commande, PowerShell confirme que l’installation s’est déroulée avec succès. À ce stade, les rôles sont bien présents sur le serveur, mais Active Directory n’est pas encore configuré. La prochaine étape consistera donc à promouvoir le serveur en contrôleur de domaine et à créer la forêt.
Étape 4 — Promouvoir le serveur en contrôleur de domaine (via PowerShell)
Les rôles AD DS, DNS et DHCP sont maintenant installés, mais à ce stade le serveur n’est pas encore un contrôleur de domaine. Il lui manque l’étape la plus importante : la création du domaine et de la forêt Active Directory.
Plutôt que de passer par l’interface graphique et le bouton Promote this server to a domain controller, nous allons effectuer cette opération directement via PowerShell. Cette approche est plus rapide, plus propre et parfaitement adaptée à un environnement de lab sous Proxmox.
Ouvrez PowerShell en tant qu’administrateur, puis lancez la commande suivante :
Install-ADDSForest ` -DomainName "lab.local" ` -DomainNetbiosName "LAB" ` -InstallDNS ` -SafeModeAdministratorPassword (ConvertTo-SecureString "Pa$$123AD" -AsPlainText -Force) ` -Force
Cette commande crée une nouvelle forêt Active Directory nommée lab.local, installe automatiquement le rôle DNS, et définit le nom NetBIOS du domaine (LAB).
Le mot de passe spécifié correspond au mot de passe DSRM (Directory Services Restore Mode), utilisé uniquement pour les opérations de récupération du contrôleur de domaine en cas de problème majeur.
⚠️ Dans cet exemple, le mot de passe Pa$$123AD est volontairement simple pour un environnement de test.
En production, il est impératif d’utiliser un mot de passe fort et de le conserver en lieu sûr.
Une fois la commande validée, le serveur procède automatiquement à la configuration du domaine, puis redémarre sans autre intervention. C’est normal.
Validation rapide du domaine
Une fois le serveur redémarré et la connexion effectuée avec un compte du domaine, il est important de vérifier que la promotion en contrôleur de domaine s’est déroulée correctement. Pour cela, quelques commandes PowerShell suffisent.
On commence par interroger la forêt Active Directory afin de confirmer qu’elle a bien été créée et qu’elle fonctionne au niveau attendu :
Get-ADDomain
La sortie doit notamment indiquer le nom de la forêt (lab.local), le contrôleur de domaine principal (SRV-DC1.lab.local) ainsi que le niveau fonctionnel (Windows2025Forest). Ces informations confirment que la forêt Active Directory est opérationnelle.
On vérifie ensuite le domaine lui-même :
Get-ADForest
Cette commande permet de valider le nom du domaine, le nom NetBIOS (LAB), ainsi que les rôles FSMO (PDC Emulator, RID Master, Infrastructure Master), qui sont tous hébergés par le contrôleur de domaine fraîchement créé.
Si ces deux commandes retournent des informations cohérentes, le domaine est correctement en place : Active Directory, DNS et la structure de base sont prêts à accueillir les clients et les services. La suite logique consiste maintenant à configurer le service DHCP et à joindre une machine Windows 11 au domaine.
Étape 5 — Configurer le service DHCP (autorisation et distribution d’adresses)
À ce stade, le contrôleur de domaine est opérationnel et le rôle DHCP est installé, mais le service n’est pas encore fonctionnel. Par défaut, un serveur DHCP sous Active Directory doit être explicitement autorisé avant de pouvoir distribuer des adresses IP sur le réseau.
On commence donc par ouvrir PowerShell en tant qu’administrateur, connecté avec un compte Domain Admin, puis on autorise le serveur DHCP dans l’Active Directory :
Add-DhcpServerInDC ` -DnsName "SRV-DC1.lab.local" ` -IPAddress 10.10.0.10
Cette commande enregistre le serveur DHCP auprès de l’Active Directory et lui permet officiellement de répondre aux requêtes des clients. Sans cette autorisation, aucun poste ne recevrait d’adresse IP, même si le service DHCP est démarré.
Un avertissement concernant le service RPC peut apparaître immédiatement après l’exécution de la commande ; dans un environnement de laboratoire fraîchement installé, ce message est courant et n’empêche pas l’autorisation effective du serveur DHCP.
Une fois le serveur autorisé, il est temps de définir le scope DHCP, c’est-à-dire la plage d’adresses qui sera distribuée aux machines du réseau interne 10.10.0.0/24.
Toujours depuis PowerShell, on crée un scope avec une plage adaptée à un environnement de lab :
Add-DhcpServerv4Scope ` -Name "LAN-10.10.0.0" ` -StartRange 10.10.0.100 ` -EndRange 10.10.0.200 ` -SubnetMask 255.255.255.0
Cette plage laisse volontairement de la place pour les adresses statiques, notamment Proxmox (10.10.0.1) et le contrôleur de domaine (10.10.0.10).
Si l’on souhaite exclure explicitement certaines adresses du scope, par exemple pour éviter toute attribution accidentelle, on peut ajouter une exclusion :
Add-DhcpServerv4ExclusionRange ` -ScopeId 10.10.0.0 ` -StartRange 10.10.0.1 ` -EndRange 10.10.0.50
Le point le plus critique reste la configuration des options DHCP, car ce sont elles qui indiquent aux clients comment accéder au réseau et au domaine.
On commence par définir la passerelle par défaut, qui correspond au NAT Proxmox :
Set-DhcpServerv4OptionValue ` -ScopeId 10.10.0.0 ` -Router 10.10.0.1
Ensuite, on configure le serveur DNS du domaine, qui est notre contrôleur de domaine :
Set-DhcpServerv4OptionValue ` -ScopeId 10.10.0.0 ` -DnsServer 10.10.0.10
Enfin, on précise le nom de domaine DNS que les clients utiliseront automatiquement :
Set-DhcpServerv4OptionValue ` -ScopeId 10.10.0.0 ` -DnsDomain "lab.local"
À ce stade, le scope est prêt. Il ne reste plus qu’à s’assurer qu’il est bien actif (ce qui est généralement le cas par défaut après création).
Validation de la configuration DHCP
Pour confirmer que tout est correctement en place, quelques commandes de vérification suffisent :
Get-DhcpServerv4Scope
Cette commande permet de vérifier que le scope 10.10.0.0 est bien présent et actif.
Get-DhcpServerv4OptionValue -ScopeId 10.10.0.0
On doit y retrouver la passerelle (10.10.0.1), le DNS (10.10.0.10) et le domaine (lab.local).
Si c’est le cas, le serveur DHCP est pleinement fonctionnel.
ipconfig /registerdns Restart-Service netlogon
Étape 6 — Vérifier le DNS avant d’ajouter un client
Avant d’intégrer un poste client au domaine, il est essentiel de s’assurer que le DNS fonctionne correctement. Dans un environnement Active Directory, presque tous les mécanismes reposent sur la résolution de noms ; un DNS défaillant entraînera immanquablement des erreurs lors de la jointure au domaine.
Depuis le contrôleur de domaine, on commence par vérifier que le nom du domaine se résout correctement via le serveur DNS local. La commande suivante interroge explicitement le DNS du serveur lui-même :
nslookup lab.local 127.0.0.1
La réponse doit indiquer que le domaine lab.local est bien résolu et associé au serveur DNS local. Cela confirme que la zone DNS du domaine est correctement créée.
On vérifie ensuite la résolution du nom complet du contrôleur de domaine :
nslookup srv-dc1.lab.local 127.0.0.1
Cette étape permet de confirmer que les enregistrements DNS du contrôleur de domaine sont bien présents et accessibles, ce qui est indispensable pour l’authentification et la découverte des services AD.
Enfin, un simple test de connectivité permet de valider que le nom du serveur est bien résolu jusqu’à l’adresse IP correspondante :
ping srv-dc1
Enfin, pour une validation “AD-proof” (celle qui rassure vraiment avant d’ajouter un client), on demande à Windows de trouver un contrôleur de domaine pour 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 aligné : DNS OK, DC détecté, services AD prêts.
Étape 7 — Créer un utilisateur de test via PowerShell
Plutôt que de passer par la console graphique, on peut créer l’utilisateur directement depuis PowerShell. C’est plus rapide, scriptable et beaucoup plus proche de ce qu’on ferait en automatisation ou en production.
Depuis le contrôleur de domaine, ouvre Windows PowerShell en administrateur.
On commence par créer une OU dédiée pour nos utilisateurs, afin d’éviter de tout laisser dans le conteneur par défaut Users :
New-ADOrganizationalUnit ` -Name "DomainUsers" ` -Path "DC=lab,DC=local"
Ensuite, on crée l’utilisateur de test oleks dans cette OU :
$Password = ConvertTo-SecureString "Pass1FortSecure!" -AsPlainText -Force New-ADUser ` -Name "oleks" ` -GivenName "oleks" ` -Surname "test" ` -SamAccountName "oleks" ` -UserPrincipalName "[email protected]" ` -Path "OU=DomainUsers,DC=lab,DC=local" ` -AccountPassword $Password ` -Enabled $true
L’utilisateur est immédiatement actif et prêt à être utilisé pour la jointure au domaine ou pour une ouverture de session.
À noter : le mot de passe utilisé ici est volontairement simple pour un labo. En environnement réel, il faut impérativement appliquer un mot de passe long et robuste, idéalement renforcé par des stratégies de sécurité (GPO, rotation, MFA). Active Directory étant le cœur de l’infrastructure, c’est un point sur lequel il ne faut jamais transiger.
Pour vérifier rapidement que l’utilisateur existe bien dans l’annuaire :
Get-ADUser oleks
Si l’objet est retourné sans erreur, tout est prêt côté Active Directory.
Résultat attendu
À ce stade, le serveur est pleinement opérationnel : les rôles AD DS, DNS et DHCP sont installés, configurés et fonctionnels. Le contrôleur de domaine est actif, le service DNS répond correctement aux requêtes, et le serveur DHCP est autorisé dans l’Active Directory avec un scope prêt à distribuer des adresses IP aux clients du réseau interne.
Et voilà 🙂
En quelques étapes bien maîtrisées — et surtout sans passer des heures à cliquer dans l’interface graphique — nous avons mis en place un Windows Server 2025 complet : contrôleur de domaine, serveur DNS et DHCP, parfaitement intégré dans un réseau interne Proxmox via NAT. Grâce à PowerShell, la configuration est plus rapide, plus reproductible et surtout beaucoup plus propre.
À partir de maintenant, toute l’infrastructure est prête : il ne reste plus qu’à connecter un poste Windows 11 au domaine et commencer à exploiter pleinement Active Directory
Bonne chance!
☕ Ce tutoriel vous a fait gagner du temps ?
Si vous souhaitez soutenir mon travail et l'hébergement du site, vous pouvez m'offrir un café.
C'est grâce à votre soutien que je continue à partager ces guides !