Jak prawidłowo delegować uprawnienia w Active Directory

Transkrypt

1 Obrona Jak prawidłowo delegować uprawnienia w Active Directory Paweł Baszkowski IT Studio stopień trudności Delegowanie uprawnień w AD to przydatne przypisywanie pewnej liczby spraw związanych z bezpieczeństwem i ułatwianie zarządzania zadaniami. Dzięki właściwemu zdelegowaniu uprawnień w AD masz możliwość określenia wybranych ról w środowisku, ograniczenia natłoku i błędów administracyjnych oraz zdefiniowanie zasad uprawnień w twojej sieci. Wiele przedsiębiorstw używających serwerów pocztowych Microsoft Exchange z Active Directory boryka się z mocą uprawnień. Spowodowane jest to po części złożonością modelu delegowania uprawnień dla wielopoziomowej organizacji. Najtrudniej jest właściwie dopasować model do własnej organizacji. Nie jest to jednak niemożliwe, istnieje kilka prostych sposobów, jakie mogą być zastosowane z lekką modyfikacją dla większości struktur IT. Każde środowisko jest inne w sposobie, kształcie, a także formie. Jednak największe środowiska są do siebie podobne pod kątem wyzwań IT. Dla przykładu, wiele organizacji jest podzielonych geograficznie na regiony, niezależne zespoły inżynierów, operacyjne, wsparcia IT, będące własnymi Business Units. A także wiele dużych organizacji musi radzić sobie z takimi sprawami, jak eskalacja uprawnień, nadużywanie kont systemowych o wysokich uprawnieniach i kwestiach związanych z zaufaniem. Zaufanie jest interesującym zwrotem i często bywa wykorzystywane w utrzymywaniu wielu gałęzi drzewa Active Directory. Problematyka ta często ma wielki wpływ na dostępność systemu innej dywizji czy regionu. Powszechnie spotykane jest, że występują różne poziomy dostępu pomiędzy granicami organizacyjnymi oraz braki w wiedzy dotyczącej specyficznych systemów wymaganych, by wspierać konkretny region lub organizację. Dodatkowo, dywizje często nie chcą oddać uprawnień administratorskich do centrali firmy. W międzyczasie dla każdego wdrożenia Active Directory administratorzy muszą zdefiniować zasady współdziałania dla aplikacji, Z artykulu dowiesz sie... na temat Active Directory sposobu delegowania uprawnień w AD definiowanie roli administratora tworzenie OU i modelu bezpieczeństwa Powinieneś wiedzieć... zasady administrowania siecią dzielenia obowiązków definiowania uprawnień wstępna znajomosc IT/Telek., m.in. AD 2 hakin9 Nr 5/2007

