Conception de la structure logique
Notion de Forêt et de domaine
Avant la création d’Active Directory, la gestion des utilisateurs et des ressources se faisait à l’aide d’un ou plusieurs domaines « NT » (New Technology). Une entreprise présente sur plusieurs sites disposait souvent d’un domaine pour chacun de ses sites. Dans un domaine NT, il y avait un serveur qui était accessible en écriture, le « Primary Domain Controller », les autres « Backup Domain Controller » ne sont que des copies en lecture de l’annuaire et pouvait assurer le rôle d’authentification de l’utilisateur. En cas de panne définitive du « PDC » il était possible de promouvoir un autre « BDC » en « PDC ». La réplication des modifications ne pouvait être initiée que depuis le « PDC » vers les « BDC ».
Active Directory est apparu avec Windows 2000. Il améliore la gestion des sites géographique et a permis la mise en place de la réplication multi-maître. Une modification peut être faite sur n’importe quels contrôleurs de domaine, elle sera répercutée sur les autres.
Un domaine Active Directory est un exemplaire d’un annuaire d’une même entité et représente une limite de sécurité. Il contient entre autres l’ensemble des utilisateurs et des ordinateurs de ce domaine. Des personnes d’une entité peuvent collaborer avec des utilisateurs d’autres domaines par l’intermédiaire de relation d’approbation configurée sur chaque domaine. Une approbation permet aux administrateurs de donner des accès à des ressources de son domaine pour des utilisateurs d’un autre domaine. Cela ne signifie pas qu’un utilisateur d’un domaine aura forcément accès aux ressources de l’autre domaine.
Un domaine peut être contenu dans un ensemble comportant d’autres domaines avec qui il partage des éléments communs. Cet ensemble de données est appelé forêt Active Directory. Dans une forêt Active Directory l’ensemble des domaines s’approuvent mutuellement.
Active Directory a dissocié la structure logique (organisation de l’entreprise) de la structure physique (situation géographique). Il n’est donc ni utile, ni recommandé, de créer plusieurs domaines si l’entreprise est implantée sur plusieurs sites géographiques.
ADDS est fortement lié à la résolution de nom DNS. Les services DNS fournissent les mécanismes nécessaires pour localiser les services et les ressources. La gestion des DNS est très importante et beaucoup de problèmes Active Directory y trouvent leur origine.
Un domaine est identifié par son nom DNS qui peut par exemple avoir la forme « mondomaineracine.monentreprise.fr » ou « mondomaineracine » est le nom du domaine et « monentreprise.fr » est appelé suffixe DNS. Une arborescence est un ensemble de domaines qui partage une racine commune dans leur nom DNS. Une forêt Active Directory peut posséder plusieurs arborescences.
Pour des raisons de compatibilité Active Directory a conservé également le nom de domaine court (NetBIOS). Le nom court est généralement la première partie du nom DNS, mais il n’y a aucune obligation à conserver ce format proposé par défaut lors de l’installation. De plus le nom court est limité à 15 caractères et « mondomaineracine » ne pourra donc être utilisé.
Par défaut les noms courts sont résolus par les services « WINS » qui sont de moins en moins utilisés en entreprise. Active Directory est indépendant de la résolution « WINS » et nous n’irons pas plus en détail sur ces fonctionnalités toujours présentes dans Windows Serveur mais de moins en moins utilisé. Les noms NetBIOS peuvent également être résolus par les services DNS en association le nom court et le suffixe DNS du domaine si les noms NetBIOS ne dépassent pas 15 caractères. Les noms courts (NetBIOS) peuvent également être résolus par des « broadcast » si l’ensemble de vos postes se trouve dans le même LAN.
Un domaine AD se représente en général par un triangle. Une relation d’approbation entre domaines Active Directory est représentée par un trait joignant les sommets des deux triangles.
L’image ci-dessous représente un exemple de forêt Active Directory.

