Serveur d'impression

Windows Server 2012 R2 Inside Out: Architecture Active Directory – Bien choisir son serveur d impression

Par Titanfall , le 10 août 2019 - 28 minutes de lecture

Comprendre la structure physique d’Active Directory est important pour comprendre le fonctionnement d’un service d’annuaire. Comprendre la structure logique d'Active Directory est important pour l'implémentation et la gestion d'un service d'annuaire. William Stanek explique la structure physique et logique dans ce chapitre de Windows Server 2012 R2 Inside Out: services, sécurité et infrastructure.

  • Architecture physique Active Directory
  • Architecture logique Active Directory

Active Directory est un service de répertoire extensible qui vous permet de gérer efficacement les ressources du réseau. Pour ce faire, un service d’annuaire stocke des informations détaillées sur chaque ressource réseau, ce qui facilite la recherche et l’authentification de base. Pouvoir stocker de grandes quantités d’informations est l’un des principaux objectifs d’un service d’annuaire, mais il faut également organiser les informations de manière à ce qu’elles puissent être facilement recherchées et récupérées.

Active Directory permet la recherche et la récupération d'informations authentifiées en divisant les structures physique et logique de l'annuaire en couches séparées. Comprendre la structure physique d’Active Directory est important pour comprendre le fonctionnement d’un service d’annuaire. Comprendre la structure logique d'Active Directory est important pour l'implémentation et la gestion d'un service d'annuaire.

Architecture physique Active Directory

La couche physique de Active Directory contrôle les fonctionnalités suivantes:

  • Comment accéder aux informations du répertoire
  • Comment les informations de répertoire sont stockées sur le disque dur d'un serveur

Architecture physique Active Directory: une vue de haut niveau

Du point de vue physique ou de la machine, Active Directory fait partie du sous-système de sécurité. (Voir la figure 10-1.) Le sous-système de sécurité s'exécute en mode utilisateur. Les applications en mode utilisateur n'ont pas d'accès direct au système d'exploitation ou au matériel. Cela signifie que les demandes provenant d'applications en mode utilisateur doivent passer par la couche de services exécutifs et doivent être validées avant d'être exécutées.


Figure 10-1

Figure 10-1 Présentation générale de l'architecture Active Directory.

Chaque ressource dans Active Directory est représentée sous la forme d'un objet. Toute personne qui tente d'accéder à un objet doit recevoir une autorisation. Les listes d’autorisations décrivant qui ou quoi peut accéder à un objet sont appelées listes de contrôle d'accès (ACL). Chaque objet de l'annuaire est associé à une liste de contrôle d'accès.

Vous pouvez limiter les autorisations sur une étendue plus large en utilisant la stratégie de groupe. L'infrastructure de sécurité d'Active Directory utilise une stratégie pour appliquer des modèles de sécurité à plusieurs objets regroupés de manière logique. Vous pouvez également configurer des relations de confiance entre des groupes d'objets pour élargir encore la portée des contrôles de sécurité entre des groupes d'objets approuvés nécessitant une interaction. Dans l’optique de haut niveau, c’est ainsi qu’Active Directory fonctionne, mais pour bien comprendre Active Directory, vous devez vous plonger dans le sous-système de sécurité.

Active Directory au sein de l'autorité de sécurité locale

Dans le sous-système de sécurité, Active Directory est un sous-composant de l'autorité de sécurité locale (LSA). Comme le montre la figure 10-2, le LSA comprend de nombreux composants qui fournissent les fonctionnalités de sécurité de Windows Server et garantissent que le contrôle d'accès et l'authentification fonctionnent comme ils le devraient. Non seulement le LSA gère-t-il la politique de sécurité locale, mais il remplit également les fonctions suivantes:

  • Génère des identifiants de sécurité (SID)
  • Fournit le processus interactif pour la connexion
  • Gère l'audit


    Figure 10-2

    Figure 10-2 Sous-système de sécurité Windows Server utilisant Active Directory.

Lorsque vous utilisez le sous-système de sécurité tel qu’il est utilisé avec Active Directory, vous trouvez les trois zones clés suivantes:

