Comment redonder votre contrôleur de domaine – Windows Server

Publié par Geoffrey Sauvageot-Berland le

Bonjour à tous. Aujourd’hui nous allons voir comment mettre en place un système de redondance pour votre domaine Active directory. Afin d’assurer la stabilité ainsi que la pérennité du réseau de votre entreprise/organisation il est important de mettre en place la redondance de votre contrôleur de domaine, pour qu’en cas de coupure, une ou plusieurs machines puissent prendre le relais, et ainsi assurer la continuité du service. Dans ce didacticiel, je pars d’un lab virtuel « from scratch », avec comme point de départ deux machines Windows server fraichement installé.

Note : Windows Server n’offre (pour le moment) pas la possibilité de créer un cluster de basculement (failover clustering) pour assurer la haute disponibilité d’un contrôleur de domaine. Il faudrait donc que vos machines clientes aient en serveurs DNS au moins deux machines. Dans le cas de l’exemple présenté :

  • Le contrôleur de domaine 1
  • Le contrôleur de domaine 2

Disclaimer : Les points que je considererai comme acquis durant le déroulé de ce tutoriel sont les suivants :

  • Notions théoriques :
    • Qu-est-ce qu’un contrôleur de domaine (OU, Users, Groups etc.), et avoir un peu de connaissance sur windows server
    • Le paramétrage IP/DNS (fixe) sur un environement Windows
    • La notion de DNS

Si-vous n’êtes pas à l’aise avec ces notions, je vous invite à consulter le cours d’introduction à l’active directory rédigé par mon collègue Florian Burnel : https://www.it-connect.fr/cours/notions-de-base-de-lactive-directory/

Bonne lecture.

0. Prérequis :

  • Assurez-vous d’avoir la même version de Windows Server sur tous vos hôtes. (ce n’est pas une obligation, tout dépend du niveau fonctionnel du domaine et de la forêt. Dans notre cas le niveau fonctionnel sera fixé sur la valeur suivante : « Windows Server 2016 »)
  • Assurez-vous que vos nœuds (dans notre cas dc1 et dc2) sont tous joints au même domaine Active Directory ;
  • Vérifiez que vous disposez bien de comptes d’administration locaux pour chacun des  serveurs, avec les droits super-utilisateur. J’utiliserai tout du long le compte administrator, car j’utilise Windows Server avec une version anglaise.
  • Un PC assez puissant (pouvant gérer 3 VMs de manières instantanées) si-vous utilisez un hyperviseur de type 2. (Dans mon cas VMware Workstation 16)

A. Configuration réseaux des 3 machines virtuelles

  • DC1
    • IP Fixe : 192.168.130.101/24
    • Gateway : 192.168.130.2
    • DNS 1 : 127.0.0.1
    • DNS 2 : 192.168.130.102
  • DC2
    • IP Fixe : 192.168.130.102/24
    • Gateway : 192.168.130.2
    • DNS 1 : 192.168.130.101
    • DNS 2 : 127.0.0.1
  • W10-Client
    • IP Fixe : 192.168.130.200/24
    • Gateway : 192.168.130.2
    • DNS 1 : 192.168.130.101
    • DNS 2 : 192.168.130.102

I. Etape 1 : Changement des IPs + hostname du premier serveur DC1

  • Paramètres Réseaux :
    • IP Fixe : 192.168.130.101/24
    • Gateway : 192.168.130.2
    • DNS1 : 127.0.0.1
    • DNS2 : 1.1.1.1

Dans un premier temps, nous allons procéder au changement du hostname de notre premier serveur (DC1), afin que celui-ci est une nomenclature convenable : Cliquez sur « computer name », puis sur « change », puis modifier le nom de la machine.

Le serveur va redémarrer suite au changement du hostname.

II. Etape 2 : Configuration du rôle ADDS (Active Directory Domain Service) depuis DC1

Depuis le menu « Server Manager », Cliquez sur « Manage » puis « Add roles and features »

Passer les 3 premières étapes en cliquant sur « Next » (étapes futiles)

Pour cette fenêtre laissez les options par défaut.

Pour cette fenêtre laissez les options par défaut.

Cochez l’option « Restart the destination server … » car l’acquisition du rôle ADDS nécessite que le serveur redémarre, afin de finaliser la configuration de celui-ci.

Cliquez ensuite sur « Install »

Dès lors que l’installation est finie, il faut « Promouvoir ce serveur en tant que contrôleur de domaine« , cliquez donc sur cette option.

Nous devons créer notre domaine (donc créer une nouvelle forest) . Dans mon cas, je vais utiliser le nom de domaine local suivant : lgds.local

