[Active Directory] – Comprendre la structure des SIDs dans le monde Microsoft

Dans le monde Windows, chaque objet déclaré et connu par le service d’annuaire de Microsoft (Active Directory) ou le système d’exploitation Windows est identifié dans la plupart des cas par un identifiant de sécurité (SID – Security IDentifier).

Afin de mieux comprendre le rôle de cet identifiant, il est important de comprendre auparavant ce qu’est une « entité principale de sécurité » – drôle de terme en français! (Security Principal dans la terminologie Active Directory).

 

  • Que sont les entités principales de sécurités (Security Principals)?

Une entité principale de sécurité est une objet qui peut avoir un identifiant de sécurité (SID), c’est-à-dire toute entité qui pourra être authentifiée par le système d’exploitation (utilisateur, ordinateur, groupe, etc.)

Ce sont les fondations pour contrôler l’accès aux ressources de votre environnement Windows (fichiers et dossiers par exemple)

 

  • Comment définir le terme SID?

Un SID (Security IDentifier) est une représentation numérique d’une entité principal de sécurité, donc d’un compte utilisateur, d’un compte d’ordinateur, d’un groupe, etc.

Lorsque vous accordez à un utilisateur, un groupe ou un service le droit d’accéder à des ressources, le système d’exploitation met à jour le SID représentant l’objet Active Directory et ses permissions définies dans l’ACL (Access Control List).

 

  • Comment obtenir le SID d’un objet Active Directory?

