Qu’est-ce que LVR?

valeurs liées entre des objets dans l’AD. Les objets présents dans l’AD sont liés de nombreuses manières : l’exemple le plus connu est le lien maintenu pour stocker la relation entre des objets utilisateurs et groupes.

Comme le montre la figure 1, chaque objet groupe a un attribut appelé member qui fait référence au DN (distinguished name) des membres du groupe (comme des utilisateurs, ordinateurs ou autres groupes), et chaque objet utilisateur a un attribut appelé memberOf qui fait référence aux DN des groupes dont l’utilisateur est membre. Dans mon exemple, John dans l’OU (organizational unit) de OU-Users est un membre de MyGroup dans l’OU OU-Groups. Bien que vous puissiez visualiser les DN contenus dans l’attribut membre d’un groupe quand on utilise des outils LDAP tels que adsiedit.msc ou ldp.exe, les DN ne sont pas concrètement utilisés pour stocker les liens dans l’AD. S’ils l’étaient, vous auriez du mal à renommer ou à déplacer des objets, parce que ces activités changent aussi le DN d’un objet. En réalité, la base de données d’AD est constituée d’une table de données et d’une table de liens.

Tous les objets de tous les contextes de nommage hébergés par un DC spécifique sont stockés dans la table de données, en même temps que leurs DN et un identificateur unique appelé DNT (distinguished name tag), un entier non signé de 32 bits qui n’est pas réutilisable. Pour stocker des liens (références) entre des objets, la table de liens n’utilise que les DNT des objets, lesquels sont ensuite résolus vers le DN correct de l’objet, lorsqu’on lit l’attribut lié respectif via LDAP. Cette méthode maintient essentiellement l’intégrité référentielle des objets et leurs liens respectifs. Pour référencer des relations parent-enfant telles que nécessaires pour la hiérarchie OU, AD utilise une colonne appelée PDNT (parent distinguished name tag) dans la table de données.

On s’en doute, le PDNT contient le DNT du parent de l’objet. La figure 2 est un exemple simplifié des tables de bases de données d’AD, montrant que l’utilisateur John est membre du groupe MyGroup. En y regardant de plus près, vous verrez que Mary appartient aussi à ce groupe et qu’elle est le manager de John. Les deux liens qui constituent la paire de liens présentent une différence importante : seul le lien avant (dans mon exemple, l’attribut membre d’un groupe) peut être édité par des administrateurs, et seul ce lien est répliqué sur les autres DC dans le domaine ou la forêt. Le lien arrière (memberOf dans mon exemple) est possédé et maintenu par chaque DC individuellement et n’est pas répliqué. Je reviendrai sur ce détail important quand il sera question du processus de reprise.

Le snap-in Microsoft Management Console (MMC) Active Directory Users and Computers est quelque peu trompeur, parce qu’il vous permet d’ouvrir les propriétés d’un objet utilisateur, puis d’ajouter un groupe à l’utilisateur via l’onglet MemberOf. En réalité, les actions menées dans cette UI mettent à jour le lien avant de la paire de valeurs liées (c’est-à-dire l’attribut membre du groupe respectif) et le DC crée le lien arrière à partir du groupe vers l’attribut MemberOf de l’utilisateur, comme cette UI le montre. Cela explique aussi pourquoi un administrateur n’a pas besoin de permission spéciale pour gérer un utilisateur pour l’ajouter à un groupe dans l’AD.

Au lieu de cela, des permissions d’écriture sur l’attribut membre du groupe sont nécessaires. Dans le contexte de la reprise d’AD, les liens entre des utilisateurs et des groupes sont plus importants pour nous, parce qu’ils ont pour fonction d’accorder ou de révoquer l’accès aux ressources d’une infrastructure. Il faut comprendre un autre point important : l’AD fait la différence entre les attributs monovaleurs et multivaleurs. Il n’est pas étonnant que l’attribut membre du groupe et l’attribut MemberOf de l’utilisateur soient multivaleurs. C’est l’assurance qu’un utilisateur peut être un membre de nombreux groupes et qu’un groupe peut avoir de multiples utilisateurs (et d’autres objets) comme membres.