Comment préparer son déploiement
Avant de déployer votre environnement, je vous conseille de réfléchir aux points suivants :
- Il est préférable de privilégier les forêts mono-domaine. Le choix d’une forêt avec plusieurs domaines dépend plus de problème d’administration et de sécurité que de la gestion des sites géographiques ;
- Définissez les noms DNS pour vos domaines afin de garantir l’unicité. Eviter d’utiliser en interne le même nom que votre domaine externe. Il est préférable d’utiliser un sous-domaine de son nom public. N’utilisez pas un nom de domaine public dont vous n’avez pas acquis les droits ;
- De préférence, installez les services DNS et stockez vos zones DNS sur vos contrôleurs de domaine. Utilisez des zones DNS intégrées AD et activez les mises à jour sécurisées ;
- Etablissez la liste des sites et les connexions physiques entre les sites. Déterminer la bande passante et son usage. Si vous centralisez vos fichiers, la messagerie, l’intranet sur un site principal le fait d’ajouter un contrôleur de domaine sur un site distant ne réduira pas la consommation de bande passante et ne garantira pas les conditions de travail. Ouvrir une session n’est pas une finalité en soi ;
- Déterminer le meilleur site pour positionner le rôle émulateur PDC pour chaque domaine afin de limiter le nombre de saut vers les autres serveurs (par exemple sur un site central) ;
- De préférence conserver l’ensemble des rôles FSMO sur le moins de contrôleurs de domaine possible
- De préférence activer le catalogue global sur l’ensemble de vos contrôleurs de domaine dans la forêt. Si ce n’est pas le cas il ne faut pas héberger le catalogue global et le maître d’infrastructure sur le même contrôleur de domaine.
- Ne cumulez pas le rôle AD DS avec d’autres rôles afin de faciliter les migrations futures. Certains rôles sont incompatibles avec les services AD DS ;
- Déterminer les besoins des utilisateurs et la localisation des ressources. Si vous installez des serveurs applicatifs sur un site, il est conseillé d’y mettre également un contrôleur de domaine. Les services des serveurs applicatifs utilisent parfois des comptes du domaine et la présence d’un contrôleur de domaine du même domaine permet de garantir le bon démarrage des services même en cas de coupure de lien entre les sites.
- Déterminer le nombre d’utilisateurs sur chaque site : si un site dispose d’une centaine utilisateurs il est préférable d’avoir un contrôleur de domaine en locale afin de limiter les flux entre les sites. A l’inverse sur un site avec quelques utilisateurs, l’installation d’un contrôleur de domaine peut représenter un cout superflu étant donné qu’il faut assurer sa sécurité physique (locaux protégés) et le maintenir. Des solutions de secours pour ses utilisateurs via des connexions VPN peuvent être plus rentables que la gestion d’un serveur physique et ses contraintes d’exploitations.
- Planifier la configuration de vos sous-réseaux et éviter si possible l’utilisation de la plage 192.168.0.x et 192.168.1.x fréquemment utilisée par les fournisseurs d’accès et qui peut poser soucis lors de la mise en place d’une interconnexion avec d’autres sites.
- Mettez en place au minimum deux contrôleurs de domaine par domaine avec une sauvegarde de l’état du système pour garantir la restauration en cas de sinistre. Surveillez vos sauvegardes ;
- Sur les sites distants où vous ne disposez pas d’un environnement sécurisé envisagez l’option d’y installer un contrôleur de domaine en lecture seule. Le RODC (Read Only Domaine Controller) ne dispose que d’une partie des mots de passe pour les utilisateurs locaux. Cela réduit le risque de corruption des mots de passe des comptes d’administration ;
- Privilégiez l’installation de contrôleur de domaine en mode « Core » : option d’installation « Minimale » sans couche graphique (sans GUI).
Interconnexion avec d’autres domaines
Il est possible qu’à un moment ou un autre, vous vous retrouviez dans l’obligation de partager des ressources avec d’autres entreprises. C’est le cas par exemple lors du rachat d’une entreprise ou d’une fusion. Si dans une forêt Active Directory l’ensemble des domaines s’approuvent automatiquement, il est possible de mettre en place des relations d’approbations avec des environnements extérieurs à la forêt. La mise en place d’une approbation nécessite de disposer d’interconnexions entre les 2 réseaux et les contrôleurs de domaine des deux entités. Ce type de solution est simple à mettre en œuvre mais représente un risque de sécurité avec des partenaires sur lesquels vous n’avez pas de maîtrise. Il existe différents types d’approbation :
- Approbation de domaine : uniquement entre les deux domaines de l’approbation (non transitif)
- Approbation de forêt : entre l’ensemble des domaines des forêts de l’approbation (transitif)
- Approbation raccourcie : approbation entre 2 domaines d’une même forêt qui s’approuvent déjà par la transitivité des domaines parent. Elle permet d’optimiser les performances
- Approbation Kerberos : permet de créer des approbations avec des annuaires supportant l’authentification Kerberos autre que des domaines Active Directory
Les approbations entre des environnements Active Directory distincts, sont également utilisées afin de réaliser des opérations de migrations des utilisateurs et des ressources vers un nouveau domaine. Microsoft a fourni un outil spécifique à la restructuration de domaine, il s’agit d’Active Directory Migration Tool.
Une autre solution pour le travail collaboratif entre partenaires est la mise en œuvre de la fédération d’identité. La fédération d’identité ne nécessite pas de mettre en place des liaisons entre les contrôleurs de domaine des deux partenaires. Dans le principe chaque utilisateur va s’identifier dans son environnement et demander des tickets d’authentification Kerberos afin de les présenter au partenaire. « Active Directory Federation Services » est la solution de fédération proposé par Microsoft. Sa mise en œuvre est largement plus complexe que les approbations mais garantit un niveau de sécurité plus importante et évite d’exposer son environnement.
Pré requis pour les contrôleurs de domaine
Au niveau de l’édition de Windows Serveur 2016, vous pouvez, comme pour Windows Serveur 2012, utiliser une version standard ou entreprise. Nous ne donnerons pas plus de détail sur la version Essentiel qui est très limitée.
Avec Windows Serveur 2012 la nouveauté était la disparition des versions intermédiaires comme Enterprise qui existait sur Windows Serveur 2008. La version Standard et Datacenter ne se différenciaient que par la limite de droits à la virtualisation. Sur Windows Server 2016, certaines fonctionnalités comme « Storage Space Direct » ne sont disponibles que dans l’édition Datacenter.
Une autre nouveauté est la méthode de calcul des licences dont l’unité n’est plus le processeur physique mais le nombre de cœur. Je vous suggère le lien suivant : https://www.microsoft.com/fr–fr/cloud–platform/windows–server–pricing
Les contrôleurs de domaine Active Directory nécessitent que peu de ressources en comparaison d’autres services comme Microsoft Exchange ou SQL serveur. Les recommandations pour la version de l’OS sont souvent suffisantes. Néanmoins les valeurs minimales présentées dans les prérequis du Windows 2016 sont vraiment justes :
Un serveur avec 2 processeurs ou 2Vpcu, un mémoire de 2Go à 4 Go de RAM et 60 Go de disque est suffisant pour ce type d’usage. Si vous installez d’autres éléments comme un antivirus par exemple il faudra tenir compte des préconisations de ces éléments.
Si vous disposez d’une forêt avec plusieurs domaines il est recommandé de mettre un peu plus de mémoire pour le rôle de catalogue global.
Il est possible de virtualiser les contrôleurs de domaines, néanmoins ce n’est pleinement supporté que depuis Windows Serveur 2012. Ceci est dû à l’utilisation de clichés instantanés (Snapshot) » au niveau de l’Hyperviseur. Le retour en arrière d’un contrôleur de domaine avant Windows Serveur 2012 crée un problème de réplication (USNRollback).
 | A partir de Windows 2012 un Contrôleur de Domaine est en mesure de détecter un retour en arrière et peut en informer les autres afin de rattraper un retard. L’utilisation de cette technologie n’est pas une méthode de restauration d’objets Active Directory. Il existe d’autres techniques pour la restauration d’objets comme la corbeille Active Directory. L’Hyperviseur doit être compatible avec l’identifiant de génération de machines virtuelles. |