Fixez l’option « Forest functional Level » et « Domain Functional level » sur « Windows Server 2016 » (Il n’y a pas plus récent pour le moment), afin de bénéficier des dernières fonctionnalités. Renseignez un mot de passe DSRM. (Nous en aurons besoin, lors de l’ajout de notre second deuxième serveur DC2 en tant que contrôleur de domaine de secours)

Lorsque vous installez un contrôleur de domaine, par défaut il faut installer le rôle DNS. (ce n’est pas obligatoire mais c’est mieux pour éviter les problèmes.) Dans tout les cas, il lui faudra rattacher un serveur DNS au rôle ADDS, étant donné, que le fondement même d’ADDS est d’utiliser des noms de domaines (DNS), pour l’identification des hôtes au sein d’un réseau.

Note : Un collègue à déjà vu un contrôleur de domaine fonctionner avec des zones DNS gérées sur un serveur Linux avec Bind9… (Ou comment se complexifier la vie pour rien ^^)

Dans notre cas, nous allons laissez par défaut l’installation du rôle DNS avant de cliquer sur « next ».

Vérifier que le netbios du domaine est correct.

Par défaut, je laisse les emplacements par défaut en ce qui concerne le stockage, pour les ressources suivantes :

  • ADDS Database
  • Logs Files
  • SYSVOL

Après avoir vérifié que vous avez bien renseigné les bonnes informations, durant le processus d’installation, Windows Server vous présente une fiche récapitulative de ce que vous avez renseigné.

Dès lors, une étape de vérification est enclanchée. Une fois que celle-ci est passée, vous pouvez cliquer sur « install »

Le serveur va redémarrer une fois automatiquement, afin d’appliquer les modifications. Vous verrez ensuite le rôle ADDS + DNS installé avec succès depuis la console du server manager de votre serveur DC1.

Dès à présent, vous avez l’accès à la console « Active Directory Users and computers ». Je ne vais pas rentrer dans les détails concernant les spécificités régissant un contrôleur de domaine (OU, Users, Groups (Global/Domain Local/Universal)

III. Etape 3 – Préparation du serveur DC2, pour qu’il devienne lui aussi un controleur de domaine « Mirroir » de DC1

A. Changement du hostname pour notre deuxième serveur

Premièrement, nous allons procéder au changement du hostname de notre deuxième serveur (DC2), afin que lui aussi ai une nomenclature convenable :

Le serveur va redémarrer suite au changement du hostname.

B. Vérification de la connectivité – Peut-il communqiuer avec DC1 ?

  • Paramètres Réseaux de DC2 :
    • IP Fixe : 192.168.130.102/24
    • Gateway : 192.168.130.2
    • DNS1 : 192.168.130.101
    • DNS2 : 127.0.0.1
  • La machine n’est pas forcément obligée d’être ajoutée au domaine.

Ouvrez ensuite un terminal, et tentez de pinguer dans un premier temps l’IP de DC1, (dans mon cas 192.168.130.101), puis le nom complet (FQDN) de cette machine : dc1.lgds.local). Puis enfin simplement le domaine : lgds.local

Si vous pouvez pinguer ces 3 instances, vous pouvez passer à la suite.

Ajoutez DC2 au domaine lgds.local. Cliquez sur « computer name » depuis le server manager, puis sur « change », puis dans la section « member of », ajoutez le domaine en question. Pour l’ajout de cet hôte au domaine, vous allez devoir vous connecter avec un compte utilisateur. Dans mon cas je vais utiliser le compte Administrator (de DC1).

Redémarrez la machine, puis connectez-vous avec le compte administrator du domaine de cette façon :

IV. Etape 4 – Installation du rôle ADDS depuis DC2

Nous allons reproduire presque à l’identique les étapes que nous avons effectuées plus haut, lors de la création de notre premier contrôleur de domaine DC1. Certaines phrases seront inchangées.

Passer les 3 premières étapes en cliquant sur « Next » (ce sont des étapes futiles)

Pour cette fenêtre laissez les options par défaut.

Pour cette fenêtre laissez les options par défaut.

Cochez l’option « Restart the destination server … » car l’acquisition du rôle ADDS nécessite que le serveur redémarre, afin de finaliser la configuration de celui-ci. Cliquez ensuite sur « Install »

Dès lors que l’installation du rôle ADDS est finie pour DC2, nous devons « Promouvoir ce serveur en tant que contrôleur de domaine« , cliquez donc sur cette option.

Cette fois-ci nous n’allons pas créer un domaine, (car nous avons déjà créé lgds.local en amont). En revanche, nous allons ajouter ce futur contrôleur de domaine (DC2) au domaine éxistant : lgds.local

Renseignez le mot de passe DRSM que vous aviez saisi lors de la création de notre premier contrôleur de domaine.

Rappel : Lorsque vous installez un contrôleur de domaine, vous devez obligatoirement installer le rôle DNS (vous n’avez pas le choix ^^) Normal, étant donné, que le fondement même d’ADDS est d’utiliser des noms de domaines (DNS), pour l’identification au sein d’un réseau.

Pour cette fenêtre laissez les options par défaut.

Pour cette fenêtre laissez les options par défaut

Après avoir vérifié que vous avez bien renseigné les bonnes informations, durant le processus d’installation, Windows Server vous présente une fiche récapitulative de ce que vous avez renseigné.

Dès lors, une étape de vérification est enclanchée. Une fois que celle-ci est passée, vous pouvez cliquez sur « install« 

Le serveur va redémarrer une fois automatiquement, afin d’appliquer les modifications. Vous verrez ensuite le rôle ADDS + DNS installé avec succès depuis la console du server manager de votre serveur DC2.

Note : La réplication des OU, Users, Groups n’est pas immédiate. Un délai par défaut de 15 minutes est nescessaire avant que la réplication s’effectue. Si-vous souhaitez que la réplication soit immédiate, je vous invite à suivre le tutoriel suivant : https://helpdeskgeek.com/how-to/active-directory-force-replication/ (Rien de bien compliqué ne vous en faites pas ^^)

V. Etape 5 – Test depuis un client Windows de la redondance du domaine lgds.local

Prérequis :

  • Paramètres Réseaux :
    • IP Fixe : 192.168.130.200/24
    • Gateway : 192.168.130.2
    • DNS1 : 192.168.130.101
    • DNS2 : 192.168.130.102
  • La machine cliente n’est pas forcément obligée d’être ajoutée au domaine (même si le but final, c’est que l’ensemble de vos machines cliente fassent partie de votre domaine dans un contexte d’entreprise), car nous souhaitons simplement tester la redondance du nom de domaine (dns) lgds.local, Par contre elle doit être en mesure de pinguer les deux contrôleurs de domaine DC1 (192.168.130.101) et DC2 (192.168.130.102)

Ouvrez un terminal depuis le client et exécutez la commande suivante, afin de pinguer le domaine (si cela ne marche pas du premier coup, tentez de pinguer le FQDN complet du contrôleur de domaine : dc1.lgds.local) :

Puis éteignez votre machine windows server DC1, afin de vérifier que DC2 prend le relais, pour assurer la continuité du service. Vider la cache dns avec la commande ipconfig /flushdns pour « vider les entrées existantes dans le cache DNS de la machine cliente » : Permet de gagner du temps pour le test), puis tentez de pinguer de nouveau votre domaine, et vous constaterez que ce n’est plus DC1 qui nous répond (192.168.130.101) mais DC2 (192.168.130.102), car nous avons éteint notre premier contrôleur de domaine DC1.

Note : Parfois, il faut redémarrer le poste client W10-client. Si le nettoyage du cache DNS ne suffit pas. (Les petits beugs de windows random, qui peuvent arriver de temps à autre. ^^)

Dans tous les cas, nous avons la confirmation que la redondance du domaine a bien eu lieu. Grâce à cela, vous n’aurez qu’une très courte interruption de service si jamais un de vos DC crash, qui clairement n’impactera pas vos utilisateurs (sauf l’exception qui confirme la règle peut-être ^^) tant que votre machine Windows aura bien DC1 et DC2 en temps que serveur DNS.

Au-delà de l’aspect redondance DNS, le fait d’avoir deux contrôleurs de domaine va permettre d’assurer une redondance pour l’authentification des clients, par exemple ouvrir une session sur un poste, mais aussi un équilibrage de charge entre les deux serveurs DC dans la gestion des clients. Puisque le serveur DC1 a été installé en premier, il dispose des « 5 rôles FSMO* » : s’il est hors ligne, il ne faut pas que ça dure une éternité non plus et que DC2 reste tout seul car ça finira par causer des problèmes.

*Pour plus d’information concernant cette notion, consultez le lien suivant : https://www.it-connect.fr/chapitres/les-cinq-roles-fsmo/

J’espère que l’article vous aura plu.

Merci à Florian Burnel, pour sa relecture précise 😉

++

Bel été 2021. La publication des articles reprendra fin août.

Geoffrey


En savoir plus sur Le Guide Du SecOps

Subscribe to get the latest posts sent to your email.


Geoffrey Sauvageot-Berland

Ingénieur diplômé par l’état en Informatique et Cybersécurité. Généraliste, à l'origine administrateur systèmes et réseaux, j’occupe actuellement un poste d’auditeur en sécurité offensive. J’apprécie également la programmation/automatisation. Fondateur du blog : "Le Guide du SecOps", anciennement "Le Guide du SysOps"

En savoir plus sur Le Guide Du SecOps

Abonnez-vous pour poursuivre la lecture et avoir accès à l’ensemble des archives.

Continue reading