Comme vous pouvez le constater, les utilisateurs sont authentifiés avant de pouvoir utiliser le composant du service d'annuaire. L’authentification est gérée en transmettant les informations d’identité de sécurité d’un utilisateur à un contrôleur de domaine. Une fois l'utilisateur authentifié sur le réseau, il peut utiliser des ressources et effectuer des actions en fonction des autorisations accordées à l'utilisateur dans l'annuaire. Au moins, voici comment le sous-système de sécurité Windows Server fonctionne avec Active Directory.

Lorsque vous êtes sur un réseau qui n'utilise pas Active Directory ou que vous vous connectez localement à un ordinateur autre qu'un contrôleur de domaine, le sous-système de sécurité fonctionne comme illustré à la figure 10-3. Ici, le service d'annuaire n'est pas utilisé. Au lieu de cela, l'authentification et le contrôle d'accès sont gérés via le gestionnaire de comptes de sécurité (SAM). Ici, les informations sur les ressources sont stockées dans le SAM, qui est lui-même stocké dans le registre.


Figure 10-3

Figure 10-3 Sous-système de sécurité Windows Server sans Active Directory.

Architecture du service d'annuaire

Comme vous l'avez vu, les demandes entrantes sont transmises via le sous-système de sécurité au composant du service d'annuaire. Le composant de service d'annuaire est conçu pour accepter les demandes de nombreux types de clients. Comme le montre la figure 10-4, ces clients utilisent des protocoles spécifiques pour interagir avec Active Directory.

Figure 10-4

Figure 10-4 Architecture du service d'annuaire.

Protocoles et interfaces client

Le protocole principal pour l'accès Active Directory est LDAP (Lightweight Directory Access Protocol). LDAP est un protocole standard de l’industrie pour l’accès aux répertoires utilisant le protocole TCP / IP (Transmission Control Protocol / Internet Protocol). Active Directory prend en charge les versions 2 et 3 de LDAP. Les clients peuvent utiliser LDAP pour interroger et gérer les informations de l'annuaire, en fonction du niveau des autorisations qui leur ont été accordées, en établissant une connexion TCP à un contrôleur de domaine. Le port TCP par défaut utilisé par les clients LDAP est 389 pour les communications standard et 636 pour SSL.

Active Directory prend en charge la réplication intersite et intrasite via l'interface REPL, qui utilise les appels de procédure distante (RPC) ou le protocole SMTP sur IP (Simple Mail Transfer Protocol sur Internet), en fonction de la configuration de la réplication. Chaque contrôleur de domaine est responsable de la réplication des modifications apportées à l'annuaire sur d'autres contrôleurs de domaine, à l'aide d'une approche multi-maître. L'approche multimaître utilisée dans Active Directory permet d'effectuer des mises à jour de l'annuaire par n'importe quel contrôleur de domaine, puis de les répliquer sur d'autres contrôleurs de domaine.

Pour les clients de messagerie plus anciens, Active Directory prend en charge l'interface MAPI (Messaging Application Programming Interface). MAPI permet aux clients de messagerie d'accéder à Active Directory (utilisé par Microsoft Exchange pour stocker des informations), principalement pour les recherches dans le carnet d'adresses. Les clients de messagerie utilisent les RPC pour établir une connexion avec le service d'annuaire. Le mappeur de points de terminaison RPC utilise les ports UDP 135 et TCP 135. Les clients de messagerie actuels utilisent LDAP au lieu de RPC.

Pour les clients hérités, Active Directory prend en charge l'interface SAM, qui utilise également les RPC. Cela permet aux clients hérités d'accéder au magasin de données Active Directory de la même manière qu'ils accéderaient à la base de données SAM. L'interface SAM est également utilisée lors de certaines activités de réplication.

Agent de répertoire et couche de base de données

Les clients et autres serveurs utilisent les interfaces LDAP, REPL, MAPI et SAM pour communiquer avec le composant de service d'annuaire (Ntdsa.dll) sur un contrôleur de domaine. D'un point de vue abstrait, le composant de service d'annuaire comprend les éléments suivants:

  • Directory System Agent (DSA), qui fournit les interfaces via lesquelles les clients et les autres serveurs se connectent
  • Couche de base de données, qui fournit une interface de programmation d'application (API) pour l'utilisation du magasin de données Active Directory