Dans Active Directory, le SID de l’objet est renseigné par l’attribut objectSid.

  •   Depuis la console Active Directory Users and Computers, dans le menu « View » cliquer sur « Advanced Features« . Ensuite, allez dans les propriétés de l’objet désiré et cliquez sur l’onglet « Attribute Editor« , vous trouverez le SID de l’objet dans le champ ObjectSid

 

  •  Grâce à l’outil « psgetsid » de la suite Microsoft SysInternals (http://technet.microsoft.com/en-us/sysinternals/bb897417.aspx), placez-vous en console DOS dans le répertoire des outils SysInternals et tapez psgetsid sAMAccountName. A noter que l’outil fonctionne dans les deux sens, en fournissant l’attribut sAMAccountName de l’objet pour obtenir son SID ou en référençant la valeur de l’attribut objectsid pour afficher le nom de l’objet!

 

 

  • Comment est composé la structure d’un identifiant de sécurité (SID)?

Un SID inclut des composants qui fournissent des informations sur la structure et les composants qui identifient un objet (rapport objet/droits accordés). Il est constitué des composants suivants:      

  • Les SID commence toujours avec le littéral « S »
  • Le niveau de révision de la structure SID (qui actuellement est toujours 1)
  • La valeur des différentes autorités d’identificateurs sur 48 bits qui permet d’identifier l’émetteur du SID.
  • Un nombre variable de sous-autorité (ou RID – Relative IDentifier) des valeurs qui identifient l’objet par rapport à l’autorité qui a émis le SID.

soit, S-1-IdentifierAuthority-SubAuthority1-SubAuthority2-…-SubAuthorityN

ou encore, S-R-I-S – dans cette notation, le caractère littéral « S » identifie le SID lui-même, R est le niveau de révision, I est la valeur identificateurautorité, et S est une ou plusieurs valeurs de sous-autorités.

Un bon exemple est toujours concret pour comprendre une théorie complexe 😉 Pour cela, prenons le SID d’un compte bien connu, celui du groupe « Administrateurs » local d’une machine fonctionnant sous Windows. Son SID est,

S-1-5-32-544

S = Identifiant brut du SID  / 1 = Niveau de révision de la structure SID / 5 = Valeur de l’autorité identificateur (SECURITY_NT_AUTHORITY) / 32 = Valeur de la première sous-autorité (SECURITY_BUILTIN_DOMAIN_RID) / 544 = Valeur de la seconde sous-autorité (DOMAIN_ALIAS_RID_ADMINS).

 

  • Quelles sont les autorités primaires des SIDs?

0 – SECURITY_NULL_SID_AUTHORITY – valeur définie quand l’autorité identifiant l’objet est inconnu (état unknown) – S-1-0-0

1 – SECURITY_WORLD_SID_AUTHORITY – utilisé pour construire les SIDs qui représentent tous les utilisateurs. Par exemple, le SID du groupe « Everyone » est S-1-1-0, créé en ajoutant le WORLD RID(0) sélectionnant ainsi tous les utilisateurs de cette autorité – S-1-1-0

2 – SECURITY_LOCAL_SID_AUTHORITY – utilisé pour construire les SIDs représentant les utilisateurs qui s’authentifient sur un ordinateur physique – S-1-2-0

3 – SECURITY_CREATOR_SID_AUTHORITY – utilisé pour construire les SIDs qui représentent le créateur (CREATOR) ou propriétaire (OWNER) d’un objet. Le CREATOR OWNER SID est S-1-3-0, créé en ajoutant le CREATOR OWNER RID (0) à cette autorité. Si S-1-3-0 est utilisé dans une ACL avec héritage, il sera remplacé par le SID du propriétaire (OWNER) des objets enfant qui héritent de cette ACL. S-1-3-1 sera alors le CREATOR GROUP SID – S-1-3-0

5 – SECURITY_NT_AUTHORITY – utilisé par le système d’exploitation lui-même. Les SIDs qui commencent par S-1-5 sont émis par Windows (base SAM – Security Account Manager) ou un domaine Active Directory (AD DS). La plupart des SID que vous verrez commenceront avec S-1-5 – S-1-5-0

 

  • Quelles sont les autorités secondaires des SIDs?

Une fois que l’identifiant de sécurité de l’objet  se soit vu attribué son autorité compétente (voir le point « Quelles sont les valeurs des autorités d’identificateurs SID?« ), c’est au tour des sous-autorités d’intervenir dans la construction du SID. Le dernier d’entre eux est appelé identificateur relatif (RID – Relative IDentifier) et est l’identifiant de l’entité de sécurité unique dans le domaine où le SID a été défini. Essayons de clarifier cette dernière phrase par un petit exemple en considérant le SID ci-dessous,

S-1-5-21-1534169462-1651380828-111620651-500

Comme vous l’avez vu, le SID commence par S-1-5, indiquant qu’il a été émis par Windows NT (SECURITY_NT_AUTHORITY). La première sous-autorité est 21S-1-5-21(0x15 en hexadécimal). Le 21 signifie que le SID Windows NT n’est pas assuré d’être universellement (c’est-à-dire totalement) unique. Il sera unique dans le domaine de son émission (exemple : labenv.local), mais il peut y avoir d’autres SID dans l’univers des ordinateurs qui ont exactement la même valeur. La première des sous-autorités est très souvent une sous-autorité bien connue.

Notre SID a alors trois sous-autorités supplémentaires: 1534169462, 1651380828, et 111620651. Elles n’ont pas en elles-mêmes un sens implicite, mais ensemble elles indiquent le domaine ou l’ordinateur qui a émis le SID. En fait, le SID pour le domaine est S-1-5-21-1534169462-1651380828-111620651, et tous les SID délivrées dans ce domaine commence par cette valeur et se terminer par un RID unique pour l’utilisateur ou l’ordinateur qu’ils désignent. Dans notre exemple, le SID se termine par 500, ce qui est un RID bien connue puisqu’il désigne le compte Administrateur (built-in Administrator account) d’une machine Windows. 501 est le RID pour le compte invité (Guest account) et 502 celui du Kerberos Ticket Granting Ticket (krbtgt).

Voici les sous-autorités SID les plus communément rencontrées,

5 – Les SIDs sont établis durant les sessions d’authentifications afin d’activer les permissions à accorder à n’importe quelle application ayant droit. Ces types de SIDs ont leur première sous-autorité défini à 5 – S-1-5-5-x-y

6 – Lorsqu’un processus se connecte en tant que service, il reçoit un SID spécial dans son jeton afin de le désigner. Ces types de SIDs ont leur première sous-autorité défini à 6 – S-1-5-6-x-y

21 – SECURITY_NT_NON_UNIQUE – Identifie des SIDs d’utilisateurs et d’ordinateurs qui ne sont pas garantis d’être universellement (totalement) unique.

32 – SECURITY_BUILTIN_DOMAIN_RID – Identifie des SIDs de comptes prédéfinis (built-in accounts). Par exemple, le SID du groupe administrateurs est S-1-5-32-544 – S-1-5-32-x-y

80 – SECURITY_SERVICE_ID_BASE_RID – Identifie les SIDs pour les services Windows – S-1-5-80-x-y

 

  • Point spécifique sur les SIDs des services Windows

Les SIDs des services Windows commencent toujours avec S-1-5-80 et terminent avec un numéro de sous-autorité qui est basé sur le nom du service. Cela signifie qu’un service donné aura le même SID sur tous les ordinateurs! Cela signifie également que vous avez la possibilité d’obtenir le SID d’un service arbitraire même s’il n’existe pas. Pour vous démontrer cela, nous allons utiliser un utilitaire intégré dans le système d’exploitation Windows,

Exécutez la commande (dans une console MS-DOS), sc showsid toto

Vous pouvez observer que même si toto n’existe pas comme service sur ma machine ou sur la vôtre, le SID renvoyé par l’utilitaire « SC » sera le même car il se base sur le nom du service!

 

  • RIDs connus

Quand un développeur écrit un programme pour Windows, il a souvent besoin de connaître le SID de quelque entités principales de sécurité. Habituellement, un SID peut être facilement construit si seulement le RID est connu parce qu’il est tout simplement ajouté à l’ordinateur ou au domaine Active Directory, comme dans le cas du compte d’administrateur. Toutefois, pour plus de commodité, il est souvent souhaitable d’avoir une forme plus courte et statique de quelques SIDs. Pour fournir cela, le modèle de sécurité utilisé dans Windows inclut un nombre important de SIDs connus – SID qui sont toujours les mêmes sur tous les ordinateurs. Quelques SID universellement connus sont les mêmes sur tous les systèmes d’exploitation à l’aide de ce modèle de sécurité. Ce sont les SID qui commencent par S-1-1, S-1-2, ou S-1-3, y compris ceux discuté au cours de cet article, comme le CRÉATEUR PROPRIÉTAIRE SID: S-1-3-0.

S-1-5-32 est connue, par exemple, pour être  le SID de domaine. Il peut, à son tour, être combiné avec un RID bien connu pour former un SID pour un compte particulier. Par exemple, le SID pour le groupe Administrateurs, que ce soit sur un domaine ou sur un ordinateur autonome, est toujours S-1-5-32-544. Dans le cas de groupes intégrés (built-in groups) un RID peut être combiné avec S-1-5-32 pour former un SID qui est valable sur n’importe quel ordinateur. D’autres comptes sont ajoutés au domaine pour former le SID complet. C’est le cas avec le groupe Admins du domaine qui récupère toujours le RID 512 pour former un SID tel que S-1-5-21-1534169462-1651380828-111620651-512.

500 – Administrator

501 – Guest

502 – krbtgt

512 – Domain Admins

513 – Domain Users

514 – Domain Guests

515 – Domain Computers

516 – Domain Controllers

544 – Built-in Administrators

545 – Built-in Users

546 – Built-in Guests

 

  • Et la sécurité dans tout ça?…

Les SIDs connus pourrait permettre à un attaquant éclairé de trouver un utilisateur ou un groupe. Cependant, cela peut également vous aider à suivre et trouver vos utilisateurs et groupes (ex: phase d’audit). N’oubliez jamais de modifier le nom du compte d’administrateur, afin de masquer la sécurité de ce compte, pour ceux qui ne sont pas informés. La création d’un compte administrateur  » pot de miel  » est un excellent moyen d’attraper des attaquants, en essayant de se connecter avec ce compte, qui n’est évidemment pas le compte « Administrateur » correct .

Bien sûr, un attaquant bien informé peut résoudre le SID et déterminer quel utilisateur a le RID 500 , indiquant l’administrateur par défaut. C’est une bonne raison de ne pas autoriser l’accès anonyme, de limiter la translation SID-nom, l’énumération de la SAM, etc.

Ce sera l’occasion de publier un prochain article sur ce sujet 🙂

Vous avez vraiment besoin de limiter mais surtout d’informer votre département informatique des utilisateurs qui serait en mesure d’effectuer une translation SID-nom, ou encore énumérer les utilisateurs et leurs SID. Il y a beaucoup trop d’informations qui peuvent être obtenus à partir de l’une de ces listes, pour un attaquant potentiel.

  • Historique des SIDs (direct from the source! – Richard B. Ward, Architect – Windows Core)

« The original concept of the SID called out each level of the hierarchy. Each layer included a new sub-authority, and an enterprise could lay out arbitrarily complicated hierarchies of issuing authorities. Each layer could, in turn, create additional authorities beneath it. In reality, this created a lot of overhead for setup and deployment, and made the management model group even more baroque. The notion of arbitrary depth identities did not survive the early stages of development, although the structure was already too deeply ingrained to be removed. In practice, two SID patterns developed. For built-in, predefined identities, the hierarchy was compressed to a depth of two or three sub-authorities. For real identities of other principals, the identifier authority was set to five, and the set of sub-authorities was set to four. »

 

Même si la compréhension des SIDs dans le monde Microsoft peut paraître compliqué, j’espère que cet article vous aura permis de mieux comprendre leurs structures!

 

Ressources :

 SECURITY CONFIGURATION GUIDANCE SUPPORT  – http://support.microsoft.com/kb/885409/en-us 

jordanlaurent

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *