L’Active Directory et les notions de SID, RID et SID History
Sommaire
I. Présentation
Dans ce tutoriel, nous allons étudier la notion de SID dans un contexte Active Directory ! En effet, nous allons étudier les SID associés aux objets d'un annuaire Active Directory, que ce soit des utilisateurs, des ordinateurs, des groupes, etc... Ce sujet nous donnera également l'occasion d'aborder la notion de RID, de Maître RID et de SID History.
Cet article est une suite au premier article sur les SID, dont voici le lien :
II. L'Active Directory et l'attribut objectSid
Dans l'Active Directory, au même titre que sur une machine Windows, il y a cette notion de SID (Security IDentifier), c'est-à-dire d'identifiant de sécurité unique. Ainsi, chaque objet de l'Active Directory aura un SID unique qui sera stocké dans l'attribut "objectSid" : si vous vous posiez la question "Où sont stockés les SIDs dans l'Active Directory ?", vous avez la réponse ! Le SID est généré lors de la création d'un objet.
Pour identifier un objet, l'Active Directory utilisera le SID plutôt que le nom : si vous renommez un objet, l'Active Directory sera toujours en mesure de l'identifier, car le SID reste le même pendant toute la vie d'un objet. Le SID est utilisé pour faire référence à un objet dans les ACL, que ce soit pour les permissions de l'annuaire lui-même ou les permissions sur des fichiers et répertoires.
À partir des propriétés d'un objet, via l'onglet "Éditeur d'attributs", nous pouvons obtenir le SID d'un objet. Voici un exemple avec un utilisateur :
Pour gagner du temps, nous pouvons utiliser PowerShell pour obtenir la liste de tous les utilisateurs avec leur nom et leur SID.
Get-ADUser -Filter * | Select-Object Name, SIDVoici un exemple :
Nous pouvons faire la même chose avec les ordinateurs, les groupes de sécurité, etc.
Get-ADComputer -Filter * | Select-Object Name, SID
Get-ADGroup -Filter * | Select-Object Name, SIDTous les SID ont une partie commune, notamment le préfixe "S-1-5-21-" qui est suivi par un identifiant de domaine. Ici, tous les objets appartiennent au même domaine, donc l'identifiant de domaine est le même. A la fin, il s'agit du RID (Relative IDentifier). Dans l'annuaire Active Directory, le compte "Administrateur" de base (Builtin) a toujours le RID 500.
Justement, intéressons-nous à cette notion de RID...
III. L'Active Directory et le rôle FSMO de Maître RID
Un environnement Active Directory est constitué d'un ou plusieurs contrôleurs de domaine. Chaque contrôleur de domaine est susceptible de posséder un ou plusieurs rôles FSMO afin d'être le "maître" pour la réalisation de certaines tâches sensibles. Parmi ces 5 rôles FSMO, il y a le rôle de "Maître RID" qui est directement lié à la notion de SID.
Si l'on prend deux objets d'un même annuaire Active Directory, la seule valeur qui diffère, c'est le RID. De ce fait, le RID est une valeur ultra-importante puisque c'est elle qui va permettre de s'assurer que chaque SID est unique.
S-1-5-21-602238038-4219226198-3932521878-1103
S-1-5-21-602238038-4219226198-3932521878-1113
S-1-5-21-602238038-4219226198-3932521878-1192Dans un domaine Active Directory, l'attribution des RID est gérée par le contrôleur de domaine qui détient le rôle FSMO de "Maître RID" ! Que va-t-il faire ? Il va distribuer un bloc de 500 RIDs différents à chaque contrôleur de domaine (en lecture/écriture) de manière à ce que chaque DC puisse créer de nouveaux objets tout en s'assurant qu'il n'y ait pas de SID en doublon. A chaque fois, le RID sera incrémenté de "1" au fur et à mesure que le DC consomme son bloc de RID.
Sachez que dans certains cas, il peut s'avérer utile d'invalider le bloc RID d'un contrôleur de domaine pour éviter les doublons : on peut se retrouver dans cette situation lors de la restauration d'un contrôleur de domaine à un état antérieur.
Remarque : bien que 500 soit la valeur par défaut, la taille du bloc est personnalisable via le Registre Windows. Il faut éditer la valeur "RID Block Size" située dans la clé "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\RID Values". La limite étant de 15 000.
Dans un annuaire Active Directory, il y a une limite sur le nombre de RID ! Pour savoir combien de RID sont attribués et combien il en reste, vous pouvez utiliser la commande dcdiag.exe de cette façon :
Dcdiag.exe /TEST:RidManager /v | find /i "Available RID Pool for the Domain"Dans l'exemple ci-dessous, le résultat de la commande indique qu'il y a 1 600 RID attribués et qu'il reste 1 073 741 823 de RID attribuables (plus d'un milliard !)
Pour en savoir plus sur l'émission des RIB, consultez cette documentation officielle :
IV. L'Active Directory et le SID History
Dans l'Active Directory, chaque objet contient un attribut un peu spécial nommé "sIDHistory" : SID History, que l'on pourrait traduire par "Historique des SID". En principe, cet attribut est vide (<non défini>) comme le montre l'exemple ci-dessous, mais ce n'est pas toujours le cas. Pourquoi ?
L'attribut associé à la notion de SID History a été introduit de manière à faciliter la migration des objets Active Directory d'un domaine vers un autre. L'outil Microsoft "ADMT" (Active Directory Migration Tool) est fréquemment utilisé pour les migrations de ce type (bien que vieillissant, il continue de rendre bien des services).
Comment fonctionne le SID History ?
Lorsqu'un utilisateur migre d'un domaine A vers un domaine B, il hérite d'un nouveau SID dans le nouveau domaine. De ce fait, avec son nouveau compte, cet utilisateur perd l'accès à toutes les ressources de l'ancien domaine Active Directory ! En phase de migration/transition, ceci peut s'avérer problématique. C'est là que l'attribut sIDHistory intervient. En stockant dans l'attribut "sIDHistory" du nouveau compte le SID de l'utilisateur dans l'ancien domaine, il est possible de faire le lien entre les deux objets dans les deux domaines et de conserver l'accès aux ressources pendant la phase de migration. Ce mécanisme est pratique pour les utilisateurs et les groupes de sécurité.
S'il doit être utilisé dans le cadre d'un projet de migration, le SID History doit être utilisé avec parcimonie et de façon temporaire, car ceci représente un risque : si l'attribut sIDHistory d'un utilisateur fait référence au SID d'un compte avec des privilèges élevés (Admins du domaine, par exemple), ceci ouvre des portes...!
La bonne nouvelle : par défaut, l'utilisation du SID History est désactivée (ceci faisant référence au SID Filtering). Mais, il n'est pas rare que cette "fonctionnalité" reste activer pendant beaucoup trop longtemps après une migration... L'outil "netdom" sert à activer/désactiver le SID History.
V. Conclusion
Suite à la lecture de cet article, vous en savez beaucoup plus sur les notions de SID, de RID et de SID History dans un environnement Active Directory ! C'est une notion importante et à connaître.