D'un point de vue physique, le DSA est réellement le composant du service d'annuaire et la couche de base de données réside dans ce dernier. La raison de la séparation des deux est que la couche base de données effectue une abstraction essentielle. Sans cette abstraction, la base de données physique sur le disque ne serait pas protégée contre les applications avec lesquelles le DSA interagit. En outre, la hiérarchie basée sur les objets utilisée par Active Directory ne serait pas possible. Pourquoi? Parce que le magasin de données se trouve dans un fichier de données unique utilisant une structure plate (basée sur l'enregistrement), alors que la couche de base de données est utilisée pour représenter les enregistrements de fichier à plat en tant qu'objets dans une hiérarchie de conteneurs. À la manière d'un dossier pouvant contenir des fichiers et d'autres dossiers, un conteneur est simplement un type d'objet pouvant contenir d'autres objets et d'autres conteneurs.

Chaque objet du magasin de données a un nom relatif au conteneur dans lequel il est stocké. Ce nom est appelé à juste titre celui de l’objet. Nom distinctif relatif (RDN). Le nom complet d’un objet, également appelé objet nom distinctif (DN), décrit la série de conteneurs, du plus haut au plus bas, dont l’objet fait partie.

Pour vous assurer que chaque objet stocké dans Active Directory est véritablement unique, chaque objet a également un identificateur global unique (GUID), qui est généré lors de la création de l'objet. Contrairement au RDN ou au DN d’un objet, qui peut être modifié en renommant un objet ou en le déplaçant vers un autre conteneur, le GUID ne peut jamais être modifié. Le DSA l'assigne à un objet et ne change jamais.

Le DSA est chargé de s'assurer que le type d'informations associé à un objet adhère à un ensemble de règles spécifique. Cet ensemble de règles est appelé le schéma. Le schéma est stocké dans l'annuaire et contient les définitions de toutes les classes d'objet et décrit leurs attributs. Dans Active Directory, le schéma est l'ensemble de règles qui déterminent le type de données pouvant être stockées dans la base de données, le type d'informations pouvant être associées à un objet particulier, les conventions de dénomination des objets, etc.

Le DSA est également responsable de l'application des limitations de sécurité. Pour ce faire, il lit les identificateurs de sécurité sur le jeton d’accès d’un client et les compare aux identificateurs de sécurité d’un objet. Si un client dispose des autorisations d'accès appropriées, il est autorisé à accéder à un objet. Si un client ne dispose pas des autorisations d’accès appropriées, il se voit refuser l’accès.

Enfin, le DSA est utilisé pour lancer la réplication. La réplication est la fonctionnalité essentielle qui garantit que les informations stockées sur les contrôleurs de domaine sont exactes et cohérentes avec les modifications apportées. Sans une réplication appropriée, les données sur les serveurs deviendraient obsolètes et obsolètes.

Moteur de stockage extensible

Active Directory utilise le moteur ESE (Extensible Storage Engine) pour extraire des informations du magasin de données et pour y écrire des informations. ESE utilise un stockage indexé et séquentiel avec un traitement transactionnel, comme suit:

  • Stockage indexé. L'indexation du magasin de données permet à l'ESE d'accéder rapidement aux données sans avoir à chercher dans la base de données entière. De cette manière, l'ESE peut rapidement extraire, écrire et mettre à jour des données.
  • Stockage séquentiel. Stocker séquentiellement les données signifie que l'ESE écrit les données sous forme de flux de bits et d'octets. Cela permet aux données d'être lues et écrites dans des emplacements spécifiques.
  • Traitement transactionnel. Le traitement transactionnel garantit que les modifications apportées à la base de données sont appliquées en tant qu'opérations discrètes pouvant être annulées si nécessaire.

Toutes les données modifiées dans une transaction sont copiées dans un fichier de base de données temporaire. Cela donne deux vues des données en cours de modification: une vue du processus modifiant les données et une vue des données d'origine disponibles pour d'autres processus jusqu'à la finalisation de la transaction. Une transaction reste ouverte tant que les modifications sont en cours de traitement. Si une erreur se produit pendant le traitement, la transaction peut être annulée pour ramener l'objet modifié à son état d'origine. Si Active Directory termine le traitement des modifications sans erreur, la transaction peut être validée.

Comme avec la plupart des bases de données utilisant le traitement transactionnel, Active Directory tient un journal des transactions. Un enregistrement de la transaction est d'abord écrit sur une copie en mémoire d'un objet, puis dans le journal des transactions, et enfin dans la base de données. La copie en mémoire d’un objet est stockée dans le dossier magasin de versions. Le magasin de versions est une zone de mémoire physique (RAM) utilisée pour traiter les modifications. En règle générale, le magasin de versions contient 25% de la RAM physique.

Le journal des transactions sert d'enregistrement de toutes les modifications qui doivent encore être validées dans le fichier de base de données. La transaction est d'abord écrite dans le journal des transactions pour s'assurer que même si la base de données est fermée immédiatement après, la modification n'est pas perdue et peut prendre effet. Pour ce faire, Active Directory utilise un fichier de point de contrôle pour suivre le point jusqu'à lequel les transactions du fichier journal ont été validées dans le fichier de base de données. Une fois qu'une transaction est validée dans le fichier de base de données, elle peut être effacée du journal des transactions.

La mise à jour réelle de la base de données est écrite à partir de la copie en mémoire de l'objet dans le magasin de versions et non à partir du journal des transactions. Cela réduit le nombre d'opérations d'E / S sur disque et permet de s'assurer que les mises à jour peuvent suivre le rythme des modifications. Cependant, lorsque de nombreuses mises à jour sont effectuées, le magasin de versions peut atteindre un point où il est submergé. Cela se produit lorsque le magasin de versions atteint 90% de sa taille maximale. Lorsque cela se produit, ESE interrompt temporairement le traitement des opérations de nettoyage utilisées pour retourner de l'espace après la modification ou la suppression d'un objet de la base de données.

Bien que, dans les versions antérieures de la création d’index Windows Server, puisse affecter les performances du contrôleur de domaine, Windows Server 2012 et Windows Server 2012 R2 vous permettent de différer la création d’index à un moment plus opportun. En reportant la création d'index à un moment précis, plutôt que de créer des index selon vos besoins, vous pouvez vous assurer que les contrôleurs de domaine peuvent effectuer des tâches connexes pendant les heures creuses, réduisant ainsi l'impact de la création d'index. Tout attribut ayant un état d'index différé sera consigné dans le journal des événements toutes les 24 heures. Recherchez les ID d'événement 2944 et 2945. Lorsque les index sont créés, l'ID 1137 est enregistré.

Dans les grands environnements Active Directory, le report de la création d'index est utile pour empêcher les contrôleurs de domaine de devenir indisponibles en raison de la création d'index après la mise à jour du schéma. Avant de pouvoir utiliser la création d'index différée, vous devez activer la fonctionnalité dans le domaine racine de la forêt. Vous faites cela en utilisant le DSHeuristique attribut de l'objet Services d'annuaire pour le domaine. Définissez le dix-huitième bit de cet attribut sur 1. Etant donné que le dixième bit de cet attribut est généralement également défini sur 1 (si l'attribut est défini sur une valeur), l'attribut a normalement la valeur suivante: 000000000100000001. Vous pouvez modifier le paramètre suivant. DSHeuristique attribut utilisant ADSI Edit ou Ldp.exe.