2 Jak delegować uprawnienia w Active Directory które utylizują infrastrukturę Active Directory. Niestety, często spotykany cel w procedurach instalacji aplikacji to stworzenie konta systemowego jako członka grupy Domain Admins. Problem, jaki się z tym wiąże to fakt, że te konta mają podstawowe uprawnienia. Równoważąc uprawnienia tych kont z uprawnieniami Domain Administrator stwarzamy znaczące zagrożenie dla środowiska IT. Konta systemowe z łatwością mogą być nadużywane poprzez niebezpiecznych lub beztroskich administratorów lub wykorzystane jako środek do osiągnięcia celu przez atakujących, którzy odkrywają podstawowe sprawy związane z bezpieczeństwem w aplikacji. Podczas gdy te próby mogą się okazać nieprzezwyciężone, określają one scenariusz standardowy dla implementowania modelu delegowania w Active Directory (AD). Stworzenie modelu delegowania uprawnień jest interaktywnym projektem. Zalecane jest wykonanie poniższych predefiniowanych kroków: określić role administracyjne (IT) w twej organizacji określić Organizational Unit (OU) i model Security Group ustanowić drugorzędne konta dla IT administratorów delegować uprawnienia. Jest to trudny proces. Przyjrzyjmy się szczegółowo tym krokom. Określenie ról Proces definiowania rozpoczyna się poprzez jednoczesne zrozumienie administrowania danymi i usługami. Te koncepcje są podstawą każdego prawidłowego modelu delegowania uprawnień Active Directory. Administracja usługami to zarządzanie krytycznymi katalogami usług, struktur komponentów, takich jak serwery Exchange i kontrolery domeny. Zarządzanie danymi to zarządzanie obiektami, takimi jak konta pocztowe i konta użytkowników, które rezydują z tymi usługami. Dzięki zakresowi Active Directory, administratorzy usług są ciągle odpowiedzialni za dostawy i osiągalność usług katalogowych, podczas gdy administratorzy zarządzają kontami użytkowników i serwerów oraz innymi zasobami domenowymi. Active Directory wspiera delegowanie uprawnień poprzez Organizational Unit (OU). OU może być często dostosowywany tak, by zapewnić ten sam poziom autoryzacji, jaki jest dostępny dla administratorów z już istniejących katalogów usług lub modeli domenowych. Ważne jednak jest to, by rozumieć jak niektóre funkcje po prostu nie mogą być delegowane i muszą być zarządzane poprzez pojedynczą zaufaną grupę lub jednostkę. Analiza zadań jest równie krytyczna. Musisz wiedzieć, które zadania Active Directory są przeprowadzane przez administratorów i jak te zadania mogą być korelowane do konkretnych ról. Dla przykładu tworzenie nowego site Active Directory jest zadaniem administracyjnym serwisowo-usługowym, podczas gdy modyfikacje członkostwa w grupie bezpieczeństwa to zadanie dla administratora danych. Każde zadanie powinno być porównane pod kątem częstotliwości, ważności i trudności. Są to główne aspekty określania zadań, kiedy uprawnienia muszą być delegowane. Zadania są wykonywane rutynowo, wiąże się z nimi określone ryzyko oraz są stosunkowo proste do wykonania, a także wymarzone do zdelegowania. Z drugiej strony, zadania, które są wykonywane rzadziej, mają większy wpływ w organizacji i wymagają wyższych umiejętności. Są w związku z tym trudniejszymi kandydatami do oddelegowania. Zamiast tego tymczasowe zwiększanie uprawnień dla konta do wymaganego poziomu lub zmiana zadania jest właściwą ścieżką dla tych zadań. Mimo że wiele dużych organizacji funkcjonuje na podobnych podstawach, zawsze bezpieczniej jest założyć, że model delegowania uprawnień może być zaimplementowany. Dla celów O autorze: własciciel i założyciel IT Studio to inż. informatyk, doświadczenie w branży IT zarządzał sieciami i telekomunikacją w logistyce i bankach kierował i uczestniczył w wielu wdrożeniach i projektach informatycznych pbaszkowski@it-studio.pl dydaktycznych przedstawiony jest testowy zbiór ról, które udostępniają możliwości zarządzania. Granice oorganizacyjne i sprawy związane ze zmianą uprawnień (tj. dostępność zewnętrzna kontrolerów domeny) są zdefiniowane. Proszę mieć na uwadze, że ten model to tylko przykład jest on jednak świetnym startem dla dyskusji w twej organizacji, ale nie powinieneś planować, by użyć go jako argument w dyskusji. Niektóre role są od razu określone przez Active Directory, a niektóre muszą być stworzone z niczego, by wyjść poza model delegowania. Przykład gotowy do zastosowania dla wielu dużych środowisk organizacji Active Directory może zawierać Enterprise Admins, Domain Admins, i administratorów usług, Regional Admins i administratorów zarządzających danych. Administratorzy usług Przyjrzyjmy się rolom administratorów usług. Administratorzy usług zarządzają krytycznymi komponentami infrastruktury, a wszyscy administratorzy którzy należą do tej grupy są wysoce uprzywilejowani. Dlatego też powinniśmy zaimplementować strategię o koniecznej ilości uprawnień, taką która oznacza przyznawanie minimum uprawnień niezbędnych do przeprowadzania określonych zadań. Taka taktyka jest ściśle zalecana.. Grupy Enterprise i Domain Admins w Active Directory definiują dwie grupy specjalnych administratorów, których uprawnienia są wymagane w celu prawidłowego hakin9 Nr 5/2007 3