Une forêt est un ensemble de domaines qui dispose de caractéristiques communes. Chaque domaine est représenté par un triangle. Il contient des objets utilisateurs, ordinateurs qui lui sont propres. Chaque domaine dispose d’un nom DNS unique qui le qualifie. Par exemple « groupe-alpha.fr » est le nom d’un domaine. Des domaines qui partagent une partie commune dans leur nom sont appelés une arborescence, comme par exemple « groupe-omega.fr » (domaine parent) et le « xxx.groupe-omega.fr » (domaine enfant). Chaque domaine dans une forêt est lié à son domaine parent. Le trait qui relie deux domaines au sommet du triangle représente la relation d’approbation.
Le premier domaine créé dans une forêt Active Directory est le domaine racine de la forêt. Le domaine racine de la forêt dispose de particularité comme certains groupes spécifiques.
Dans une forêt Active Directory tous les domaines partagent des propriétés communes pour chaque même type d’objet. Par exemple si vous ajoutez un champ date de naissance (ne le cherchez pas il n’existe pas par défaut) pour l’objet utilisateur ce champ sera disponible pour tous les utilisateurs de la forêt quelques soit le domaine. Cette structure commune qui définit les propriétés de chaque type d’objet est appelée le schéma Active Directory. Le schéma Active Directory qui décrit les objets et leurs propriétés est stocké dans une partition commune à l’ensemble de la forêt. Il existe une autre partition commune à l’ensemble de la forêt : la partition de configuration. Chaque domaine dispose enfin d’une partition qui lui est propre et qui contient les objets comme les utilisateurs les ordinateurs et les ressources. Cette partition est appelée « partition du domaine ».
Nous verrons qu’il existe d’autres partitions selon les versions de Windows. Il est également possible de créer des partitions particulières appelées « partitions d’application » mais cela n’est pas expliqué dans ce livre.
Il est important de comprendre qu’une forêt est un ensemble cohérent de domaine indissociable. Une forêt est viable si chaque domaine est intègre et si la communication avec les autres domaines fonctionne. Chaque domaine détient ses propres paramètres personnalisés pour les postes clients et les utilisateurs. Ces paramètres personnalisés s’appellent des stratégies de groupe (GPO).
Un Contrôleur de Domaine (DC) est un serveur Windows disposant d’un exemplaire de la partition du domaine auquel il appartient ainsi qu’un exemplaire de la partition de configuration et du schéma de la Forêt.
Active Directory étant basé sur un modèle multi maitre, toute modification faite d’un objet du domaine sur un contrôleur de domaine doit être répliquée sur les autres contrôleurs de domaine du même domaine. De la même manière toute modification sur la partition de configuration ou sur le schéma doit être répliquée avec l’ensemble des contrôleurs de domaines de la forêt.
Il faut retenir qu’un environnement Active Directory viable est un ensemble de contrôleurs de domaine qui arrivent à dialoguer ensemble. Si votre entreprise est répartie sur plusieurs sites sans qu’il y ait d’interconnexion informatique vous ne pourrez mettre en place une forêt unique.
Les Unités d’Organisation (OU : Organizational Units)
Une unité d’organisation notée « OU » pour « Organizational Units » est un objet d’un domaine Active Directory pouvant contenir des utilisateurs, des ordinateurs et d’autres unités d’organisation. Le rôle de l’unité d’organisation est de faciliter la gestion d’Active Directory en tenant en compte de l’application des stratégies de groupe et de la délégation de l’administration. En résumé il s’agit d’un dossier pour classer les éléments (objets AD).
L’image ci-dessous représente une organisation simple pour le classement des objets du domaine (ce n’est pas forcément celle qui vous conviendra le mieux) :