ADSI Edit est un composant logiciel enfichable que vous pouvez ajouter à n’importe quelle console MMC (Microsoft Management Console). Ouvrez une nouvelle console MMC en entrant MMC à l’invite, puis utilisez l’option Ajouter / Supprimer un composant logiciel enfichable du menu Fichier pour ajouter le composant logiciel enfichable ADSI Edit à la console MMC. Vous pouvez ensuite utiliser ADSI Edit pour modifier le DSHeuristique attribuer en effectuant les étapes suivantes:

  1. Maintenez enfoncé ou cliquez avec le bouton droit de la souris sur le nœud racine, puis sélectionnez Se connecter à. Dans la boîte de dialogue Paramètres de connexion, choisissez l'option Sélectionner un contexte de dénomination bien connu. Dans la liste de sélection associée, sélectionnez Configuration (car vous souhaitez vous connecter au contexte de nommage de la configuration pour le domaine), puis appuyez ou cliquez sur OK.
  2. Dans ADSI Edit, naviguez jusqu'au conteneur CN = Directory Service en développant le contexte d'attribution de nom de configuration, le conteneur CN = Configuration, le conteneur CN = Services et le conteneur CN = Windows NT.
  3. Ensuite, maintenez enfoncé ou cliquez avec le bouton droit de la souris sur CN = Directory Service, puis sélectionnez Propriétés. Dans la boîte de dialogue Propriétés, sélectionnez les propriétés de dsHeuristics, puis appuyez sur ou cliquez sur Modifier.
  4. Dans la boîte de dialogue Éditeur d'attribut de chaîne, tapez la valeur souhaitée, telle que 000000000100000001, puis appuyez ou cliquez deux fois sur OK.