Il est recommandé de conserver un contrôleur de domaine physique ce qui facilitera le démarrage de l’Hyperviseur intégré à l’AD (surtout avec du cluster) et conservera au moins un DC intègre. Néanmoins les services de cluster ont été améliorés avec Windows 2016 et certains problèmes présents avec Windows Server 2012 sont maintenant gérés.
De plus Microsoft Hyper-V avec les machines virtuelles de génération 1 utilisent des disques virtuels IDE, il est recommandé d’ajouter un 2ème disque en SCSI pour héberger l’annuaire Active Directory. Le problème est lié au fait qu’Active Directory impose de désactiver le cache en écriture sur le disque où se trouve l’annuaire. Il est donc préférable d’utiliser des disques SCSI qui fournit cette option dans le protocole. Vous pouvez consulter l’extrait suivant qui vous donneront plus d’informations sur ce point :
Il est également important de ne pas synchroniser les horloges des machines virtuelles sur l’hôte. Active Directory utilise ses propres mécanismes de synchronisation d’horloge via l’émulateur PDC du domaine racine. Dans un domaine Active Directory la synchronisation des horloges entre les postes clients et les contrôleurs de domaines est importante pour garantir le bon déroulement des processus d’authentification.
Lors de l’installation d’un contrôleur de domaine dans un environnement existant ou dans une nouvelle forêt vous devez disposer de droits spécifiques en fonction de votre déploiement. Le tableau suivant, décrit les droits minimums requis pour effectuer l’opération.
| Que voulez-vous faire ? | Vous devez utiliser : |
| Installer une nouvelle forêt AD. | Un compte qui dispose du droit administrateur local sur le futur contrôleur de domaine. |
| Installer un nouveau domaine dans une forêt existante. | Un compte membre du groupe administrateurs de l’entreprise. La version du schéma doit correspondre à la version du système du nouveau serveur, sinon il faut mettre à jour le schéma. La mise à jour est automatique (ADPrep) depuis Windows Serveur 2012, mais vous devez utiliser un compte disposant des droits sur le schéma. |
| Installer un contrôleur de domaine supplémentaire dans un domaine existant. | Un compte administrateur du domaine, si la version du schéma de l’AD existant correspond à la version de l’OS du serveur. Sinon vous devez mettre à jour le schéma. |
| Mettre à jour le schéma dans un domaine existant (ADPrep / ForestPrep ) | Un compte membre du groupe « administrateurs du schéma ». |
| Préparer les domaines pour une version plus récente (ADPrep / DomainPrep ou ADPrep / DomainPrep /GPPPrep) | Un compte administrateur du domaine. |
| Préparer l’ajout un contrôleur de domaine en lecture seul ( ADPrep / rodcprep ) | Vous devez utiliser un compte membre du groupe « administrateurs de l’entreprise ». |