Les objets « Groupes », « utilisateurs », « Ordinateurs », « Windows 7 », « Windows 8 » sont des unités d’organisations qui peuvent contenir des utilisateurs (« Pierre Dupond »), des groupes (« Compta »), des ordinateurs (« PC001 »).
Dans cet exemple nous constatons qu’il est facile de cibler avec des paramètres spécifiques les postes en Windows 7 de ceux en Windows 8. Il est également possible de déléguer le droit de modifier des comptes utilisateurs aux ressources humaines sur une unité d’organisation spécifique, sans pour autant donner à ces personnes des droits sur les autres objets.
Représentation LDAP des noms des objets
Le compte de l’utilisateur « Pierre Dupond » qui est stocké dans l’unité d’organisation « utilisateurs » du domaine « charlie.groupe-alpha.fr » peut être identifié de manière unique dans la forêt Active Directory avec son nom LDAP. Le nom LDAP retrace l’ensemble du chemin pour accéder à un objet. Si l’on admet que le nom d’ouverture de session est « pdupond » alors notre utilisateur aura comme nom LDAP : « CN=pdupond,OU=Utilisateurs,DC=charlie,DC=groupealpha,DC=fr » ou « CN » représente le nom de l’objet. « OU » le nom du conteneur (unité d’organisation), « DC » représente une partie du nom de domaine situé entre deux points.
Pour l’ordinateur PC001, son nom LDAP est :
« CN=PC001, OU=Windows7, OU=Ordinateurs, DC=charlie, DC=groupe-alpha, DC=fr ».
Choisir un nom DNS
Un des éléments importants à définir avant le déploiement d’un domaine Active Directory est le nom DNS de votre domaine. Même s’il existe des solutions pour modifier un nom de domaine après sa création, l’opération reste généralement délicate car d’autres services ou applications peuvent en être dépendant (Exchange, SharePoint, …). Je vous conseille de ne pas renommer un domaine existant si vous ne maitrisez pas l’opération et l’ensemble des éléments qui s’appuie sur Active Directory et DNS.
Les règles suivantes s’appliquent aux conventions de nom DNS :
- N’utilisez que des caractères alphabétiques de (a à z) des chiffres (0 à 9) et des tirets (-),
- Le point (.) ne doit être utilisé que pour séparer un sous domaine de son domaine parent.
Vous pouvez consulter le lien suivant si vous souhaitez plus de détails : https://support.microsoft.com/fr–fr/kb/909264
Il est important de choisir un nom de domaine en 2 parties au minimum séparé par un point. Le nom de domaine doit être unique et ne pas être en conflit avec un nom de domaine public. L’utilisation de suffixe comme « .local » n’est pas plus recommandable que d’utiliser un sous-domaine de son domaine public, car même s’ils ne sont pas utilisés sur internet, rien ne garantit qu’il soit unique. Par exemple vous louer le nom publique « monentreprise.fr » et vous créez un sous-domaine « monAD.monentreprise.fr ». Les serveurs DNS de votre fournisseur gérera la zone DNS « monentreprise.fr » et vos contrôleurs de domaine le sous-domaine « monad.monentreprise.Fr ». Le nom principal vous étant attribué vous n’aurez pas de conflit entre votre nom interne, votre nom public ni avec celui d’une autre entreprise.
Quelques recommandations et « Best Practices »
Il est préférable de :
- Privilégier les forêts avec un domaine unique ;
- Si vous créer une forêt multi-domaine, il est recommandé de créer un domaine racine qui n’est ni un domaine de ressources, ni un domaine d’utilisateur afin de protéger les comptes et mots de passe disposant de droits sur l’ensemble de la forêt, surtout si l’administration des domaines est déléguée à différentes entités ;
- Organiser les unités d’organisations en fonction de la délégation des droits d’administrations et en fonction des stratégies de groupe. Il n’est pas utile d’essayer de représenter l’organigramme de l’entreprise.
- Utiliser un nom de domaine interne qui ne rentre pas en conflit avec une zone hébergé sur d’autres serveurs DNS, comme par exemple un sousdomaine de votre domaine public ;
- Ne pas utiliser pas de caractères spécifiques dans les noms DNS des domaines ;
- Utiliser un nom de domaine au minimum en 2 parties séparés par un «. » ;
- Utiliser une convention de nom d’ordinateur ne dépassant pas 15 caractères pour faciliter la résolution de nom.
Conception de la structure physique
Si la structure logique d’Active Directory permet de s’adapter aux besoins liés à l’administration du domaine, la structure physique va permettre de s’adapter à la répartition géographique de l’entreprise. Elle permettra d’optimiser les flux réseaux entre les sites situés dans différents lieux géographiques. Si une entreprise est présente sur plusieurs lieux géographiques, il est nécessaire de déterminer pour chaque site s’il est utile de disposer d’un contrôleur de domaine en local ou si l’authentification peut être réalisée depuis un autre site. Si le site ne dispose pas de contrôleur de domaine cela pourrai entrainer des problèmes d’authentification et impacter l’activité du site en cas de perte de lien externes. Néanmoins l’intérêt de garantir l’authentification de l’utilisateur, si l’utilisateur ne peut plus accéder à ses applications, sa messagerie, car ils sont hébergés ailleurs, reste discutable. De plus les postes clients disposent par défaut d’un cache autorisant l’utilisateur à se connecter sur le poste avec son dernier mot de passe même sans connectivité réseau. Cette fonctionnalité est couramment utilisée avec les ordinateurs portables.
Si le site dispose d’un contrôleur de domaine ce dernier doit être en mesure de répliquer les modifications vers les autres contrôleurs de domaine des autres sites. Il est donc nécessaire de tenir compte des performances et stabilités des liaisons entre les sites.
Nous allons donc définir deux périmètres pour la réplication Active Directory :
- La réplication inter-sites (entre des contrôleurs de domaine de sites différents)
- La réplication intra-site (entre les contrôleurs de domaine d’un même site).
Un site est un ensemble de sous-réseaux interconnectés par des liaisons rapides.
Un lien de site est une liaison plus au moins rapide entre 2 sites. Afin de garantir l’intégrité d’Active Directory il est possible de configurer plusieurs chemins de réplication pour en garantir l’efficacité. S’il peut être judicieux de mettre en place une redondance dans les chemins de réplication, il n’est pas nécessaire d’avoir des liens centralisés vers un même site principal (architecture en étoile), ni un maillage complet de chaque contrôleur de domaine vers tous les autres contrôleurs de domaine.
Il est préférable que toute modification sur l’AD puisse atteindre l’ensemble des contrôleurs de domaine sans excéder 3 sauts.
Le schéma ci-dessous présente un exemple de gestion des sites. Vous retrouvez en bleu les liens de réplications et dans les bulles jaunes les liaisons entre les sites ainsi qu’une notion de coût. Le coût dans les liens inter-sites permet de prendre en compte les capacités réelles des connexions entre les différents sites et d’optimiser les flux. Une liaison avec un coût faible sera prioritaire mais la liaison avec un coût plus élevé permettra d’assurer la continuité même si la liaison principale est inopérante.

