La gestion des identités, et des droits associés, est une partie sensible et essentielle de l’infrastructure IT des entreprises, et Microsoft Active Directory est devenu une brique incontournable au sein des entreprises ayant un environnement Microsoft.   A l’heure où nombre de ces entreprises migrent sur le Cloud, se pose la question de l’automatisation de la couche Active Directory.

Nous vous proposons ici une méthodologie de migration de la couche AD sur le Cloud AWS, issue des bonnes pratiques du Cloud et de notre retour d’expérience. Lors de la migration dans le Cloud, il est indispensable de considérer Active Directory comme faisant partie du socle sur lequel l’infrastructure applicative viendra se greffer, tout comme la couche réseau. Autre point à noter, comme pour une infrastructure On-premise, il est nécessaire de déployer AD sur toutes les régions dans lesquelles l’infrastructure sera présente.

On pourrait envisager de recourir au service managé proposé par AWS, ADS (Amazon Directory Services), mais le coût de deux instances EC2 portant un AD est moindre qu’une souscription à ADS. Il est également plus simple d’étendre ses propres infrastructures AD vers un AD de même technologie, et que vos équipes maîtrisent déjà ! Afin de gagner en souplesse, nous avons appliqué la méthode du Replatforming pour tous les services Active Directory.

Deux choix sont possibles pour une entreprise souhaitant migrer vers AWS :

• étendre son infrastructure AD existante via une connexion de type VPN ou Direct Connect entre ses infrastructures et AWS
• créer une nouvelle infrastructure AD et y migrer ses ressources

Au vu de la récurrence de ce sujet dans nos projets, nous avons choisi d’automatiser la construction d’infrastructure Active Directory. Pour ce faire, nous avons combiné des solutions open-source telles que Packer, Terraform, Chocolatey, Boxstarter ainsi que certains services et fonctionnalités AWS (S3, DHCPOptionSet, etc.).

Il devient alors très simple d’étendre une infrastructure AD existante ou de créer de nouvelles forêts/domaines AD. Cette automatisation reste modulable, permettant d’envisager des builds simples, comme l’installation de deux contrôleurs de domaine sur deux zones de disponibilité, ou plus complexes, avec plusieurs dizaines de contrôleurs de domaine répartis sur plusieurs régions AWS.

Plusieurs éléments sont nécessaires :

• une AMI packer préparée avec les prérequis Chocolatey
• un VPC
• les informations relatives au domaine désiré

Les informations pour la création du domaine sont stockées sous forme de variables et récupérées via Chocolatey durant le processus. Dans la phase de construction, la première étape consiste à créer le premier nœud de l’infrastructure AD avec un package Chocolatey spécifique à la création d’une forêt AD. La création d’une nouvelle forêt AD nécessite deux redémarrages de la machine. À ce stade, un séquencement spécifique est nécessaire car tous les services AD doivent être opérationnels avant de pouvoir ajouter des contrôleurs supplémentaires.

Comment réaliser ce séquencement ? Dès le début de la première étape, une dépendance est mise en place. Celle-ci met en attente la construction du second contrôleur de domaine. Elle vérifie la présence d’un objet dans un bucket S3 préalablement défini.

Après la finalisation de la première étape (le premier nœud est totalement configuré et disponible, la forêt est up), un objet S3 est écrit dans le bucket surveillé par la dépendance. Cet objet contient l’adresse IP du premier nœud AD. Lorsque celle-ci voit l’objet, les étapes suivantes sont initiées.

Ces étapes sont modulables, nous utilisons des packages Chocolatey pour divers types d’opérations, comme par exemple l’ajout d’un second contrôleur de domaine, la création d’un sous domaine ou encore la définition de la structure OU. Dans le cas du rajout d’un DC, le rattachement au domaine est fait par une résolution DNS du nom de domaine. L’adresse IP récupérée dans la dépendance est définie comme serveur DNS de ce second nœud, permettant la résolution du nom de domaine et donc une communication vers le domaine. L’ajout de tout nœud supplémentaire se réalise de la même manière, l’important étant la disponibilité du premier nœud. Les autres nœuds peuvent après être construits en parallèle.

Les services DNS du domaine sont également pris en compte et déclarés sur le VPC AWS par une étape finale. La fonctionnalité « DHCPOptionset » est utilisée afin de définir les serveurs DNS du domaine sur le VPC. De ce fait, toute machine présente dans ce VPC sera capable de résoudre le nom de domaine et de profiter des services du domaine.

Il paraît plus simple d’intégrer de l’Active directory sur AWS … Aujourd’hui, l’automatisation nous permet de le faire en moins de 40 minutes et de façon modulbale !