Active Directory : Active Directory de votre chemin
La façon dont vous configurez votre topographie Active Directory aura un impact direct sur comment bien vous êtes en mesure d'organiser vos utilisateurs et les ressources.
Brien M. Posey
Depuis la sortie de Windows 2000 Server edition il y a plus de dix ans — et avec elle la version d'Active Directory, le service d'annuaire Microsoft éprouvé a aidé les organismes à maintenir l'ordre dans le chaos. La plupart des organisations prennent (bien qu'il y a certes des exceptions) la stratégie consiste à s'en tenir avec le déploiement de Active Directory plus simple qu'ils peuvent raisonnablement s'en tirer avec.
Cela ne sera pas une surprise. Le principe de garder les choses aussi simples que possible s'applique certainement au monde de l'informatique. Tout informaticien chevronné sait que garder les choses simples réduit les risques de problèmes et rend beaucoup plus facile de dépannage. Il n'y a absolument rien de mal avec l'utilisation d'une topologie Active Directory standard. Il ya une raison que Microsoft définie la topologie standard par défaut.
Mais alors qu'il y a quelque chose à dire pour plus de simplicité, quand il s'agit de Active Directory, certaines organisations pourraient mieux servies par une structure plus créative. Il existe certains modèles alternatifs qui risquent plus appropriés pour les grandes entreprises qui ont besoin de séparer les responsabilités de gestion.
Structure du domaine
Déploiements Active Directory réelles utilisent le plus souvent, une structure de domaine qui reflète la structure géographique de l'organisation. Par exemple, si une organisation possède trois bureaux, il est susceptible d'avoir trois domaines. Non chaque organisation utilise ce type de conception, mais c'est le type commun de la plupart de la structure Active Directory. Voici quelques structures de domaine alternatif que vous pouvez considérer pour votre organisation.
Domaines d'utilisateurs
Active Directory n'est vraiment rien d'autre qu'une base de données. La base de données est remplie avec différents types d'objets. Chaque objet est assigné à un ou plusieurs attributs. Les organisations de base parfois leur structure de domaines sur des types spécifiques d'objets Active Directory. Un exemple de ceci est l'utilisation des domaines d'utilisateurs.
Un domaine d'utilisateur est un domaine Active Directory mis en place dans le seul but de gérer les comptes d'utilisateurs. Pour vous donner une idée de pourquoi cela est utile, considérez cet exemple d'une organisation avec quelques milliers d'utilisateurs et un taux élevé de rotation du personnel. Cette organisation emploie deux personnes dont le travail consiste à créer, configurer et supprimer des comptes d'utilisateurs.
Dans ce genre de situation un domaine d'utilisateur pourrait se révéler utile, parce que ce type de structure de domaine aiderait les utilisateurs chargés de la gestion des comptes d'avoir un contrôle administratif complet sur les comptes d'utilisateurs. Ils pourraient être limitées, toutefois, d'avoir accès à d'autres objets Active Directory ou d'autres fonctions.
Vous n'avez pas besoin de mettre en œuvre ce type de structure de domaines spécifiquement pour isoler les responsabilités administratives. Il y a des autres moyens d'accomplir ce type d'isolation. Néanmoins, une structure de domaine utilisateur peut aider une entreprise à rester mieux organisé en rendant les domaines individuels que moins encombré. Il fournit également un sentiment d'isolement administratif physique, dont certaines organisations préfèrent plutôt que l'isolement administratif logique qui peut exister lorsque tous les différents types d'objets se trouvent dans un domaine commun.
Domaines de ressources
Domaines de ressources sont semblables aux domaines d'utilisateurs car ils sont à usage unique dans la nature. Ils servent à améliorer la sécurité ou la structure Active Directory de rendre plus logiques et plus faciles à gérer. Il y a les déploiements Active Directory réelle dans laquelle tous les ordinateurs de bureau sont regroupés dans un domaine de ressources dédiées. Autres organisations ont placé tous leurs serveurs exécutant des applications métier des principales dans un domaine de ressources dédiées. Vous pouvez utiliser des domaines de ressources pour n'importe quelle autre classe de ressource aussi bien.
Domaines de ressources sont probablement plus utiles quand vous traitez comme des domaines de gestion. Par exemple, vous pouvez créer une forêt Active Directory dédiée conçue pour agir purement comme un domaine de gestion pour les serveurs Hyper-V. Il y a quelques raisons pourquoi vous pouvez choisir de le faire.
La première raison a à voir avec la direction. System Center Operations Manager 2012 (et un certain nombre d'autres produits de gestion) peuvent gérer uniquement les serveurs qui sont membres d'un domaine Active Directory. Vous ne voulez pas joindre vos serveurs Hyper-V pour votre domaine principal car tous les contrôleurs de domaine pour votre domaine principal sont virtualisées. Vous ne voulez pas risquer de mettre votre entreprise dans une situation où vous étiez incapable de se connecter à un serveur Hyper-V parce que les contrôleurs de domaine virtuels étaient hors ligne. Ajout des serveurs Hyper-V pour une forêt dédiée de gestion Active Directory résout ce problème tout à fait bien.
Une autre raison, que vous pouvez choisir de créer un domaine de ressource dédiée pour vos serveurs Hyper-V doit faire avec quelques-unes des nouvelles fonctionnalités apportées à la version 3.0 de Hyper-V. Hyper-V 3.0 auront la possibilité de répliquer une machine virtuelle (VM) depuis un serveur vers un autre. Ce type de réplication n'est pas une solution de clustering de basculement, mais plutôt une solution de reprise après sinistre qui vous permet de conserver une copie à jour de vos machines virtuelles sur un serveur hôte. De cette façon, si quelque chose est arrivé à votre matrice de disques ou de votre principal hôte Hyper-V, vous auriez une autre copie de vos machines virtuelles que vous pourriez se replier sur.
Pour pouvoir utiliser cette fonctionnalité, cependant, le serveur hôte et le serveur de réplicas ont doivent être authentifiées. Pour fournir ce type d'authentification la plus simple consiste à joindre les deux serveurs d'un domaine commun et utiliser Kerberos. Par conséquent, la création d'un domaine de ressource dédiée pour les serveurs Hyper-V prend tout son sens. Cela est particulièrement vrai si l'on considère d'autres fonctionnalités Hyper-V qui exigent aussi l'appartenance au domaine.
Soit dit en passant, les domaines d'utilisateurs et de domaines de ressources ne sont pas mutuellement exclusives. Certaines organisations utilisent une combinaison de domaines d'utilisateurs et de domaines de ressources dans une forêt Active Directory commune.
Topologie géographique
Alors que ces structures de rechange sont en effet efficaces, la grande majorité des déploiements Active Directory dans le monde réel reposent sur la structure géographique. Techniquement, il n'y a rien de mal avec l'utilisation de ce type de topologie Active Directory, mais il y a quelques choses que vous devriez envisager.
Tout d'abord, ne confondez pas la structure de domaine avec la structure du site. La structure du site Active Directory doit toujours imiter topologie géographique de l'organisation. Pour chaque liaison de réseau (étendu WAN) étendu entre offices, il faudrait un lien de site correspondant dans Active Directory. En outre, les ordinateurs qui résident dans un bureau physique doivent être placés dans un site Active Directory commun. Idéalement, chaque emplacement doit faire utiliser un sous-réseau dédié parce qu'un seul sous-réseau ne peut pas s'étendre sur plusieurs sites Active Directory.
Structure de site Active Directory est important parce que la structure du site a une incidence directe sur le volume de trafic de réplication Active Directory qui s'écoule à travers les liaisons de réseau étendu. Par exemple, imaginez une organisation disposant de plusieurs succursales. Cette organisation a choisi de configurer son Active Directory dans un domaine unique, ce qui n'est pas mauvais. Dans une telle situation, vous pourriez potentiellement faire mises à jour d'Active Directory sur tout contrôleur de domaine accessible en écriture dans toute l'organisation. Lorsqu'une mise à jour se produit, c'est la responsabilité du contrôleur de domaine pour effectuer la mise à jour disponible pour les autres contrôleurs de domaine.
Si cet organisme n'a pas fait utilisation d'une structure de site approprié, une mise à jour commun pourrait se transmettre via une liaison réseau étendue plusieurs fois. Par exemple, s'il y avait cinq contrôleurs de domaine dans une succursale, une mise à jour Active Directory pourrait potentiellement être envoyée la liaison WAN à cinq reprises, une fois pour chaque contrôleur de domaine.
Lorsque vous utilisez les sites Active Directory, un contrôleur de domaine dans chaque site agit comme un serveur tête de pont. Emploi du serveur tête de pont est de recevoir des mises à jour Active Directory sur le réseau étendu et de distribuer ces mises à jour pour les autres contrôleurs de domaine dans le site. Cela signifie que n'importe quel répertoire Active mises à jour devra être envoyé à chaque succursale une fois, quel que soit le nombre de contrôleurs de domaine, il ya dans cette succursale.
Qu'en est-il des organisations qui utilisent un domaine distinct pour chaque succursale ? Si chaque succursale possède une forêt Active Directory dédiée, vous n'avez pas à vous soucier de définir les sites Active Directory. En revanche, si chaque domaine appartient à une forêt commune, vous devez implémenter une structure de site Active Directory appropriée sans aucun doute comme un moyen de maintenir le trafic de réplication Active Directory au niveau de la forêt en échec.
Comme vous pouvez le voir, il ya beaucoup de différentes manières de mettre en place votre structure de domaine Active Directory. En fin de compte, vous devez choisir la topologie qui fait le plus de sens pour votre entreprise. Cela pourrait être un modèle de domaine unique, ou un modèle multi-domaine basée sur la proximité géographique, des utilisateurs ou même des ressources.
.jpg)
Brien M. Posey, MVP, est un auteur technique indépendant avec des milliers d'articles et des dizaines de livres à son actif. Vous pouvez visiter site Web son à l'adresse brienposey.com.