3 Obrona funkcjonowania krytycznych funkcji AD. Te grupy są odpowiedzialne za najwyższy poziom administrowania usługami. By zminimalizować ryzyko dziedziczenia w takich wysoko uprzywilejowanych grupach, zalecane jest ograniczanie dostępu do tych grup. Grupa Enterprise Admins nie powinna mieć stałych członków, a grupa Domain Admins powinna zawierać jedynie małą, zarządzalną grupę zaufanych osób, które pracują dla organizacji na pełen etat. Gdy muszą być wykonane zadania administratorskie, takie jak autoryzacja DHCP w Active Directory, członkowie grupy Domain Admins w domenie nadrzędnej lasu AD mogą otrzymać wymagane uprawnienia poprzez ustanowienie przynależności do grupy Enterprise Admins. Takie uprawnienia powinny być przyznawane tylko na krótkie okresy czasu, w celu uniknięcia tworzenia stałych członków w grupie Enterprise Admins. Oczywiście, wszyscy członkowie grupy Domain Admins w danym lesie Active Directory powinni być osobami, którym można zaufać w równym stopniu. Typowym błędem, który popełnia większość organizacji podczas rozwoju modelu delegowania uprawnień jest blokowanie lub zmniejszanie roli wbudowanych grup czy innych komponentów. Powszechne jest myślenie, że modyfikacja tych domyślnych ról może mieć nieprzewidywalny skutek, nie ma gwarancji, że sevice pack czy aktualizacje oprogramowania przywracają te ustawienia. Dodatkowo, ten typ modyfikacji tworzy niewspierane środowisko poza organizacją. Praktyczny cel polega na tym, by użyć wbudowane grupy i role, ale ograniczyć członkostwo. By to zrobić, prawdopodobnie musiałbyś stworzyć nowe role dla administratorów, którzy wcześniej przynależeli do grup takich jak Domain Admins. Administratorzy grupy powinni składać się z administratorów usług scentralizowanych, którzy zapewniają wsparcie dla wszystkich usług organizacji. Mimo, że jest to stworzona rola, usługi katalogowe i dostępy systemowe mogą być dopasowane do specyficznych wymagań twojej organizacji. Podczas gdy członkowie tej grupy są administratorami usług, mogą również dokonywać okazjonalnie innych, bardziej rozległych, zadań zarządczych. Mamy więc różne typy systemów i różne obszary odpowiedzialności, role te są rozdzielone w różne podgrupy w ramach katalogu. Na przykład, pojedyncze grupy powinny być stworzone tak, aby zapewnić dyskretne zarządzanie specyficznymi systemami, takimi jak serwery Exchange. Ta grupa także służy jako punkt eskalacji dla administratorów danych. Inne powszechne stanowisko określa przynależność do grupy Domain Admins z powodu przyznania uprawnień administratorskich na każdym systemie w danej domenie. Cała sztuka polega tu na zezwoleniu administratorom usług na tylko wymagane uprawnienia, by kontrolować serwery korporacyjne bez dodawania ich do grupy Domain Admins. W celu ograniczenia rozprzestrzeniania uprawnień, administratorzy ci powinni posiadać nadane uprawnienia do wbudowanej grupy administratorów na kontrolerach domeny, w związku z posiadaniem przez tą grupę wielu podległych uprawnień do katalogu usług, które nie mogą być rozdzielone. Dla przykładu, członek wbudowanej grupy administratorów wybranej domeny może zarządzać członkostwem w grupie Domain Admins, umożliwiając członkom zmianę uprawnień bez dokonywania sprawdzenia. Pamiętając o zasadzie nie przekazywania domyślnych uprawnień, ryzyko może być ominięte poprzez stworzenie grupy zagnieżdżonej w grupie Server Operators i wbudowany w grupę domenowy DNS Admins. To umożliwi lokalne zarządzanie kontrolerami domeny limitując możliwość rozprzestrzeniania uprawnień. Dla większości systemów (innych niż kontrolery domen, np. Certificate Servers) powinno się stworzyć grupę w lokalnej grupie administratorów. Automatyka zagnieżdżania lokalnych członków grup może być osiągnięta poprzez funkcjonalność Restricted Groups w Group Policy. Administratorzy danych A teraz prześledźmy role administratorów danych. Ci powinni być stworzeni ze skumulowanymi uprawnieniami, co oznacza, że jeden administrator powinien mieć pełne Listing 1.????????????????? nazwa_dc>,dc=com /I:S /G <twoja_nazwa_dc>\<twoja_nazwa_dane_ou>:rpwp;c;user nazwa_dc>,dc=com /I:S /G <twoja_nazwa_dc>\<twoja_nazwa_dane_ou>:rpwp;co;user nazwa_dc>,dc=com /I:S /G <twoja_nazwa_dc>\<twoja_nazwa_dane_ou>:rpwp;l;user nazwa_dc>,dc=com /I:S /G <twoja_nazwa_dc>\<twoja_nazwa_dane_ou>: RPWP;postalCode;user nazwa_dc>,dc=com /I:S /G <twoja_nazwa_dc>\<twoja_nazwa_dane_ou>: RPWP;postOfficeBox;user nazwa_dc>,dc=com /I:S /G <twoja_nazwa_dc>\<twoja_nazwa_dane_ou>:rpwp;st;user nazwa_dc>,dc=com /I:S /G <twoja_nazwa_dc>\<twoja_nazwa_dane_ou>: RPWP;streetAddress;user nazwa_dc>,dc=com /I:S /G <twoja_nazwa_dc>\<twoja_nazwa_dane_ou>:rpwp;telephonenum ber;user 4 hakin9 Nr 5/2007

