Un guide des attributs liés d'Active Directory
Feb 20, 2017
L’attribut lié d’Active Directory est un type spécial d’attribut utilisé pour décrire les relations entre les objets. Cet article explique ce que sont les attributs liés et comment ils fonctionnent.
Contenu connexe sélectionné :
Qu'est-ce qui fait qu'un attribut est un attribut lié ?
Chaque attribut dans Active Directory est défini par un objet AttributeSchema dans la partition du schéma Active Directory. Les objets AttributeSchema qui définissent les attributs liés sont les seuls objets de schéma qui possèdent un attribut LinkID rempli. Par conséquent, identifier tous les attributs liés dans un domaine est aussi simple que d'utiliser PowerShell pour rechercher dans le schéma les objets avec un LinkID rempli, comme ceci :
Get-ADObject -SearchBase (Get-ADRootDSE).SchemaNamingContext -LDAPFilter "(LinkID=*)"
Les attributs liés existent généralement par paires, un lien direct et un lien retour, qui sont définis par la valeur de l'attribut LinkID :
- Lien direct — La valeur de LinkID est toujours un entier positif pair.
- Lien retour — La valeur de LinkID est toujours un entier impair positif ; en fait, c'est la valeur du LinkID du lien direct associé plus un.
Les attributs avec les valeurs de LinkID les plus petites sont l'attribut Member et l'attribut MemberOf, qui sont utilisés pour suivre l'appartenance à un groupe dans Active Directory. Modifions donc notre script PowerShell pour limiter la sortie à juste ces deux attributs :
La sortie nous indique plusieurs faits importants concernant ces deux attributs :
- La valeur LinkID de l'attribut Member est 2, ce qui est un entier pair. Cela signifie que l'attribut Member est un lien direct.
- La valeur LinkID de l'attribut MemberOf est 3, ce qui est un nombre impair. Cela signifie que l'attribut MemberOf est un lien retour.
- La valeur LinkID du lien retour MemberOf est la valeur LinkID du lien direct attribut Member augmentée d'un (3 = 2 + 1). Cela signifie que l'attribut Member et l'attribut MemberOf sont des attributs liés associés.
Un script PowerShell légèrement différent peut être utilisé pour récupérer directement le nom d'un attribut lié associé à un lien direct ou un lien inverse, bien qu'il ne vous indique pas explicitement si l'attribut est un lien direct ou un lien inverse. Vous devriez examiner la valeur LinkID et le déterminer par vous-même.
Comment fonctionnent les attributs liés à Active Directory ?
Maintenant que nous avons défini ce que sont les attributs liés et comment les identifier, il est temps d'explorer leur comportement.
Les attributs liés stockent des informations sur une relation entre deux objets, contrairement aux attributs conventionnels d'Active Directory, qui stockent des informations sur un objet. Cette différence fonctionnelle se reflète dans le fait qu'Active Directory stocke les valeurs des attributs liés différemment de celles des autres attributs.
Comment les attributs liés sont stockés
Les données d'Active Directory sont stockées dans le fichier de base de données ntds.dit. Les valeurs des attributs conventionnels sont stockées dans une table appelée datatable. Les attributs liés ont leur propre table dédiée, nommée de manière appropriée link_table. Si nous jetons un coup d'œil à l'intérieur d'une capture instantanée du fichier de base de données ntds.dit de mon laboratoire, nous pouvons voir comment Active Directory stocke les valeurs des attributs liés :
Les références d'objet dans la link_table utilisent une balise de nom distinctif d'objet (DNT), qui est en fait la clé primaire interne des enregistrements dans la datatable ntds.dit. Cela empêche que des modifications apportées au nom distinctif d'un objet nécessitent une mise à jour des entrées associées de la link_table.
La capture d'écran met en évidence trois champs importants dans le link_table :
- link_DNT — Référence à un objet de lien direct.
- backlink_DN — Une référence à l'objet de lien retour associé.
- link_base — Une référence au LinkID de l'attribut de lien direct. Ce champ utilise la valeur LinkID du lien direct pour identifier la relation suivie entre les deux objets (bien que, comme vous pouvez le voir dans la capture d'écran, les valeurs dans le tableau sont en réalité la valeur de LinkID divisée par 2).
Conséquences pratiques de cette approche de stockage des attributs liés
Bien que cette approche de stockage puisse paraître un peu étrange, c’est en réalité une conception géniale qui entraîne des conséquences pratiques importantes :
- Les valeurs de lien direct sont stockées ; les valeurs de lien inverse sont construites. C'est de loin le concept le plus important à retenir de cette discussion : Les liens inverses ne stockent pas réellement d'informations. Puisqu'une association entre deux objets est une entité unique, Active Directory n'a pas besoin de stocker plus d'une copie d'une association. Lorsqu'un lien direct est interrogé, Active Directory peut simplement retourner les entrées de link_table où le DNT de l'objet interrogé correspond à la valeur dans le champ link_DNT et le LinkID du lien direct correspond à la valeur dans le champ link_base. Lorsqu'un lien inverse est interrogé, Active Directory peut calculer ses valeurs en retournant les entrées de link_table où le DNT de l'objet interrogé correspond à la valeur dans le champ backlink_DNT et le LinkID du lien direct associé (calculé en soustrayant 1 du LinkID du lien inverse) correspond à la valeur dans le champ link_base.
- Les valeurs de lien direct sont inscriptibles ; les valeurs de lien inverse sont en lecture seule. Une fois que vous savez qu'Active Directory stocke uniquement les valeurs des liens directs, cela semble probablement évident. Cependant, cela a une conséquence importante : lorsqu'un attribut lié est modifié, Active Directory met à jour le lien direct, ce qui modifie l'objet possédant ce lien. Le lien inverse, possédant une valeur construite en lecture seule, ne peut jamais être modifié, donc l'objet possédant le lien inverse n'est pas modifié non plus.
Pour illustrer pourquoi ceci est important, considérons l'ajout d'un utilisateur à un groupe. Cette mise à jour modifie uniquement l'attribut Member du groupe ; l'attribut MemberOf de l'utilisateur n'est pas modifié. Puisque l'objet groupe a subi un changement matériel, les champs de métadonnées qui reflètent ce changement (par exemple, les attributs « ModifyTimeStamp » et « WhenChanged ») sont mis à jour. Ces mêmes champs de métadonnées ne sont pas mis à jour sur l'objet utilisateur car, même si son attribut MemberOf retournera désormais une valeur différente, l'attribut MemberOf lui-même n'a pas été modifié. - Les liens directs sont obligatoires ; les liens inverses sont facultatifs. Certains articles sur les attributs liés affirment que les attributs liés ont toujours à la fois un lien direct et un lien inverse. Bien que cela soit souvent vrai, la présence d'un lien inverse n'est pas strictement nécessaire. En fait, si nous utilisons PowerShell pour récupérer les paires d'attributs liés, nous pouvons voir que chaque lien direct dans mon laboratoire n'a pas forcément un lien inverse associé :
Avantages de cette approche pour stocker des attributs liés
Vous souvenez-vous comment j'ai mentionné que la manière dont les attributs liés sont stockés est assez brillante ? L'approche d'Active Directory pour stocker les valeurs d'attributs liés offre en réalité deux avantages vraiment conséquents.
Tout d'abord, le stockage uniquement des valeurs de liens directs et leur utilisation pour calculer les valeurs de liens inverses associées réduit la taille de la base de données Active Directory.
L'autre avantage clé, qui est un peu moins évident, découle du fait que Active Directory stocke chaque association individuellement. Puisque chaque association d'un lien direct a sa propre entrée dans la link_table, chaque entrée peut maintenir son propre Numéro de Séquence de Mise à jour (USN). Ce comportement est appelé Réplication de Valeurs Liées (LVR) et permet à Active Directory de répliquer chaque association individuellement. Par exemple, si vous ajoutez un utilisateur à un groupe de 100 membres existants, seule l'entrée pour l'utilisateur nouvellement ajouté est répliquée. Cela peut réduire considérablement le volume de réplication nécessaire pour propager les modifications aux attributs liés.
Fait bonus
Avant de conclure tout cela, il y a un autre comportement qui mérite d'être mentionné : Les valeurs d'attributs liés sont supprimées des objets supprimés à moins que la corbeille AD ne soit activée. Lorsqu'un objet possédant un attribut lié est supprimé, même si Active Directory maintient l'objet lui-même pendant un certain temps sous forme de fantôme, les entrées associées de la table de liens sont également supprimées. L'activation de la Active Directory Recycle Bin modifie ce comportement et conserve les entrées associées de la table de liens pendant toute la durée de la période de fantôme de l'objet supprimé.
Conclusion
Parce que les attributs liés à Active Directory sont stockés différemment des autres attributs d'Active Directory, ils se comportent différemment. Cela est particulièrement vrai pour les attributs de lien retour. Si vous ne devez retenir qu'une seule chose de cet article, ce doit être le fait que les liens retour sont des attributs construits — leurs valeurs ne sont pas stockées directement et, en conséquence, ils ne se comportent vraiment pas du tout comme les autres attributs, surtout en ce qui concerne les mises à jour. Active Directory fait généralement un très bon travail pour dissimuler ses comportements en coulisse afin de garantir une expérience utilisateur cohérente, mais comprendre ces différences sous-jacentes concernant les attributs et leurs conséquences peut prévenir des problèmes.
Comment Netwrix peut aider
Sécurisez votre Active Directory de bout en bout avec la solution de sécurité Active Directory de Netwrix. Elle vous permettra de :
- Découvrez les risques de sécurité dans Active Directory et priorisez vos efforts d'atténuation.
- Renforcez les configurations de sécurité à travers votre infrastructure informatique.
- Détectez et contenez rapidement même les menaces avancées, telles que les attaques DCSync et Golden Ticket.
- Répondez instantanément aux menaces connues avec des options de réponse automatisées.
Minimisez les perturbations commerciales avec une récupération rapide d'Active Directory.
Partager sur
En savoir plus
À propos de l'auteur
Joe Dibley
Chercheur en sécurité
Chercheur en sécurité chez Netwrix et membre de l'équipe de recherche en sécurité de Netwrix. Joe est un expert en Active Directory, Windows et une grande variété de plateformes logicielles d'entreprise et de technologies, Joe étudie les nouveaux risques de sécurité, les techniques d'attaque complexes, ainsi que les atténuations et détections associées.
En savoir plus sur ce sujet
Lois sur la confidentialité des données par État : Différentes approches de la protection de la vie privée
Exemple d'analyse des risques : Comment évaluer les risques
Le Triangle CIA et son application dans le monde réel
Qu'est-ce que la gestion des documents électroniques ?
Analyse quantitative des risques : Espérance de perte annuelle