[ Pobierz całość w formacie PDF ]
.com Domain Local Group = Lista kontroli dostêpu (ACL)zawieraj¹ca grupê lokalnej domeny Subsidiary.comKierunki relacji zaufaniaDwie domeny (Company.com i Subsidiary.com) s¹ po³¹czone ze sob¹ poprzez relacjêzaufania drzewa katalogowego.Jest to dwukierunkowa przechodnia relacjazaufania Kerberos, dlatego te¿ rozró¿nienie domeny „zaufanej” i „ufaj¹cej” jestbardzo p³ynne.Zwróæmy uwagê na u¿ytkownika w domenie Company.com, który uzyskuje dostêp doobiektu domeny Subsidiary.com.Administrator zabezpiecza obiekt w domenieSubsidiary.com za pomoc¹ konta domeny Company.com, dlatego te¿ domenaSubsidiary.com jest domen¹ „ufaj¹c¹”, a Company.com domen¹ „zaufan¹”.Relacjezaufania zawsze s¹ „odwrotnie skierowane” do kierunku, w którym s¹ u¿ywane.Wiem, brzmi to zabawnie.Administrator jest w stanie zmodyfikowaæ deskryptor zabezpieczeñ w kontenerzeOU w domenie Subsidiary.com, gdy¿ jest cz³onkiem grupy administracyjnej tejdomeny.Grupa administracyjna posiada prawo odczytu-zapisu odczytu/zapisu doobiektów katalogu w swojej domenie.Reasumuj¹c, u¿ytkownik z zaufanej domeny Company.com próbuje uzyskaæ dostêp doobiektu katalogu w domenie zaufanej Subsidiary.com.Obiekt jest zabezpieczonyprzez lokaln¹ grupê w domenie Subsidiary.com.U¿ytkownik znajduje siê wCompany.com i jest cz³onkiem tej grupy.Poni¿ej przedstawiona zosta³a kolejnoœæzdarzeñ, które maj¹ miejsce podczas próby uzyskania dostêpu do obiektu przeztego u¿ytkownika.U¿ytkownik korzysta z konsoli Active Directory Users andComputers (U¿ytkownicy i komputery Active Directory).Procedura 10.8 Funkcjonalny opis uzyskiwania dostêpu do obiektu poprzez lokaln¹grupê ¹ domenow¹Gdy u¿ytkownik loguje siê do domeny Company.com, LSA tworzy listêidentyfikatorów zabezpieczeñ SID dla u¿ytkownika, w oparciu o atrybut Member-Of(Cz³onek) obiektu u¿ytkownika oraz skanowanie grup uniwersalnych w kataloguglobalnym GC.LSA nie znajduje u¿ytkownika na liœcie cz³onków grupy lokalnej domenowej wSubsidiary.com.Czêœciowa kopia kontekstu nazw w katalogu globalnym nieobejmuje listy cz³onków grup lokalnej domeny.Dlatego te¿ TGT wydane przezcentrum dystrybucji biletów w domenie Company.com zawiera tylko identyfikatoru¿ytkownika i identyfikator grup domeny Company.com, do której y nale¿yu¿ytkownik.Gdy u¿ytkownik po otwarciu konsoli Active Directory Users and Computers(U¿ytkownicy i komputery Active Directory) chce przejrzeæ przegl¹daæ domenêSubsidiary.com, klient sieciowy na komputerze u¿ytkownika musi przedstawiækontrolerowi domeny Subsidiary.com bilet Kerberos, tak aby kontroler móg³otrzymaæ zezwolenie do wys³ania zapytania LDAP.Active Directory nie akceptujebezpo³¹czeniowych ¿¹dañ wyszukiwania.Aby otrzymaæ bilet Kerberos dla serwera w domenie Subsidiary.com, klientsieciowy musi posiadaæ TGT dla Subsidiary.com.Centrum dystrybucji biletów wCompany.com nie mo¿e jednak wydaæ takiego TGT — – le¿y to w kompetencji centrumw kontrolerze domeny Subsidiary.com.KDC w domenie Company.com musi w imieniu u¿ytkownika uzyskaæ TGT dla domenySubsidiary.com.Nastêpnie centrum dystrybucji biletow KDC w Subsidiary.comwydaje TGT na podstawie relacji zaufania drzewa katalogowego, która istniejepomiêdzy dwiema dwoma domenami.Podczas tworzenia TGT dla u¿ytkownika Company.com, LSA skanuje kontekst nazwsprawdzaj¹c, czy u¿ytkownik albo grupy, do których nale¿y u¿ytkownik s¹cz³onkami grup lokalnej domeny.W koñcu LSA znajduje konto u¿ytkownika w grupielokalnej domenowej i dodaje jej identyfikator do identyfikatorów znajduj¹cychsiê w TGT u¿ytkownika, tworz¹c nowy TGT dla domeny Subsidiary.com.Nastêpniewydaje kontrolerowi domeny Company.com bilet, który jest automatycznieprzekazywany do klienta sieciowego znajduj¹cego siê w komputerze u¿ytkownika.Klient sieciowy natychmiast wykorzystuje TGT do uzyskania biletu do kontroleradomeny Subsidiary.com.W oparciu o rekordy SRV klient wybiera jeden zkontrolerów domeny.Centrum KDC w domenie Subsidiary.com wydaje wybranemu kontrolerowi domeny biletKerberos.Bilet zawiera kopiê pola Authorization Data (Dane uwierzytelnienia) zTGT domeny Subsidiary.com.W polu tym znajduje siê identyfikator zabezpieczeñgrupy lokalnej domenowej Subsidiary.com oraz identyfikatory grup z domenyCompany.com.Klient sieciowy przedstawia kontrolerowi domeny Subsidiary.com bilet Kerberos.Kontroler uwierzytelnia bilet.Us³uga LSA w kontrolerze domeny nie skanuje bazySAM, gdy¿ kontroler domeny nie ma prawa do posiadania grup lokalnych w bazieSAM.LSA tworzy lokalny ¿eton dostêpu dla u¿ytkownika zawieraj¹cyidentyfikatory z pola Authorization Data (Dane uwierzytelnienia).Gdy u¿ytkownik próbuje uzyskaæ dostêp do kontenera w domenie Subsidiary.com,LSA porównuje identyfikatory zabezpieczeñ z listy kontroli dostêpu obiektu zidentyfikatorami znajduj¹cymi siê w ¿etonie dostêpu u¿ytkownika.Gdy znalezionyzostanie identyfikator grupy lokalnej domeny, który pasuje do identyfikatora zlisty kontroli, u¿ytkownik uzyskuje dostêp do odczytu-zapisu odczytu/zapisu doobiektu.Reasumuj¹c, gdy u¿ytkownicy z zaufanej domeny staj¹ siê cz³onkami grup lokalnejdomeny w domenie ufaj¹cej, us³uga LSA w kontrolerze domeny ufaj¹cej mo¿euwierzytelniæ prawa dostêpu u¿ytkowników w oparciu o zawartoœci biletówKerberos.Problem zwi¹zany z grupami globalnymi wygl¹da natomiast trochê inaczej.Otó¿u¿ytkownicy z jednej domeny nie mog¹ byæ dodawani do grupy globalnej z innejdomeny bez wzglêdu na konfiguracjê relacji zaufania.Grupy globalne mog¹posiadaæ cz³onków tylko ze swoich domen.Z tego samego powodu grupy lokalnedomenowe nie mog¹ byæ zagnie¿d¿ane w grupach globalnych, gdy¿ u¿ytkownicy zdomen ufaj¹cych mog¹ byæ cz³onkami grupy lokalnej domenowej [ Pobierz caÅ‚ość w formacie PDF ]

zanotowane.pl

doc.pisz.pl

pdf.pisz.pl

listy-do-eda.opx.pl