4 Jak delegować uprawnienia w Active Directory prawa do drugiego plus pewne dodatkowe uprawnienia. Przyjrzymy się takim potencjalnym grupom. Grupa pierwsza administratorów powinna zawierać ogólne zasady zarządzania wcześniej stworzonego katalogu obiektów. Ta grupa powinna być przeznaczona dla wstępnie przeszkolonych administratorów lub dla takich, którzy wykonują odizolowane zadania, np. zmiana haseł. Nadaj tej grupie we własnej OU uprawnienia do modyfikacji właściwości kont użytkowników, zmiany hasła, odblokowywania kont, uaktywniania lub blokowania kont, resetowania kont stacji roboczych, modyfikowania członkostwa obiektów grupowych dla nieadministracyjnych grup. Grupa druga powinna umożliwiać trochę więcej funkcji, jak zarządzanie tworzeniem obiektów, zezwalanie na tworzenie obiektów, aby mogły być zarządzane przez grupę pierwszą. Członkowie tej grupy mogą dodawać i modyfikować konta administracyjne grupy pierwszej, a także zarządzać kontami użytkowników. Mają możliwość usunięcia obiektów stacji roboczych, dodawania, modyfikowania, usuwania obiektów Server, Contact i Shared Folder. Kolejna grupa to grupa Regional Admins. Ta grupa wychodzi poza obręb własnej struktury Organizational Unit. Nie może zarządzać innymi strukturami regionalnymi OU. Konto Regional Admin powinno być rozważane jako wysoce uprzywilejowane. Konta Regional Admins przechowywane są w oddzielnej hierarchii OU i zarządzane przez administratorów usług. Regional Admins mają dostęp do tworzenia większości obiektów bez restrykcji we własnej strukturze Organizational Unit, co stwarza pewne zagrożenie, że tworzone obiekty mogą nie być zarządzane przez administratorów o niższych uprawnieniach. Wiele struktur organizacyjnych posiada scentralizowany help desk. Ta rola wypełnia listę administratorów danych, zapewniając grupie administratorów danych nadrzędne prawa nad Regional Admins. Prawa nie są delegowane do tych grup, są tworzone jako zagnieżdżone członkostwo w każdej grupie Regional Admins. Zapewnia to najwyższej jakości punkt eskalacji dla wszystkich administratorów danych, jak i służy jako punkt dostępu dla spraw do przekazania dalej do grupy administratorów usług. Model Organizational Unit i Security Group Gdy role są zdefiniowane, w organizacji musimy stworzyć model Organizational Unit i Security Group. Dwa główne czynniki decydują o budowie OU w Active Directory. Po pierwsze delegowanie uprawnień, po drugie tworzenie punktu, gdzie obiekty Group Policy mogą być połączone. Sposób, w jaki zdecydujesz się na delegowanie uprawnień powinien być głównym czynnikiem, decydującym o tym, jak chcesz zaimplementować twoją strukturę OU. Mając to na uwadze, OU nadrzędne powinno być stworzone dokładnie pod domeną, tak aby zmieścić wszystkie obiekty. Taki OU służy celom definiowania najwyższego poziomu uprawnień ponad usługami katalogowymi, które mogą rozpocząć się na poziomie OU, a nie na poziomie domenowym. Poniżej najwyższego poziomu OU powinien zostać stworzony oddzielny OU, by prezentować własny region mający dyskretny zespół zarządzania danymi. Każdy regionalny OU powinien mieć wspólną, nie za dużą hierarchię do zarządzania obiektami katalogowymi. Unifikowanie jest krytyczne dla zarządzania bieżącego, w związku z automatyzowaniem delegowania uprawnień. To duże wyzwanie, zważywszy na fakt, że każdy region może wymagać unikalnych OU. Administratorzy IT muszą trzymać się określonych zasad. Jeśli rozszerzenie jest wymagane dla jednego regionu, struktura OU powinna być rozszerzona dla wszystkich regionów. To może być na początku trudne, ale jeśli organizacja zapewnia podstawowe przechowywanie dla obiektów, możliwe. Wreszcie, stwórz oddzielne podgrupy administracyjne i konta do usuwania możliwości administracyjnych, by zwiększać ich przywileje. Tworzenie kont w oddzielnych OU zezwala ograniczać zarządzanie własnym poziomem lub niższym. Dla przykładu, każdy członek grupy Domain Admins może stworzyć dowolne konto dla użytkownika jako Domain Admin. Przy zastosowaniu naszego podziału kont na poddomeny ryzyko zmniejsza się. Ustanawianie drugorzędnych kont Kluczem do prawidłowego modelu delegowania uprawnień jest stworzenie zasady jak najmniej zbędnych uprawnień. W praktyce oznacza to, że tylko względy bezpieczeństwa powinny być brane pod uwagę, aby wykonać zadania określone dla danej roli i nic więcej. Niestety wielu administratorów sądzi, że do bieżących zadań oraz przeglądania zasobów sieci czy czytania poczty, również pomocne będą im uprawnienia administratorskie. Gdy mamy oddzielne konta możemy uniknąć przypadkowego skasowania drzewa katalogowego przez zmęczonego administratora lub zabezpieczyć się przed atakami, które są powodowane przez aplikacje codziennego użytku, ale takimi, które celują w administratorów. By to osiągnąć bez konieczności wylogowywania się użyj serwisu Secondary Logon (Runas.exe). To zezwoli użytkownikowi zwiększyć uprawnienia, zapewniając inny zestaw uprawnień, gdy są uruchamiane skrypty lub pliki wykonywalne na serwerach lub stacjach roboczych. Mimo że koncepcja używania kont o niższych uprawnieniach jest prosta, organizacje często z nieufnością do niej podchodzą. Wynika to z przyzwyczajeń, które trudno się zmienia. Wymuszenie użycia kont o niższych uprawnieniach może być wynikiem niedopuszczenia otrzymywania bezpośrednich wiadomości pocztowych na kontach o uprawnie- hakin9 Nr 5/2007 5