Ldp est un utilitaire graphique. Ouvrez LDP en tapant ldp dans la zone de recherche d'applications ou à une invite. Vous pouvez ensuite utiliser Ldp pour modifier le DSHeuristique attribuer en effectuant les étapes suivantes:

  1. Choisissez Connexion dans le menu Connexion, puis connectez-vous à un contrôleur de domaine du domaine racine de la forêt. Une fois que vous vous êtes connecté à un contrôleur de domaine, choisissez Bind dans le menu Connection pour vous lier au domaine racine de la forêt à l'aide d'un compte doté de privilèges d'administrateur d'entreprise.
  2. Ensuite, choisissez Arborescence dans le menu Affichage pour ouvrir la boîte de dialogue Arborescence. Dans la boîte de dialogue Vue arborescente, choisissez CN = conteneur de configuration comme nom distinctif de base à utiliser.
  3. Dans le conteneur CN = Configuration, développez le conteneur CN = Services, développez le conteneur CN = Windows NT, puis sélectionnez le conteneur CN = Directory Service. Ensuite, maintenez enfoncé ou cliquez avec le bouton droit de la souris sur CN = Directory Service, puis sélectionnez Modifier.
  4. Dans la boîte de dialogue Modifier, tapez le nom de l'attribut comme suit: dsHeuristics et la valeur en tant que 000000000100000001.
  5. Si l'attribut existe déjà, définissez l'opération sur Remplacer. Sinon, définissez l'opération sur Ajouter.
  6. Appuyez ou cliquez sur Entrée pour créer une transaction LDAP pour cette mise à jour, puis appuyez ou cliquez sur Exécuter pour appliquer la modification.

Une fois que la modification est répliquée sur tous les contrôleurs de domaine de la forêt, ils reportent automatiquement la création d'index. Vous devez ensuite déclencher la création d'index manuellement en redémarrant les contrôleurs de domaine, qui reconstruisent le cache de schéma et les index différés, ou en déclenchant une mise à jour de schéma pour RootDSE. Dans ADSI Edit, vous pouvez lancer une mise à jour en vous connectant à RootDSE. Pour ce faire, maintenez enfoncé ou cliquez avec le bouton droit de la souris sur le nœud racine, puis sélectionnez Se connecter à. Dans la boîte de dialogue Paramètres de connexion, choisissez l'option Sélectionner un contexte de dénomination bien connu. Dans la liste de sélection associée, sélectionnez RootDSE, puis appuyez ou cliquez sur OK. Dans ADSI Edit, maintenez enfoncé ou cliquez avec le bouton droit de la souris sur le nœud RootDSE, puis sélectionnez Mettre à jour le schéma maintenant.

Pour permettre la récupération d'objet et la réplication des suppressions d'objet, un objet supprimé de la base de données est supprimé logiquement plutôt que physiquement. Le mode de suppression dépend de l'activation ou de la désactivation de la corbeille Active Directory.

Suppression sans corbeille

Lorsque la corbeille Active Directory est désactivée, comme pour les déploiements standard antérieurs à Windows Server 2008 R2, la plupart des attributs de l'objet sont supprimés et Supprimé attribut est défini sur TRUE pour indiquer qu'il a été supprimé. L'objet est ensuite déplacé vers un conteneur d'objets supprimés masqué, dans lequel sa suppression peut être répliquée sur d'autres contrôleurs de domaine. (Voir la figure 10-5.) Dans cet état, l’objet est dit tombstoned. Pour autoriser la réplication de l'état désactivé, sur tous les contrôleurs de domaine, et donc la suppression de toutes les copies de la base de données, attribut appelé tombstoneLifetime est également défini sur l'objet. le tombstoneLifetime attribut spécifie combien de temps l'objet désactivé doit rester dans le conteneur Objets supprimés. La durée de vie par défaut est de 180 jours.

Figure 10-5

Figure 10-5 Cycle de vie d'un objet Active Directory sans Corbeille.

