Le socle Active Directory : des postes en domaine, puis un second contrôleur
Ma première année en production : préparer les postes selon une procédure écrite, puis supprimer le point unique de défaillance du domaine, pour que l'arrêt d'un serveur ne prive plus personne de session, de DNS ni d'adresse IP.
En bref
Chaque nouvel arrivant devait trouver un poste prêt dans le domaine, et tout le domaine reposait sur un seul serveur, qui portait aussi le DNS et le DHCP : chaque redémarrage coupait tout le monde.
J'ai écrit et appliqué la procédure de mise en service des postes, puis promu une VM Hyper-V en second contrôleur, avec zone DNS répliquée et DHCP en basculement 50/50.
Des postes identiques, validés en cinq points. Panne simulée réussie, et en 2026, le second contrôleur a assuré l'authentification pendant les 25 minutes de redémarrage du premier.
Contexte
Première année d'alternance, dans une PME d'une vingtaine de personnes. Deux besoins de base. Chaque nouvel arrivant devait trouver un poste prêt : session du domaine, stratégies de groupe appliquées, partages accessibles, ERP de gestion commerciale installé. Et le domaine ne devait plus dépendre d'un seul serveur.
Tout reposait en effet sur un contrôleur unique, DC1, un serveur physique qui portait aussi le DNS et le DHCP. S'il s'arrêtait : plus de session ni de partages, plus de DNS (donc plus de Kerberos) et, une fois les baux expirés, plus d'adresse pour les postes. Chaque redémarrage de DC1 coupait tout le monde.
Ce que j'ai fait
- Écrire la procédure des postesDNS pointé vers les contrôleurs et heure juste, car Kerberos refuse par défaut un écart de plus de cinq minutes. Compte créé dans l'unité d'organisation de son service, qui détermine ses GPO. Jonction, puis
gpupdate /force, puis l'ERP depuis le partage informatique. Une procédure que n'importe qui dans l'équipe peut suivre. - Valider chaque poste en cinq pointsPing du domaine, accès aux partages, profil créé à la première connexion, devis de test dans l'ERP, Observateur d'événements sans erreur critique.
- Préparer le second contrôleurWindows Server sur Hyper-V, adresse IP fixe, mises à jour, jonction comme serveur membre. Un contrôleur ne doit jamais changer d'adresse : les postes l'utilisent comme DNS.
- Promouvoir, puis répliquer le DNSRôle AD DS installé (voir l'incident), promotion en contrôleur supplémentaire, réplication initiale. La zone du domaine, intégrée à l'annuaire, se réplique avec lui, sans transfert de zone ; les deux serveurs DNS sont déclarés.
- Répartir le DHCPBasculement en équilibrage de charge 50/50 plutôt qu'en secours à chaud : un partenaire qui travaille tous les jours révèle tout de suite qu'il ne répond plus.
Voir les détails techniques
Mise en service d'un poste
Adresse par DHCP ou fixe selon l'usage, mot de passe administrateur local, mises à jour et pilotes avant la jonction. Le compte de l'utilisateur est créé dans le Centre d'administration Active Directory, dans l'OU de son service. Sage 100c s'installe depuis le partage informatique, ses deux installeurs dans l'ordre, puis s'active avec la licence de l'entreprise.
Basculement DHCP
En secours à chaud, DC2 attendrait la panne de DC1. En équilibrage de charge, les deux serveurs distribuent en permanence, chacun sur la moitié de la plage.
| Paramètre DHCP | Valeur | Rôle |
|---|---|---|
| Mode | Équilibrage, 50 % / 50 % | Chaque serveur distribue la moitié des adresses |
| MCLT | 1 h | Écart maximal de durée de bail entre les deux serveurs, et délai avant de reprendre toute la plage si le partenaire est déclaré arrêté |
| Authentification des messages | Activée, secret partagé | Chaque serveur vérifie que les messages de synchronisation viennent bien de son partenaire |
PowerShell · diagnostic et correction de l'incident
# État réel du rôle et de ses outils
Get-WindowsFeature AD-Domain-Services
Get-WindowsFeature RSAT-ADDS
# Install State : Available, et non Installed
# Réinstallation avec les outils d'administration
Install-WindowsFeature AD-Domain-Services -IncludeManagementTools
# Vérification : Install State = Installed
Get-WindowsFeature AD-Domain-Services
L'incident
Le rôle AD DS « ajouté »… mais absent
Après l'ajout du rôle par l'assistant, la promotion échouait. Get-WindowsFeature indiquait Available, et non Installed : l'assistant n'était pas allé au bout.
Réinstallation en PowerShell, vérification, puis promotion sans erreur. Leçon retenue : vérifier un état par une commande, pas par l'interface.
Résultats
- Réplication : un compte de test créé sur DC1 est apparu sur DC2.
- DHCP :
ipconfig /releasepuis/renewsur un poste, bail obtenu. - Panne simulée : DC1 arrêté, l'ouverture de session passait par DC2, qui distribuait aussi les baux.
Ces tests manuels prouvent la bascule, pas sa durée. La vraie preuve est venue deux ans plus tard : pendant un redémarrage de DC1 en 2026, personne n'a perdu sa session. Côté postes, la procédure a rendu chaque mise en service identique à la précédente ; en revanche, tout restait manuel et sa durée n'était pas mesurée.
Ce que j'améliorerais
- J'automatiserais la jonction et l'installation des logiciels, par un script PowerShell ou une image de déploiement, et je déploierais Windows LAPS : un mot de passe d'administrateur local différent par poste, changé automatiquement.
- Active Directory est multi-maître : seuls les cinq rôles FSMO restent uniques, ici sur DC1. Je les répartirais en connaissance de cause, je vérifierais que DC2 est catalogue global et j'écrirais la procédure de reprise.
- J'activerais l'intervalle de basculement d'état du DHCP : lors d'une panne longue, DC2 reprendrait de lui-même toute la plage.
- Je chronométrerais la bascule et la prouverais par
dcdiag,repadmin /replsummary,netdom query fsmoetGet-DhcpServerv4Failover.
La suite du fil rouge : passer de la disponibilité à la sécurité, avec l'audit PingCastle de ce même annuaire en 2026.