5 Obrona niach wyższych. To jakże proste rozwiązanie w kolejny znaczący sposób obniża używanie takich kont rutynowo do zadań nieadministracyjnych. Delegowanie uprawnień Finalny krok wdrożenia modelu delegowania uprawnień to jego wdrożenie, czyli delegacja uprawnień w Active Directory. W tym celu należy skonfigurować dostęp do access control entries (ACEs) oraz access control lists (ACLs) dla danych przechowywanych w ramach usług katalogowych. ACLs w kontenerach Active Directory definiują, które obiekty mogą być tworzone i w jaki sposób mają być zarządzane. Delegowanie uwzględnia podstawowe operacje na obiektach, m.in. przeglądanie obiektów, tworzenie obiektów z uprzednio predefiniowanych, zmiana atrybutu czy bezpieczeństwo. Poza nimi AD definiuje Extended Rights, które umożliwiają na operacje, takie jak wyślij jako i zarządzaj topologią replikacji. By zaimplementować model delegowania uprawnień grupy i podgrupy bezpieczeństwa, OU muszą posiadać przypisane uprawnienia ponad obiektami w katalogu. Nie chcemy przecież się uwsteczniać i nagle tworzyć wynalezionego raz koła. Przeciwnie, postaraj się zmniejszyć uprawnienia wbudowanym grupom gdzie możliwe. Jeśli np.: określone wpisy DNS muszą być dokonane, nie musisz delegować uprawnień ponad kontenerami i nazywać kontekstu powiązanego do zintegrowanych DNS w Active Directory. Lepiej obniżyć grupę BUILTIN\DNS Admins w domenie. Dodatkowo, prawa użytkowników i inne uprawnienia mogą być zwiększone poprzez Group Policy w taki sposób, aby zapewnić dodatkowe uprawnienia wymagane do zarządzania określonymi klasami systemów poprzez określoną rolę. Podczas przypisywania uprawnień, używając delegowania uprawnień, powinno się limitować lub całkowicie eliminować używanie Deny ACEs. Mogą stać się one bowiem kłopotliwe w razie wystąpienia błędów. Lepszym rozwiązaniem jest wyodrębnienie Allow ACEs w celu przyznania uprawnień do grup przedefiniowanych prezentujących twą rolę. Pamiętaj, że predefiniowane role będą mieć tylko wyłączne prawa zdefiniowane przez te role. Ważne jest dziedziczenie w AD. Zawsze bądź dokładny w zakresie dziedziczenia poprzez zapewnianie dziedziczących ACEs, by były one zastosowane możliwie blisko obiektów celu. Jest wiele narzędzi, których możesz użyć w celu prawidłowego ustalenia zasad modelu delegowania uprawnień. Możesz korzystać z szablonów i kreatorów (wizardy). Podstawowe tekstowe narzędzie, mogące posłużyć do manipulowania usługami ACLs na obiekcie w katalogu to DSACLS.EXE, Jeśli flaga dziedziczenia będzie źle zdefiniowana narzędzie nie zadziała prawidłowo. Bardzo ważne jest testowanie narzędzia, by stwierdzić ewentualne nieprawidłowości. Jeśli chcesz stworzyć obiekt typu komputer w docelowym OU, zwróć uwagę na to, że narzędzie jest casesensitive: dsacls.exe ou=<twoja_nazwa_ ou>,dc=<twoja_nazwa_dc>,dc=com /I:T /G <twoja_nazwa_dc>\dataadmin:cc;computer Określony zbiór uprawnień jest wymagany dla tworzenia kilku obiektów. Jest różnica pomiędzy atrybutami obiektu: tymi co mogą wystąpić, a tymi które są konieczne. Dla obiektów użytkowników przykład może wyglądać tak: nazwa_dc>,dc=com /I:T /G <twoja_nazwa_ dc>\<twoja_nazwa_dane_ou>:cc;user Administrator może spodziewać się kilku błędów podczas tworzenia obiektów typu użytkownik. Musimy nadać wymagane uprawnienia, by ustawić wymagane atrybuty dla obiektu użytkownika, włączając zmianę hasła. Jest to spowodowane w następującej dodatkowej składni DSACLS. Na początku przyznajmy uprawnienia do zapisu atrybutów koniecznych, poprzez nadanie Generic Read/Generic Write do wszystkich atrybutów klasy użytkownika: nazwa_dc>,dc=com /I:S /G <twoja_nazwa_ dc>\<twoja_nazwa_dane_ou>:grgw;;user Następnie, nadajmy rozszerzone uprawnienia do zmiany hasła: nazwa_dc>,dc=com /I:S /G <twoja_ nazwa_dc>\<twoja_nazwa_dane_ou>: CA;"Reset Password";user Na końcu, nadajmy uprawnienie do właściwości czytania i zapisu atrybutu Password Last: nazwa_dc>,dc=com /I:S /G <twoja_nazwa_ dc>\<twoja_nazwa_dane_ou>: RPWP;pwdLastSet;user Gdy właściwe uprawnienia zostaną zdelegowane, zdefiniowane role będą ograniczone tylko do zarządzania obiektami zdefiniowanymi w kontenerze DACL. Menu kontekstowe w Active Directory Users and Computers ogranicza listę nowych obiektów, jakie mogą zostać stworzone przez osobę z takimi wydelegowanymi uprawnieniami. DSACLS może również służyć do zautomatyzowania złożonego zbioru uprawnień. Poniżej przykład zastosowania komend do delegowania uprawnień, by ustawiać powszechne atrybuty ponad obiektami użytkowników w danym kontenerze: Takie przykłady są powszechne dla większości modeli delegowania uprawnień i mogą być używane w połączeniu z wcześniej zdefiniowanymi rolami. Innym narzędziem jest DSRE- VOKE.EXE, zezwalające administratorom lokalizować i usuwać zdelegowane uprawnienia dla specyficznych zasad bezpieczeństwa dla obiektów w ramach katalogu. To narzędzie może być użyteczne, jest ono specyficzne dla zasad bezpie- 6 hakin9 Nr 5/2007

