Il s'agit d'une Question canonique sur les services de domaine Active Directory (AD DS).
Qu'est-ce qu'Active Directory? Que fait-il et comment fonctionne-t-il?
Je me retrouve à expliquer presque quotidiennement ce que je suppose être de notoriété publique. Nous espérons que cette question servira de question canonique et de réponse à la plupart des questions de base d'Active Directory. Si vous pensez que vous pouvez améliorer la réponse à cette question, modifiez-la.
Les services de domaine Active Directory sont le serveur d'annuaire de Microsoft. Il fournit des mécanismes d'authentification et d'autorisation ainsi qu'un cadre dans lequel d'autres services connexes peuvent être déployés (services de certificats AD, services fédérés AD, etc.). Il s'agit d'une base de données compatible LDAP qui contient des objets. Les objets les plus couramment utilisés sont les utilisateurs, les ordinateurs et les groupes. Ces objets peuvent être organisés en unités organisationnelles (UO) selon un certain nombre de besoins logiques ou commerciaux. Les objets de stratégie de groupe (GPO) peuvent ensuite être liés aux unités d'organisation pour centraliser les paramètres de divers utilisateurs ou ordinateurs dans une organisation.
Lorsque les gens disent "Active Directory", ils font généralement référence aux "services de domaine Active Directory". Il est important de noter qu'il existe d'autres rôles/produits Active Directory tels que les services de certificats, les services de fédération, les services d'annuaire légers, les services de gestion des droits, etc. Cette réponse se réfère spécifiquement aux services de domaine Active Directory.
Une forêt est une frontière de sécurité. Les objets dans des forêts distinctes ne peuvent pas interagir les uns avec les autres, sauf si les administrateurs de chaque forêt distincte créent un trust entre eux. Par exemple, un compte d'administrateur d'entreprise pour domain1.com
, Qui est normalement le compte le plus privilégié d'une forêt, n'aura aucune autorisation dans une deuxième forêt nommée domain2.com
, Même si ces forêts existent dans le même réseau local, sauf s'il existe une confiance.
Si vous avez plusieurs unités commerciales disjointes ou si vous avez besoin de limites de sécurité distinctes, vous avez besoin de plusieurs forêts.
Un domaine est une limite de gestion. Les domaines font partie d'une forêt. Le premier domaine d'une forêt est appelé domaine racine de la forêt. Dans de nombreuses petites et moyennes organisations (et même dans certaines grandes), vous ne trouverez qu'un seul domaine dans une seule forêt. Le domaine racine de la forêt définit l'espace de noms par défaut de la forêt. Par exemple, si le premier domaine d'une nouvelle forêt est nommé domain1.com
, Il s'agit du domaine racine de la forêt. Si vous avez besoin d'un domaine enfant, par exemple - une succursale à Chicago, vous pouvez nommer le domaine enfant chi
. Le FQDN du domaine enfant serait chi.domain1.com
. Vous pouvez voir que le nom du domaine enfant a été ajouté au nom du domaine racine de la forêt. C'est généralement ainsi que cela fonctionne. Vous pouvez avoir des espaces de noms disjoints dans la même forêt, mais c'est une boîte de vers séparée pour une autre période.
Dans la plupart des cas, vous voudrez essayer de faire tout votre possible pour avoir un seul domaine AD. Il simplifie la gestion et les versions modernes d'AD permettent de déléguer très facilement le contrôle basé sur l'unité d'organisation, ce qui réduit le besoin de domaines enfants.
Pas vraiment. dcpromo.exe
, L'outil qui gère la promotion d'un serveur en DC n'est pas à l'abri des idiots. Cela vous permet de prendre de mauvaises décisions avec votre nom, alors faites attention à cette section si vous n'êtes pas sûr. (Modifier: dcpromo est déconseillé dans le serveur 2012. Utilisez l'applet de commande PowerShell Install-ADDSForest
Ou installez AD DS à partir du Gestionnaire de serveur.)
Tout d'abord, n'utilisez pas de TLD constitués comme .local, .lan, .corp ou tout autre merde. Ces TLD sont pas réservés. L'ICANN vend des TLD maintenant, donc votre mycompany.corp
Que vous utilisez aujourd'hui pourrait en fait appartenir à quelqu'un demain. Si vous possédez mycompany.com
, Alors la chose intelligente à faire est d'utiliser quelque chose comme internal.mycompany.com
Ou ad.mycompany.com
Pour votre nom AD interne. Si vous utilisez mycompany.com
Comme site Web pouvant être résolu en externe, vous devez également éviter de l'utiliser comme nom AD interne, car vous vous retrouverez avec un DNS à cerveau divisé.
Un serveur qui répond aux demandes d'authentification ou d'autorisation est un contrôleur de domaine (DC). Dans la plupart des cas, un contrôleur de domaine détiendra une copie du Global Catalog . Un catalogue global (GC) est un ensemble partiel d'objets dans les domaines tous dans une forêt. Il est directement consultable, ce qui signifie que les requêtes inter-domaines peuvent généralement être effectuées sur un GC sans avoir besoin d'être référées à un DC dans le domaine cible. Si un DC est interrogé sur le port 3268 (3269 si vous utilisez SSL), le GC est interrogé. Si le port 389 (636 si vous utilisez SSL) est interrogé, alors une requête LDAP standard est utilisée et les objets existants dans d'autres domaines peuvent nécessiter un référence .
Lorsqu'un utilisateur essaie de se connecter à un ordinateur qui est joint à AD à l'aide de ses informations d'identification AD, la combinaison de nom d'utilisateur et de mot de passe salée et hachée est envoyée au DC pour le compte d'utilisateur et le compte d'ordinateur qui se connectent. Oui, l'ordinateur se connecte également. Ceci est important, car si quelque chose arrive au compte d'ordinateur dans AD, comme quelqu'un réinitialise le compte ou le supprime, vous pouvez obtenir une erreur indiquant qu'une relation d'approbation n'existe pas entre l'ordinateur et le domaine. Même si vos informations d'identification réseau sont correctes, l'ordinateur n'est plus approuvé pour se connecter au domaine.
J'entends "J'ai un contrôleur de domaine principal (PDC) et je veux installer un contrôleur de domaine de sauvegarde (BDC)" beaucoup plus fréquemment que j'aimerais le croire. Le concept de PDC et de BDC est mort avec Windows NT4. Le dernier bastion pour PDC était dans un AD en mode mixte de transition Windows 2000 lorsque vous aviez encore des DC NT4. Fondamentalement, à moins que vous ne preniez en charge une installation de plus de 15 ans qui n'a jamais été mise à niveau, vous n'avez vraiment pas de PDC ou de BDC, vous n'avez que deux contrôleurs de domaine.
Plusieurs contrôleurs de domaine sont capables de répondre simultanément aux demandes d'authentification de différents utilisateurs et ordinateurs. Si l'un échoue, les autres continueront à offrir des services d'authentification sans avoir à en faire un "principal" comme vous auriez dû le faire dans les jours NT4. Il est recommandé d'avoir au moins deux contrôleurs de domaine par domaine. Ces contrôleurs de domaine doivent tous deux détenir une copie du GC et doivent tous deux être des serveurs DNS qui détiennent également une copie des zones DNS intégrées Active Directory pour votre domaine.
"Donc, s'il n'y a pas de PDC, pourquoi y a-t-il un rôle PDC qu'un seul DC peut avoir?"
J'entends beaucoup ça. Il y a un rôle PDC Emulator. C'est différent d'être un PDC. En fait, il existe 5 rôles d'opérations de maître unique flexibles (FSMO) . Ces rôles sont également appelés rôles d'Operations Master. Les deux termes sont interchangeables. Que sont-ils et que font-ils? Bonne question! Les 5 rôles et leur fonction sont:
Domain Naming Master - Il n'y a qu'un seul Domain Naming Master par forêt. Le maître de nom de domaine s'assure que lorsqu'un nouveau domaine est ajouté à une forêt, il est unique. Si le serveur détenant ce rôle est hors ligne, vous ne pourrez pas apporter de modifications à l'espace de noms AD, qui inclut des éléments tels que l'ajout de nouveaux domaines enfants.
Schema Master - Il n'y a qu'un seul maître d'opérations de schéma dans une forêt. Il est responsable de la mise à jour du schéma Active Directory. Les tâches qui le nécessitent, telles que la préparation d'AD pour une nouvelle version de Windows Server fonctionnant en tant que DC ou l'installation d'Exchange, nécessitent des modifications de schéma. Ces modifications doivent être effectuées à partir du Schema Master.
Infrastructure Master - Il y a un maître d'infrastructure par domaine. Si vous n'avez qu'un seul domaine dans votre forêt, vous n'avez pas vraiment à vous en préoccuper. Si vous avez plusieurs forêts, vous devez vous assurer que ce rôle n'est pas détenu par un serveur qui est également un détenteur de GC sauf si chaque DC dans la forêt est un GC . Le maître d'infrastructure est chargé de s'assurer que les références interdomaines sont gérées correctement. Si un utilisateur dans un domaine est ajouté à un groupe dans un autre domaine, le maître d'infrastructure pour les domaines en question s'assure qu'il est géré correctement. Ce rôle ne fonctionnera pas correctement s'il se trouve sur un catalogue global.
RID Master - Le Relative ID Master (RID Master) est responsable de l'émission des pools RID aux contrôleurs de domaine. Il y a un maître RID par domaine. Tout objet dans un domaine AD a un unique Security Identifier (SID) . Il se compose d'une combinaison de l'identifiant de domaine et d'un identifiant relatif. Chaque objet dans un domaine donné a le même identifiant de domaine, donc l'identifiant relatif est ce qui rend les objets uniques. Chaque DC possède un pool d'ID relatifs à utiliser. Ainsi, lorsque DC crée un nouvel objet, il ajoute un RID qu'il n'a pas encore utilisé. Étant donné que les contrôleurs de domaine reçoivent des pools sans chevauchement, chaque RID doit rester unique pendant la durée de vie du domaine. Lorsqu'un DC arrive à ~ 100 RID restants dans son pool, il demande un nouveau pool au maître RID. Si le maître RID est hors ligne pendant une période prolongée, la création d'objet peut échouer.
PDC Emulator - Enfin, nous arrivons au rôle le plus mal compris de tous, le rôle d'émulateur PDC. Il existe un émulateur PDC par domaine. En cas d'échec d'une tentative d'authentification, elle est transmise à l'émulateur PDC. L'émulateur PDC fonctionne comme le "bris d'égalité" si un mot de passe a été mis à jour sur l'un DC et n'a pas encore été répliqué sur les autres. L'émulateur PDC est également le serveur qui contrôle la synchronisation de l'heure sur le domaine. Tous les autres contrôleurs de domaine synchronisent leur heure à partir de l'émulateur PDC. Tous les clients synchronisent leur heure à partir du DC auquel ils se sont connectés. Il est important que tout reste à moins de 5 minutes les uns des autres, sinon Kerberos se casse et quand cela se produit, tout le monde pleure.
La chose importante à retenir est que les serveurs sur lesquels ces rôles s'exécutent ne sont pas figés. Il est généralement trivial de déplacer ces rôles, donc si certains contrôleurs de domaine font un peu plus que d'autres, s'ils tombent en panne pendant de courtes périodes, tout fonctionnera normalement normalement. S'ils sont en panne depuis longtemps, il est facile de transférer les rôles de manière transparente. C'est beaucoup plus agréable que les jours NT4 PDC/BDC, alors veuillez cesser d'appeler vos contrôleurs de domaine par ces anciens noms. :)
Réplication, bien sûr . Par défaut, les contrôleurs de domaine appartenant au même domaine dans le même site se répliquent mutuellement à 15 secondes d'intervalle. Cela garantit que tout est relativement à jour.
Certains événements "urgents" déclenchent une réplication immédiate. Ces événements sont les suivants: Un compte est verrouillé pour trop de connexions infructueuses, une modification est apportée au mot de passe de domaine ou aux stratégies de verrouillage, le secret LSA est modifié, le mot de passe est modifié sur le compte d'ordinateur d'un contrôleur de domaine ou le rôle maître RID est transféré vers un nouveau DC. N'importe lequel de ces événements déclenchera un événement de réplication immédiate.
Les changements de mot de passe se situent quelque part entre urgent et non urgent et sont gérés de manière unique. Si le mot de passe d'un utilisateur est modifié sur DC01
Et qu'un utilisateur essaie de se connecter à un ordinateur qui s'authentifie auprès de DC02
Avant que la réplication ne se produise, vous vous attendez à ce que cela échoue, non? Heureusement, cela ne se produit pas. Supposons qu'il existe également un troisième DC appelé DC03
Qui détient le rôle d'émulateur PDC. Lorsque DC01
Est mis à jour avec le nouveau mot de passe de l'utilisateur, cette modification est immédiatement répliquée dans DC03
Également. Lorsque votre tentative d'authentification sur DC02
Échoue, DC02
Transmet ensuite cette tentative d'authentification à DC03
, Ce qui vérifie qu'elle est effectivement bonne et que la connexion est autorisée.
Le DNS est essentiel au bon fonctionnement de l'AD. La ligne officielle de Microsoft Party est que tout serveur DNS peut être utilisé s'il est correctement configuré. Si vous essayez d'utiliser BIND pour héberger vos zones AD, vous êtes au top. Sérieusement. Restez fidèle à l'utilisation des zones DNS intégrées AD et utilisez des redirecteurs conditionnels ou globaux pour d'autres zones si vous le devez. Vos clients doivent tous être configurés pour utiliser vos serveurs AD DNS, il est donc important d'avoir une redondance ici. Si vous avez deux contrôleurs de domaine, demandez-leur d'exécuter DNS tous les deux et de configurer vos clients pour qu'ils utilisent les deux pour la résolution de noms.
De plus, vous voudrez vous assurer que si vous avez plusieurs contrôleurs de domaine, ils ne se répertorient pas en premier pour la résolution DNS. Cela peut conduire à une situation où ils se trouvent sur un "îlot de réplication" où ils sont déconnectés du reste de la topologie de réplication AD et ne peuvent pas récupérer. Si vous avez deux serveurs DC01 - 10.1.1.1
Et DC02 - 10.1.1.2
, Leur liste de serveurs DNS doit être configurée comme ceci:
Serveur: DC01 (10.1.1.1)
DNS primaire - 10.1.1.2
DNS secondaire - 127.0.0.1Serveur: DC02 (10.1.1.2)
DNS primaire - 10.1.1.1
DNS secondaire - 127.0.0.1
Parce qu'une fois que vous savez ce que vous faites, votre vie devient infiniment meilleure. AD permet la centralisation de la gestion des utilisateurs et des ordinateurs, ainsi que la centralisation de l'accès et de l'utilisation des ressources. Imaginez une situation où vous avez 50 utilisateurs dans un bureau. Si vous souhaitez que chaque utilisateur dispose de sa propre connexion à chaque ordinateur, vous devez configurer 50 comptes d'utilisateurs locaux sur chaque PC. Avec AD, vous n'avez à créer le compte utilisateur qu'une seule fois et il peut se connecter à n'importe quel PC du domaine par défaut. Si vous vouliez renforcer la sécurité, vous devriez le faire 50 fois. Une sorte de cauchemar, non? Imaginez également que vous disposez d'un partage de fichiers auquel vous ne souhaitez que la moitié de ces personnes. Si vous n'utilisez pas AD, vous devrez soit répliquer leur nom d'utilisateur et leurs mots de passe à la main sur le serveur pour donner un accès sans pareil, soit créer un compte partagé et donner à chaque utilisateur le nom d'utilisateur et le mot de passe. Une façon signifie que vous connaissez (et devez constamment mettre à jour) les mots de passe des utilisateurs. L'autre moyen signifie que vous n'avez pas de piste d'audit. Pas bon, non?
Vous pouvez également utiliser la stratégie de groupe lorsque vous avez configuré AD. La stratégie de groupe est un ensemble d'objets liés aux unités d'organisation qui définissent les paramètres des utilisateurs et/ou des ordinateurs dans ces unités d'organisation. Par exemple, si vous souhaitez que "Arrêt" ne soit pas dans le menu Démarrer pour 500 PC de laboratoire, vous pouvez le faire dans un paramètre de la stratégie de groupe. Au lieu de passer des heures ou des jours à configurer manuellement les entrées de registre appropriées, vous créez une fois un objet de stratégie de groupe, vous le liez à la ou aux unités d'organisation appropriées, et vous n'avez plus jamais à y penser. Il existe des centaines d'objets de stratégie de groupe qui peuvent être configurés, et la flexibilité de la stratégie de groupe est l'une des principales raisons pour lesquelles Microsoft est si dominant sur le marché des entreprises.
Remarque: Cette réponse a été fusionnée dans cette question à partir d'une question différente qui posait des questions sur les différences entre les forêts, les domaines enfants, les arbres, les sites et les unités d'organisation. Cela n'a pas été écrit à l'origine comme une réponse à cette question spécifique.
Vous souhaitez créer une nouvelle forêt lorsque vous avez besoin d'une limite de sécurité. Par exemple, vous pouvez avoir un réseau de périmètre (DMZ) que vous souhaitez gérer avec AD, mais vous ne voulez pas que votre AD interne soit disponible dans le réseau de périmètre pour des raisons de sécurité. Dans ce cas, vous souhaitez créer une nouvelle forêt pour cette zone de sécurité. Vous pouvez également souhaiter cette séparation si vous avez plusieurs entités qui ne se font pas confiance - par exemple une société Shell qui englobe des entreprises individuelles qui opèrent de manière indépendante. Dans ce cas, vous souhaitez que chaque entité ait sa propre forêt.
Vraiment, vous n'en avez plus besoin. Il existe quelques bons exemples de cas où vous souhaiteriez un domaine enfant. Une raison héritée est due à différentes exigences de stratégie de mot de passe, mais ce n'est plus valable, car il existe des stratégies de mot de passe affinées disponibles depuis le serveur 2008. Vous n'avez vraiment besoin d'un domaine enfant que si vous avez des zones avec une connectivité réseau incroyablement faible et que vous voulez pour réduire considérablement le trafic de réplication - un navire de croisière avec satellite WAN est un bon exemple. Dans ce cas, chaque navire de croisière peut être son propre domaine enfant, de manière à être relativement autonome tout en toujours en mesure de tirer parti des avantages d'être dans la même forêt que d'autres domaines de la même entreprise.
C'est une boule bizarre. De nouvelles arborescences sont utilisées lorsque vous souhaitez conserver les avantages de gestion d'une forêt unique mais que vous avez un domaine dans un nouvel espace de noms DNS. Par exemple corp.example.com
peut être la racine de la forêt, mais vous pourriez avoir ad.mdmarra.com
dans la même forêt en utilisant un nouvel arbre. Les mêmes règles et recommandations pour les domaines enfants s'appliquent ici - utilisez-les avec parcimonie. Ils ne sont généralement pas nécessaires dans les AD modernes.
Un site doit représenter une limite physique ou logique dans votre réseau. Par exemple, les succursales. Les sites sont utilisés pour sélectionner intelligemment des partenaires de réplication pour les contrôleurs de domaine dans différentes zones. Sans définir de sites, tous les contrôleurs de domaine seront traités comme s'ils se trouvaient au même emplacement physique et répliqués dans une topologie maillée. Dans la pratique, la plupart des organisations sont configurées de manière logique dans un hub et un rayon, les sites et les services doivent donc être configurés pour refléter cela.
D'autres applications utilisent également des sites et des services. DFS l'utilise pour les références d'espaces de noms et la sélection de partenaires de réplication. Exchange et Outlook l'utilisent pour rechercher le catalogue global "le plus proche" à interroger. Vos ordinateurs joints à un domaine l'utilisent pour localiser le ou les contrôleurs de domaine les plus proches pour vous authentifier. Sans cela, votre trafic de réplication et d'authentification est comme le Far West.
Ceux-ci doivent être créés de manière à refléter le besoin de votre organisation en matière de délégation d'autorisation et d'application de stratégie de groupe. De nombreuses organisations ont une unité d'organisation par site, car elles appliquent GPO de cette façon - c'est idiot, car vous pouvez appliquer GPO à un site à partir de Sites et Services en tant que bien. D'autres organisations séparent les UO par département ou fonction. Cela a du sens pour beaucoup de gens, mais la conception des UO devrait vraiment répondre à vos besoins et est plutôt flexible. Il n'y a pas de "façon unique" de le faire.
Une entreprise multinationale peut avoir des unités d'organisation de niveau supérieur de North America
, Europe
, Asia
, South America
, Africa
pour pouvoir déléguer des privilèges administratifs en fonction du continent. D'autres organisations peuvent avoir des unités d'organisation de niveau supérieur de Human Resources
, Accounting
, Sales
, etc. si cela a plus de sens pour eux. D'autres organisations ont des besoins stratégiques minimes et utilisent une disposition "plate" avec juste Employee Users
et Employee Computers
. Il n'y a vraiment pas de bonne réponse ici, c'est tout ce qui répond aux besoins de votre entreprise.