Qu'est-ce que Active Directory?
Les services de domaine Active Directory constituent 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 associés peuvent être déployés (services de certificats AD, services fédérés AD, etc.). C'est 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 d'organisation (OU) en fonction d'un nombre quelconque de besoins logiques ou professionnels. Les objets de stratégie de groupe (GPO) peuvent ensuite être liés aux unités d'organisation afin de centraliser les paramètres de différents utilisateurs ou ordinateurs d'une organisation.
Lorsque les gens disent "Active Directory", ils font généralement référence à "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 de droits, etc. Cette réponse fait spécifiquement référence aux services de domaine Active Directory.
Qu'est-ce qu'un domaine et qu'est-ce qu'une forêt?
Une forêt est une limite de sécurité. Les objets situés dans des forêts distinctes ne peuvent pas interagir entre eux, à moins que les administrateurs de chaque forêt distincte ne créent une relation de confiance . 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, à moins d'une approbation en place. .
Si vous avez plusieurs unités business disjointes ou 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 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 nom par défaut pour 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 nom de domaine complet du domaine enfant seraitchi.domain1.com. Vous pouvez voir que le nom du domaine enfant était le nom du domaine racine de la forêt ajouté. C'est typiquement comme ça que ça marche. Vous pouvez avoir des espaces de noms disjoints dans la même forêt, mais c'est une boîte de Pandore tout à fait séparée pour une heure différente.
Dans la plupart des cas, vous devrez essayer de faire tout ce qui est en votre pouvoir pour avoir un seul domaine AD. Cela simplifie la gestion et les versions modernes d'AD facilitent la délégation du contrôle sur l'unité d'organisation, ce qui réduit le besoin de domaines enfants.
Je peux nommer mon domaine comme je veux, non?
Pas vraiment. dcpromo.exe, l'outil qui gère la promotion d'un serveur sur un contrôleur de domaine n'est pas idiot. Cela vous permet de prendre de mauvaises décisions avec votre nom, alors faites attention à cette section si vous n’êtes pas sûr. (Edit: dcpromo est obsolète dans Server 2012. Utilisez la Install-ADDSForestcmdlet PowerShell ou installez AD DS à partir du Gestionnaire de serveur.)
Tout d’abord, n’utilisez pas de TLD composés tels que .local, .lan, .corp, ni aucun autre de ces merdes. Ces TLD ne sont pas réservés. L'ICANN vend actuellement des TLD, de sorte mycompany.corpque votre ordinateur que vous utilisez aujourd'hui pourrait appartenir à quelqu'un de demain. Si vous possédez mycompany.com, alors la chose intelligente à faire est d'utiliser quelque chose comme internal.mycompany.comou ad.mycompany.compour votre nom AD interne. Si vous utilisez mycompany.comun site Web pouvant être résolu en externe, évitez de l’utiliser également comme nom d’AD interne, car vous obtiendrez un DNS à cerveau divisé.
Contrôleurs de domaine et catalogues globaux
Un serveur qui répond aux demandes d'authentification ou d'autorisation est un contrôleur de domaine. Dans la plupart des cas, un contrôleur de domaine conservera une copie du catalogue global . Un catalogue global (GC) est un ensemble partiel d'objets de tous les domaines d'une forêt. Il est directement interrogeable, ce qui signifie que les requêtes inter-domaines peuvent généralement être effectuées sur un GC sans nécessiter une référence à un contrôleur de domaine dans le domaine cible. Si un contrôleur de domaine est interrogé sur le port 3268 (3269 si SSL est utilisé), le GC est interrogé. Si le port 389 (636 en cas d'utilisation de SSL) est interrogé, une requête LDAP standard est utilisée et les objets existant dans d'autres domaines peuvent nécessiter une référence .
Lorsqu'un utilisateur essaie de se connecter à un ordinateur connecté à AD à l'aide de ses informations d'identification AD, la combinaison de noms d'utilisateur et de mots de passe salés et hachés est envoyée au contrôleur de domaine pour le compte d'utilisateur et le compte d'ordinateur en cours de connexion. l'ordinateur se connecte aussi. Cela est important, car si quelque chose arrive au compte d'ordinateur dans AD, par exemple si quelqu'un réinitialise ou supprime le compte, vous risquez d'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 fiable pour se connecter au domaine.
Problèmes de disponibilité du contrôleur de domaine
J'entends "J'ai un contrôleur de domaine principal (PDC) et je souhaite installer un contrôleur de domaine de sauvegarde (BDC)" beaucoup plus fréquemment que je voudrais y croire. Le concept de PDC et de BDC est mort avec Windows NT4. Le dernier bastion pour les PDC était dans un AD en mode mixte de transition Windows 2000 alors que vous disposiez toujours de contrôleurs de domaine 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 ni PDC ni 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. En cas d'échec, les autres continueront à offrir des services d'authentification sans avoir à en créer un "principal" comme vous auriez dû le faire au cours de la NT4. Il est recommandé d’avoir au moins deux centres de distribution par domaine. Ces contrôleurs de domaine doivent tous deux conserver une copie du catalogue global et être des serveurs DNS contenant également une copie des zones DNS intégrées à Active Directory pour votre domaine.
Rôles FSMO
"Donc, s'il n'y a pas de PDC, pourquoi y a-t-il un rôle de PDC que seul un seul DC peut avoir?"
Je l'entends beaucoup. Il existe un rôle d' émulateur PDC . C'est différent d'être un PDC. En fait, il y a 5 rôles FSMO (Flexible Single Master Operations) . Ils sont également appelés rôles de maître d'opérations. 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 maître de nommage de domaine par forêt. Le Domain Naming Master s'assure que lorsqu'un nouveau domaine est ajouté à une forêt, il est unique. Si le serveur qui détient ce rôle est hors ligne, vous ne pourrez pas modifier l'espace de noms AD, notamment pour l'ajout de nouveaux domaines enfants.
Schema Master - Il n'y a qu'un seul Schema Operations Master dans une forêt. Il est responsable de la mise à jour du schéma Active Directory. Les tâches qui en ont besoin, telles que la préparation d'AD pour une nouvelle version de Windows Server fonctionnant en tant que contrôleur de domaine ou l'installation d'Exchange, nécessitent des modifications de schéma. Ces modifications doivent être effectuées à partir du contrôleur de schéma.
Infrastructure Master - Il existe un maître d'infrastructure par domaine. Si vous n'avez qu'un seul domaine dans votre forêt, vous n'avez pas vraiment besoin de 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 titulaire du GC, à moins que chaque contrôleur de domaine de la forêt ne soit un GC . Le maître d'infrastructure est chargé de s'assurer que les références interdomaines sont traitées correctement. Si un utilisateur d'un domaine est ajouté à un groupe d'un autre domaine, le maître d'infrastructure des domaines en question s'assure qu'il est correctement géré. Ce rôle ne fonctionnera pas correctement s'il figure dans un catalogue global.
Maître RID - Le maître d’identification relatif (maître RID) est responsable de l’émission de pools de RID vers les DC. Il y a un maître RID par domaine. Tout objet dans un domaine AD a un identifiant de sécurité (SID) unique. Celui-ci est constitué d'une combinaison de l'identifiant de domaine et d'un identifiant relatif. Chaque objet d'un domaine donné a le même identifiant de domaine, donc l'identifiant relatif est ce qui rend les objets uniques. Chaque contrôleur de domaine a un groupe d'ID relatifs à utiliser. Ainsi, lorsqu'il 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 ne se chevauchant pas, chaque RID doit rester unique pour la durée de vie du domaine. Lorsqu'un contrôleur de domaine obtient environ 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 souvent mal compris, à savoir le rôle d'émulateur PDC. Il existe un émulateur PDC par domaine. En cas d'échec de la tentative d'authentification, celle-ci est transmise à l'émulateur PDC. L'émulateur de contrôleur de domaine principal fonctionne comme un "point de départ" si un mot de passe a été mis à jour sur un contrôleur de domaine 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 depuis l'émulateur PDC. Tous les clients synchronisent leur heure à partir du CD auquel ils se sont connectés. Il est important que tout reste à moins de 5 minutes les uns des autres, sinon Kerberos se brise et quand cela se produit, tout le monde pleure.
Il est important de se rappeler que les serveurs sur lesquels ces rôles sont exécutés ne sont pas immuables. Il est généralement trivial de déplacer ces rôles. Ainsi, même si certains pays en font un peu plus que d’autres, s’ils échouent pendant de courtes périodes, tout fonctionnera normalement. S'ils sont indisponibles pendant 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 arrêtez d’appeler vos contrôleurs de domaine par ces anciens noms. :)
Alors, euh ... comment les contrôleurs de domaine partagent-ils des informations s’ils peuvent fonctionner indépendamment les uns des autres?
La réplication, bien sûr . Par défaut, les contrôleurs de domaine appartenant au même domaine sur le même site se répliquent mutuellement leurs données toutes les 15 secondes. 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 un trop grand nombre de connexions échouées, le mot de passe du domaine ou les stratégies de verrouillage sont modifiés, le secret LSA est modifié, le mot de passe est modifié sur le compte d'ordinateur du contrôleur de domaine ou le rôle de maître RID est transféré. à un nouveau DC. Chacun de ces événements déclenchera un événement de réplication immédiat.
Les modifications de mot de passe se situent entre urgent et non urgent et sont traitées de manière unique. Si le mot de passe d'un utilisateur est modifié DC01et qu'un utilisateur tente de se connecter à un ordinateur authentifié DC02avant la réplication, vous vous attendez à ce que cela échoue, n'est-ce pas? Heureusement cela n'arrive pas. Supposons qu'il existe également un troisième contrôleur de domaine ici appelé DC03qui détient le rôle d'émulateur PDC. Lorsque DC01est mis à jour avec le nouveau mot de passe de l'utilisateur, cette modification est immédiatement répliquée sur DC03. Lorsque la tentative d'authentification en cours DC02échoue, DC02transmettez cette tentative d'authentification à DC03, ce qui vérifie qu'elle est effectivement bonne et que la connexion est autorisée.
Parlons de DNS
Le DNS est essentiel au bon fonctionnement de l’AD. La ligne officielle de la fête chez Microsoft 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 haut. Sérieusement. Tenez-vous-en à l'aide des zones DNS intégrées à AD Integrated et utilisez des redirecteurs conditionnels ou globaux pour d'autres zones si vous 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 de lancer DNS et de configurer vos clients pour qu'ils utilisent les deux pour la résolution de noms.
En outre, vous devrez vous assurer que, si vous avez plusieurs contrôleurs de domaine, ils ne s'affichent pas d'abord pour la résolution DNS. Cela peut entraîner 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 être restaurés. Si vous avez deux serveurs DC01 - 10.1.1.1et DC02 - 10.1.1.2leur liste de serveurs DNS doit alors être configurée comme suit:
Serveur: DC01 (10.1.1.1)
DNS principal - 10.1.1.2
DNS secondaire - 127.0.0.1
Serveur: DC02 (10.1.1.2)
DNS principal - 10.1.1.1
DNS secondaire - 127.0.0.1
OK, cela semble compliqué. Pourquoi est-ce que je veux utiliser AD?
Parce qu'une fois que vous savez ce que vous faites, votre vie devient infiniment meilleure. AD permet de centraliser la gestion des utilisateurs et des ordinateurs, ainsi que de centraliser l'accès et l'utilisation des ressources. Imaginez une situation où vous avez 50 utilisateurs dans un bureau. Si vous souhaitez que chaque utilisateur dispose de son propre identifiant de connexion sur chaque ordinateur, vous devez configurer 50 comptes d'utilisateurs locaux sur chaque PC. Avec AD, vous ne devez créer le compte d’utilisateur qu’une seule fois et celui-ci peut se connecter à n’importe quel PC du domaine par défaut. Si vous voulez renforcer la sécurité, vous devrez le faire 50 fois. Une sorte de cauchemar, non? Imaginez également que vous avez un partage de fichiers auquel vous ne voulez que la moitié de ces personnes accèdent. Si vous n'utilisez pas AD, vous devez soit répliquer à la main leur nom d'utilisateur et leur mot de passe sur le serveur pour permettre un accès sans faille, soit vous ' Vous devez créer un compte partagé et donner à chaque utilisateur le nom d'utilisateur et le mot de passe. Un moyen 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 bien 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 de ces unités d'organisation. Par exemple, si vous souhaitez que "Arrêter" ne figure pas dans le menu Démarrer de 500 ordinateurs 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 un objet de stratégie de groupe, vous le liez à l'unité ou aux unités d'organisation appropriées et vous n'avez jamais à y réfléchir à nouveau. Il existe des centaines d'objets de stratégie de groupe pouvant ê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.