6 Jak delegować uprawnienia w Active Directory czeństwa i nie wpływa na zagnieżdżone członkostwo wewnątrz grup bezpieczeństwa. Poza tymi narzędziami, uruchamianymi z linii poleceń, wysoce zalecane jest użycie User Rights Assignment i Restricted Groups z Group Policy. User Rights Assignment umożliwia administratorom IT rozszerzenie lub usunięcie niskich uprawnień (zdalny dostęp, restart systemu) dla różnych grup użytkowników na specyficznych systemach. Restricted Groups mogą być użyte do określenia i lokalnych i domenowych członków grup w lesie. W połączeniu, te narzędzia zapewniają wszystko, co niezbędne do zautomatyzowania i zaimplementowania modelu delegowania uprawnień Active Directory. Podsumowanie Tworzenie modelu delegowania uprawnień w AD może wydawać się skomplikowane, jednak tak nie jest. Wiele prostych modeli można zastosować do infrastruktury IT. Najważniejszy krok to zdefiniowanie jasnych ról. Należy limitować role do małych, zarządzalnych grup. Balansowanie jest trudne, zbyt wiele zmian spowoduje stworzenie ról nigdy nie wykorzystywanych, natomiast za mało nie zezwoli na właściwy podział obowiązków. Należy pamiętać podczas definiowania zadań, by grupować je pod względem częstotliwości, ważności i trudności. Po jednokrotnym zdefiniowaniu zwróć uwagę na wdrożenie zestawów przypadków, które pomogą zidentyfikować, które role można, a których nie należy zautomatyzować w procesie testowania. Dobrze przygotowane pozwolą przekonać osoby z zarządu do słusznej decyzji oraz pomogą w ewentualnych problemach w przyszłości. Na koniec, zawsze warto przygotować praktyczny test, przed wdrożeniem modelu delegowania uprawnień. Pamiętaj, że ułatwienie równa się jakości wspierania i stabilności modelu delegowania. Taki model będzie pełnił kluczową rolę w kontroli uprawnień administratorskich w środowisku twojego Active Directory. hakin9 Nr 5/2007 7