ESE utilise un processus de récupération de place pour supprimer les objets désactivés après expiration de la durée de vie de désactivation, et effectue une défragmentation en ligne automatique de la base de données après la récupération de place. L’intervalle auquel la récupération de place se produit est un facteur de la valeur définie pour le garbageCollPeriod attribut et la durée de vie tombstone. Par défaut, la récupération de place a lieu toutes les 12 heures. Lorsque plus de 5 000 objets désactivés doivent être collectés, l'ESE supprime les 5 000 premiers objets désactivés, puis utilise la disponibilité de la CPU pour déterminer si la récupération de place peut continuer. Si aucun autre processus n'attend le processeur, la récupération de place continue jusqu'à 5 000 objets désactivés dont la durée de vie de désactivation a expiré, et la disponibilité de la CPU est à nouveau vérifiée pour déterminer si la récupération de place peut continuer. Ce processus se poursuit jusqu'à ce que tous les objets désactivés dont la durée de vie de désactivation a expiré soient supprimés ou qu'un autre processus ait besoin d'accéder à la CPU.

Suppression avec Corbeille

Lorsque la corbeille Active Directory est activée en tant qu'option avec Windows Server 2008 R2 et versions ultérieures, les objets ne sont pas étonnés lorsqu'ils ont été initialement supprimés et leurs attributs non supprimés. Au lieu de cela, le processus de suppression se déroule par étapes.

Dans la première étape de la suppression, l’objet est dit logiquement supprimé. Ici, l'objet Supprimé attribut est défini sur TRUE pour indiquer qu'il a été supprimé. L'objet est ensuite déplacé, avec ses attributs et son nom préservés, dans un conteneur Objets supprimés masqué, dans lequel sa suppression peut être répliquée sur d'autres contrôleurs de domaine. (Voir la figure 10-6.) Pour permettre à l'état supprimé logiquement d'être répliqué sur tous les contrôleurs de domaine, et ainsi supprimé de toutes les copies de la base de données, un attribut appelé ms-DeletedObjectLifetime est également défini sur l'objet. le ms-DeletedObjectLifetime attribut spécifie combien de temps l'objet supprimé logiquement doit rester dans le conteneur Objets supprimés. La durée de vie par défaut des objets supprimés est de 180 jours.

Figure 10-6

Figure 10-6 Cycle de vie d'un objet Active Directory avec la corbeille.

Lorsque la durée de vie de l'objet supprimé expire, Active Directory supprime la plupart des attributs de l'objet, modifie le nom distinctif afin que le nom de l'objet ne puisse pas être reconnu, et définit le tombstoneLifetime attribut. Cela détruit efficacement l'objet (et le processus est le même que le processus de désactivation hérité).

L’objet recyclé reste dans le conteneur Objets supprimés jusqu’à expiration de sa durée de vie. Il est dit qu’il se trouve dans le recyclé Etat. La durée de vie par défaut est de 180 jours.

Comme pour la suppression sans la corbeille, l'ESE utilise un processus de récupération de place pour éliminer les objets désactivés après expiration de la durée de vie de la désactivation. Ce processus de récupération de place est identique à celui décrit précédemment.

Architecture du magasin de données

Après avoir examiné les composants du système d'exploitation prenant en charge Active Directory, l'étape suivante consiste à voir comment les données de l'annuaire sont stockées sur les disques durs d'un contrôleur de domaine. Comme le montre la figure 10-7, le magasin de données comprend un fichier de données primaire et plusieurs autres types de fichiers associés, notamment des fichiers de travail et des journaux de transactions.

Figure 10-7

Figure 10-7 Le magasin de données Active Directory.

Ces fichiers sont utilisés comme suit:

  • Fichier de données primaire (Ntds.dit). Fichier de base de données physique contenant le contenu du magasin de données Active Directory
  • Fichier de point de contrôle (Edb.chk). Fichier de point de contrôle qui indique jusqu'à quel point les transactions dans le fichier journal ont été validées dans le fichier de base de données.
  • Données temporaires (Tmp.edb). Espace de travail temporaire pour le traitement des transactions
  • Fichier journal principal (Edb.log). Fichier journal principal contenant un enregistrement de toutes les modifications qui doivent encore être validées dans le fichier de base de données
  • Fichiers journaux secondaires (Edb00001.log, Edb00002.log, …). Fichiers journaux supplémentaires utilisés au besoin
  • Réserver des fichiers journaux (EdbRes00001.jrs, EdbRes00002.jrs, …). Fichiers utilisés pour réserver de l'espace pour des fichiers journaux supplémentaires si le fichier journal principal est saturé

Le fichier de données primaire contient trois tables indexées:

  • Table de données Active Directory. La table de données contient un enregistrement pour chaque objet du magasin de données, qui peut inclure des conteneurs d'objet, les objets eux-mêmes et tout autre type de données stockées dans Active Directory.
  • Table de liens Active Directory. La table de liens est utilisée pour représenter les attributs liés. Un attribut lié est un attribut qui fait référence à d'autres objets dans Active Directory. Par exemple, si un objet contient d'autres objets (c'est-à-dire qu'il s'agit d'un conteneur), les liens d'attribut sont utilisés pour pointer vers les objets du conteneur.
  • Table des descripteurs de sécurité Active Directory. La table des descripteurs de sécurité contient les descripteurs de sécurité hérités pour chaque objet du magasin de données. Windows Server utilise cette table afin que les descripteurs de sécurité hérités ne doivent plus être dupliqués sur chaque objet. Au lieu de cela, les descripteurs de sécurité hérités sont stockés dans cette table et liés aux objets appropriés. Cela rend les mécanismes d'authentification et de contrôle Active Directory très efficaces.

Pensez à la table de données comme ayant des lignes et des colonnes; l'intersection d'une ligne et d'une colonne est un champ. Les lignes de la table correspondent aux instances individuelles d’un objet. Les colonnes de la table correspondent aux attributs définis dans le schéma. Les champs de la table ne sont renseignés que si un attribut contient une valeur. Les champs peuvent être de longueur fixe ou variable. Si vous créez un objet et ne définissez que 10 attributs, seuls ces 10 attributs contiendront des valeurs. Certaines de ces valeurs peuvent avoir une longueur fixe, d'autres une longueur variable.

Les enregistrements de la table de données sont stockés dans des pages de données ayant une taille fixe de 8 kilo-octets (Ko, ou 8 192 octets). Chaque page de données comporte un en-tête de page, des lignes de données et un espace libre pouvant contenir des décalages de lignes. L'en-tête de page utilise les 96 premiers octets de chaque page, ce qui laisse 8 096 octets pour les décalages de données et de lignes.

Les décalages de lignes indiquent l'ordre logique des lignes sur une page, ce qui signifie que le décalage 0 correspond à la première ligne de l'index, le décalage 1 à la deuxième ligne, etc. Si une ligne contient de longues données de longueur variable, il est possible que les données ne soient pas stockées avec le reste des données de cette ligne. Au lieu de cela, Active Directory peut stocker un pointeur de 8 octets sur les données réelles, qui sont stockées dans une collection de pages de 8 Ko non nécessairement écrites de manière contiguë. De cette manière, un objet et toutes ses valeurs d'attribut peuvent être beaucoup plus grands que 8 Ko.

Le fichier journal principal a une taille fixe de 10 mégaoctets (Mo). Lorsque ce journal est plein, Active Directory crée des fichiers journaux supplémentaires (secondaires) selon les besoins. Les fichiers journaux secondaires sont également limités à une taille fixe de 10 Mo. Active Directory utilise les fichiers journaux de réservation pour réserver de l'espace sur le disque aux fichiers journaux à créer. Plusieurs fichiers de réserve étant déjà créés, cela accélère le processus de journalisation transactionnelle lorsque des journaux supplémentaires sont nécessaires.

Par défaut, le fichier de données principal, les fichiers de travail et les journaux de transactions sont tous stockés au même endroit. Sur le volume système d’un contrôleur de domaine, vous trouverez ces fichiers dans le dossier% SystemRoot% NTDS. Bien qu'il s'agisse des seuls fichiers utilisés pour le magasin de données, Active Directory utilise d'autres fichiers. Par exemple, les fichiers de stratégie et d'autres fichiers, tels que les scripts de démarrage et d'arrêt utilisés par le DSA, sont stockés dans le dossier% SystemRoot% Sysvol.

Click to rate this post!
[Total: 0 Average: 0]

Commentaires

Laisser un commentaire

Votre commentaire sera révisé par les administrateurs si besoin.