En résumé lorsque vous ajoutez un site physique à votre réseau d’entreprise il est nécessaire de déterminer :
- S’il est utile de mettre un contrôleur de domaine sur ce site
- Le type de connexion permettant de relier les sites et leur « cout » d’utilisation (performance, prix)
- La fiabilité des liens et la bande passante
- La topologie de réplication afin d’assurer une latence raisonnable Afin de mettre en œuvre ce nouveau site nous devons :
- Configurer le site dans Active Directory
- Configurer les sous-réseaux pour ce site
- Configurer les liens de réplications inter sites.
Les sites sont généralement reliés entre eux avec des liaisons spécialisées ou des liens VPNs configurés au niveau des routeurs. Pour assurer les services, les contrôleurs de domaine doivent pouvoir communiquer et il est nécessaire d’autoriser le routage de ports spécifiques entre les sites. La solution la plus simple est de ne pas faire de filtrage, mais dans le cas contraire vous pouvez consulter la liste des ports nécessaires dans le lien suivant :
Partition de forêt ou de domaine et réplication multi maître
Active Directory dispose de différentes partitions. Au minimum nous en retrouvons trois :
- La partition de schéma unique dans la forêt
- La partition de configuration unique dans la forêt
- La partition du domaine différente pour chaque domaine de la forêt.
Il existe également 2 partitions liées à DNS la première au niveau de la Forêt, la deuxième au niveau du domaine.
Les partitions des forêts sont répliquées entre tous les contrôleurs de domaine de la forêt. Les partitions de domaines sont répliquées entre les contrôleurs de domaine du même domaine. Il est important de retenir qu’un domaine ne peut être isolé du reste de la forêt.
Un Catalogue global, qu’est-ce que c’est ?
Dans une forêt multi domaine chaque contrôleur de domaine ne gère que les utilisateurs de son domaine. Or il est possible à un utilisateur d’un domaine d’utiliser une ressource d’un autre domaine (si l’administrateur de ce domaine l’autorise). Les contrôleurs de domaine doivent être en mesure de localiser les objets des autres domaines de la forêt. Ce service est rendu par le catalogue global. Il contient également des informations sur des éléments spécifiques, comme les groupes universels indispensables au moment de l’ouverture d’une session. Si aucun catalogue global n’est joignable, le contrôleur de domaine ne pourra valider l’authentification et générer le jeton utilisateur contenant les groupes auquel il appartient. Pour certains sites distants, de petite taille, il existe une alternative qui n’oblige pas la mise en place du catalogue global en local : la mise en cache des groupes universels.
Le rôle de catalogue global augmente la consommation de ressources sur le serveur et il peut être utile d’augmenter la mémoire sur ces serveurs. Certaines applications comme Microsoft Exchange interrogent régulièrement le catalogue global. Il est important de disposer d’un catalogue global sur les sites ou sont déployés les serveurs de messagerie.
Il est recommandé de disposer d’un catalogue global sur un site si :
- Le site a plus de 100 utilisateurs
- Le site héberge une application effectuant un nombre élevé de requêtes sur le catalogue global.
Si un site contenant peu d’utilisateurs, dispose d’un contrôleur de domaine, il est recommandé d’activer la mise en cache des groupes universels si le contrôleur de domaine n’est pas catalogue global et si les connexions ne sont pas 100 % fiables.
Un cas particulier concerne les forêts avec un seul domaine. Dans la pratique c’est sans doute le cas le plus fréquemment rencontré. Dans une forêt avec un domaine unique, il est recommandé d’activer le catalogue global sur tous les contrôleurs de domaine.
FSMO, qu’est-ce que c’est ?
Dans une forêt Active Directory, il existe 5 rôles particuliers qui ne sont pas partagés par l’ensemble des contrôleurs de domaine. Ces rôles sont les rôles de maitre d’opération (Flexible Single Master Operations). Il existe 2 rôles présents sur un seul contrôleur de domaine de la forêt et 3 rôles présents sur un seul contrôleur de domaine de chaque domaine de la forêt. Les différents rôles FSMO ne se trouvent pas forcément sur le même contrôleur de domaine.
Il s’agit des rôles suivants pour la forêt :
- Le maître de schéma : toute modification de schéma (par exemple lors de l’installation d’un serveur de messagerie Microsoft Exchange ou lors de la migration vers des contrôleurs de domaine sur un système d’exploitation plus récent) doit être exécutée sur le contrôleur de domaine qui dispose du rôle de maître de schéma ;
- Le maitre d’attribution des noms de domaines : lorsque vous créez un nouveau domaine dans une forêt Active Directory le nom de ce domaine est vérifié et validé par le contrôleur de domaine qui dispose de ce rôle ; Au niveau de chaque domaine les 3 rôles sont :
- L’émulateur PDC : le rôle d’émulateur PDC est particulier. Au départ il a été créé pour assurer la compatibilité avec les contrôleurs de domaine secondaires de NT4. A première vue il n’a plus une grande utilité aujourd’hui, et pourtant l’émulateur PDC joue un rôle important au sein du domaine. Le premier élément est qu’il est par défaut utilisé comme source de temps dans un domaine Active Directory. Les postes clients et les serveurs synchronisent leur horloge sur les contrôleurs de domaine. Les contrôleurs de domaine d’un domaine utilisent par défaut l’émulateur PDC du domaine pour se synchroniser. L’émulateur PDC de chaque domaine synchronise automatiquement son horloge sur l’émulateur PDC du domaine racine de la Forêt. Il suffit donc de configurer la synchronisation de l’horloge sur l’émulateur PDC du domaine racine de la Forêt vers une source de temps fiable. Un autre élément important du rôle émulateur PDC est lié aux changements de mots de passe. Dans ce cas, une réplication urgente se fait vers l’émulateur PDC et le mécanisme de réplication garantie un temps de latence faible pour ce changement qui concerne la sécurité.
- Le maitre d’infrastructure : il assure les mises à jour des références des objets de son domaine par rapport aux autres domaines. Par défaut ce rôle ne doit pas être hébergé sur un contrôleur de domaine qui est catalogue global. Quelques exceptions existent par exemple dans le cas d’une Forêt avec un seul domaine (voir le chapitre sur le catalogue global).
- Le maitre RID : Active Directory étant multi maître chaque contrôleur de domaine peut créer des objets. Chaque objet doit disposer d’un identifiant unique. Pour réaliser cela, le maître RID distribue des plages différentes d’identifiants à chaque contrôleur de domaine qui seront utilisés lors des prochaines créations d’objets. Quand un contrôleur de domaine a utilisé tous les identifiants qui lui ont été attribués il demande une nouvelle plage d’identifiant au maître RID.