Z artykulu dowiesz sie Powinieneś wiedzieć Jak ... · Jak delegować uprawnienia w Active...

www.hakin9.orghakin9 Nr 5/20072

Obrona

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 nie-moż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 po-dzielonych 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 za-ufaniem.

Zaufanie jest interesującym zwrotem i często bywa wykorzystywane w utrzymy-waniu 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 wie-dzy dotyczącej specyficznych systemów wy-maganych, 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ą zde-finiować zasady współdziałania dla aplikacji,

Jak prawidłowo delegować uprawnienia w Active DirectoryPaweł 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.

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

Jak delegować uprawnienia w Active Directory

hakin9 Nr 5/2007www.hakin9.org 3

które utylizują infrastrukturę Active Directory. Niestety, często spoty-kany cel w procedurach instalacji aplikacji to stworzenie konta syste-mowego jako członka grupy Domain Admins. Problem, jaki się z tym wią-że to fakt, że te konta mają podsta-wowe uprawnienia. Równoważąc uprawnienia tych kont z uprawnie-niami Domain Administrator stwa-rzamy znaczące zagrożenie dla środowiska IT. Konta systemowe z łatwością mogą być nadużywa-ne poprzez niebezpiecznych lub beztroskich administratorów lub wykorzystane jako środek do osią-gnięcia celu przez atakujących, którzy odkrywają podstawowe spra-wy 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 dele-gowania w Active Directory (AD). Stworzenie modelu delegowania uprawnień jest interaktywnym pro-jektem. Zalecane jest wykonanie po-niż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ólProces definiowania rozpoczyna się poprzez jednoczesne zrozumienie administrowania danymi i usługami. Te koncepcje są podstawą każdego prawidłowego modelu delegowania uprawnień Active Directory. Admini-stracja usługami to zarządzanie kry-tycznymi katalogami usług, struktur komponentów, takich jak serwery Exchange i kontrolery domeny. Za-rządzanie danymi to zarządzanie obiektami, takimi jak konta pocz-towe i konta użytkowników, które rezydują z tymi usługami. Dzięki zakresowi Active Directory, admini-

stratorzy usług są ciągle odpowie-dzialni za dostawy i osiągalność usług katalogowych, podczas gdy administratorzy zarządzają kontami użytkowników i serwerów oraz inny-mi zasobami domenowymi.

Active Directory wspiera delego-wanie uprawnień poprzez Organiza-tional 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 mo-deli 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 jed-nostkę.

Analiza zadań jest równie kry-tyczna. Musisz wiedzieć, które zadania Active Directory są przepro-wadzane przez administratorów i jak te zadania mogą być korelowane do konkretnych ról.

Dla przykładu tworzenie no-wego site Active Directory jest zadaniem administracyjnym ser-wisowo-usługowym, podczas gdy modyfikacje członkostwa w grupie bezpieczeństwa to zadanie dla ad-ministratora 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 zdelegowa-nia. Z drugiej strony, zadania, które są wykonywane rzadziej, mają większy wpływ w organizacji i wy-magają wyższych umiejętności. Są w związku z tym trudniejszymi kan-dydatami do oddelegowania.

Zamiast tego tymczasowe zwiększanie uprawnień dla konta do wymaganego poziomu lub zmia-na 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 mo-del delegowania uprawnień może być zaimplementowany. Dla celów

dydaktycznych przedstawiony jest testowy zbiór ról, które udostęp-niają możliwości zarządzania. Granice oorganizacyjne i sprawy związane ze zmianą uprawnień (tj. dostępność zewnętrzna kon-trolerów domeny) są zdefiniowane. Proszę mieć na uwadze, że ten model to tylko przykład – jest on jednak świetnym startem dla dys-kusji w twej organizacji, ale nie powinieneś planować, by użyć go jako argument w dyskusji.

Niektóre role są od razu określo-ne 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 organi-zacji Active Directory może zawierać Enterprise Admins, Domain Admins, i administratorów usług, Regional Admins i administratorów zarządza-jących danych.

Administratorzy usługPrzyjrzyjmy się rolom administra-torów usług. Administratorzy usług zarządzają krytycznymi kompo-nentami infrastruktury, a wszyscy administratorzy którzy należą do tej grupy są wysoce uprzywilejowani. Dlatego też powinniśmy zaimple-mentować 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 Ad-mins w Active Directory definiują dwie grupy specjalnych admini-stratorów, których uprawnienia są wymagane w celu prawidłowego

O autorze:• własciciel i założyciel IT Studio

to inż. informatyk, doświadczenie w branży IT

• zarządzał sieciami i telekomunika-cją w logistyce i bankach

• kierował i uczestniczył w wielu wdrożeniach i projektach informa-tycznych

• [email protected]

hakin9 Nr 5/2007 www.hakin9.org

Obrona

4

funkcjonowania krytycznych funkcji AD. Te grupy są odpowiedzialne za najwyższy poziom administrowania usługami. By zminimalizować ryzy-ko dziedziczenia w takich wysoko uprzywilejowanych grupach, za-lecane 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 za-dania administratorskie, takie jak autoryzacja DHCP w Active Di-rectory, członkowie grupy Domain Admins w domenie nadrzędnej la-su AD mogą otrzymać wymagane uprawnienia poprzez ustanowienie przynależności do grupy Enter-prise Admins. Takie uprawnienia powinny być przyznawane tylko na krótkie okresy czasu, w celu uniknięcia tworzenia stałych człon-kó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 mo-dyfikacja tych domyślnych ról może mieć nieprzewidywalny skutek, nie ma gwarancji, że sevice pack czy aktualizacje oprogramowania

przywracają te ustawienia. Dodat-kowo, 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 Do-main Admins.

Administratorzy grupy powin-ni składać się z administratorów usług scentralizowanych, którzy zapewniają wsparcie dla wszyst-kich usług organizacji. Mimo, że jest to stworzona rola, usługi kata-logowe i dostępy systemowe mogą być dopasowane do specyficznych wymagań twojej organizacji. Pod-czas 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 od-powiedzialności, role te są rozdzie-lone w różne podgrupy w ramach katalogu. Na przykład, pojedyncze grupy powinny być stworzone tak, aby zapewnić dyskretne zarządza-nie specyficznymi systemami, taki-mi 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 przy-znania uprawnień administrator-skich 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 Do-main Admins. W celu ograniczenia rozprzestrzeniania uprawnień, ad-ministratorzy ci powinni posiadać nadane uprawnienia do wbudo-wanej 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ć roz-dzielone. 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 dokonywa-nia sprawdzenia.

Pamiętając o zasadzie nie przekazywania domyślnych upraw-nień, 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ść rozprzestrze-niania uprawnień. Dla większości systemów (innych niż kontrolery domen, np. Certificate Servers) po-winno 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 danychA teraz prześledźmy role admini-stratorów danych. Ci powinni być stworzeni ze skumulowanymi upraw-nieniami, co oznacza, że jeden administrator powinien mieć pełne

Listing 1. ?????????????????

dsacls ou=<twoja_nazwa_ou>,dc=<twoja_nazwa_dc>,dc=com /I:S /G <twoja_nazwa_dc>\<twoja_nazwa_dane_ou>:RPWP;c;user

dsacls ou=<twoja_nazwa_ou>,dc=<twoja_nazwa_dc>,dc=com /I:S /G <twoja_nazwa_dc>\<twoja_nazwa_dane_ou>:RPWP;co;user

dsacls ou=<twoja_nazwa_ou>,dc=<twoja_nazwa_dc>,dc=com /I:S /G <twoja_nazwa_dc>\<twoja_nazwa_dane_ou>:RPWP;l;user

dsacls ou=<twoja_nazwa_ou>,dc=<twoja_nazwa_dc>,dc=com /I:S /G <twoja_nazwa_dc>\<twoja_nazwa_dane_ou>:

RPWP;postalCode;user


RPWP;postOfficeBox;user

dsacls ou=<twoja_nazwa_ou>,dc=<twoja_nazwa_dc>,dc=com /I:S /G <twoja_nazwa_dc>\<twoja_nazwa_dane_ou>:RPWP;st;user


RPWP;streetAddress;user

dsacls ou=<twoja_nazwa_ou>,dc=<twoja_nazwa_dc>,dc=com /I:S /G <twoja_nazwa_dc>\<twoja_nazwa_dane_ou>:RPWP;telephoneNum

ber;user



prawa do drugiego plus pewne do-datkowe uprawnienia. Przyjrzymy się takim potencjalnym grupom.

Grupa pierwsza administra-torów powinna zawierać ogólne zasady zarządzania wcześniej stworzonego katalogu obiektów. Ta grupa powinna być przeznaczona dla wstępnie przeszkolonych ad-ministratoró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żyt-kowników, zmiany hasła, odbloko-wywania 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 modyfiko-wać konta administracyjne grupy pierwszej, a także zarządzać kontami użytkowników. Mają moż-liwość usunięcia obiektów stacji roboczych, dodawania, modyfiko-wania, usuwania obiektów Server, Contact i Shared Folder.

Kolejna grupa to grupa Regional Admins. Ta grupa wychodzi poza obręb własnej struktury Organiza-tional Unit. Nie może zarządzać in-nymi strukturami regionalnymi OU. Konto Regional Admin powinno być rozważane jako wysoce uprzywi-lejowane. 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 Organi-zational Unit, co stwarza pewne zagrożenie, że tworzone obiekty mogą nie być zarządzane przez administratorów o niższych upraw-nieniach.

Wiele struktur organizacyjnych posiada scentralizowany help desk. Ta rola wypełnia listę administra-toró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łon-kostwo w każdej grupie Regional Admins. Zapewnia to najwyższej ja-kości punkt eskalacji dla wszystkich administratorów danych, jak i służy jako punkt dostępu dla spraw do przekazania dalej do grupy admini-stratorów usług.

Model Organizational Unit i Security GroupGdy role są zdefiniowane, w organi-zacji musimy stworzyć model Orga-nizational 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 zaimplemen-tować twoją strukturę OU.

Mając to na uwadze, OU nad-rzę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 od-dzielny OU, by prezentować własny region mający dyskretny zespół za-rzą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. Administra-torzy IT muszą trzymać się określo-nych zasad. Jeśli rozszerzenie jest wymagane dla jednego regionu, struktura OU powinna być rozsze-rzona dla wszystkich regionów. To może być na początku trudne, ale jeśli organizacja zapewnia podsta-

wowe przechowywanie dla obiektów, możliwe. Wreszcie, stwórz oddzielne podgrupy administracyjne i konta do usuwania możliwości administracyj-nych, 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 Do-main 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 kontKluczem do prawidłowego modelu delegowania uprawnień jest stwo-rzenie 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 da-nej roli i nic więcej. Niestety wielu ad-ministratorów sądzi, że do bieżących zadań oraz przeglądania zasobów sieci czy czytania poczty, również pomocne będą im uprawnienia ad-ministratorskie.

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 aplika-cje codziennego użytku, ale takimi, które celują w administratorów.

By to osiągnąć bez konieczno-ści wylogowywania się użyj serwi-su Secondary Logon (Runas.exe). To zezwoli użytkownikowi zwięk-szyć uprawnienia, zapewniając inny zestaw uprawnień, gdy są uru-chamiane skrypty lub pliki wykony-walne na serwerach lub stacjach roboczych.

Mimo że koncepcja używania kont o niższych uprawnieniach jest prosta, organizacje często z nieuf-noś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 otrzymy-wania bezpośrednich wiadomości pocztowych na kontach o uprawnie-

hakin9 Nr 5/2007 www.hakin9.org

Obrona

6

niach wyższych. To jakże proste roz-wiązanie w kolejny znaczący sposób obniża używanie takich kont rutyno-wo do zadań nieadministracyjnych.

Delegowanie uprawnieńFinalny krok wdrożenia modelu delegowania uprawnień to jego wdrożenie, czyli delegacja upraw-nień w Active Directory. W tym celu należy skonfigurować dostęp do ac-cess control entries (ACEs) oraz ac-cess 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. De-legowanie uwzględnia podstawowe operacje na obiektach, m.in. przeglą-danie obiektów, tworzenie obiektów z uprzednio predefiniowanych, zmia-na atrybutu czy bezpieczeństwo. Poza nimi AD definiuje Extended Rights, które umożliwiają na opera-cje, takie jak wyślij jako i zarządzaj topologią replikacji.

By zaimplementować model delegowania uprawnień grupy i pod-grupy 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 wbudowa-nym grupom gdzie możliwe. Jeśli np.: określone wpisy DNS muszą być dokonane, nie musisz delego-wać 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ęk-szone poprzez Group Policy w taki sposób, aby zapewnić dodatkowe uprawnienia wymagane do zarzą-dzania określonymi klasami syste-mów poprzez określoną rolę.

Podczas przypisywania upraw-nień, używając delegowania uprawnień, powinno się limitować lub całkowicie eliminować używa-nie 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 upraw-nień 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 obiek-tów celu.

Jest wiele narzędzi, których możesz użyć w celu prawidłowego ustalenia zasad modelu delegowa-nia 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 katalo-gu to DSACLS.EXE, Jeśli flaga dzie-dziczenia będzie źle zdefiniowana narzędzie nie zadziała prawidłowo. Bardzo ważne jest testowanie na-rzę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 case-sensitive:

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 wy-magany 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 przy-kład może wyglądać tak:

dsacls ou=<twoja_nazwa_ou>,dc=<twoja_

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 ko-niecznych, 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 atry-butu 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 kontek-stowe w Active Directory Users and Computers ogranicza listę nowych obiektów, jakie mogą zostać stwo-rzone przez osobę z takimi wydele-gowanymi uprawnieniami.

DSACLS może również służyć do zautomatyzowania złożonego zbioru uprawnień. Poniżej przykład zasto-sowania komend do delegowania uprawnień, by ustawiać powszechne atrybuty ponad obiektami użytkowni-kó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 zdefinio-wanymi rolami.

Innym narzędziem jest DSRE-VOKE.EXE, zezwalające admi-nistratorom lokalizować i usuwać zdelegowane uprawnienia dla spe-cyficznych zasad bezpieczeństwa dla obiektów w ramach katalogu. To narzędzie może być użyteczne, jest ono specyficzne dla zasad bezpie-



czeństwa i nie wpływa na zagnież-dżone członkostwo wewnątrz grup bezpieczeństwa.

Poza tymi narzędziami, uru-chamianymi z linii poleceń, wysoce zalecane jest użycie User Rights Assignment i Restricted Groups z Group Policy. User Rights Assign-ment umożliwia administratorom IT rozszerzenie lub usunięcie niskich uprawnień (zdalny dostęp, restart systemu) dla różnych grup użytkow-nikó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 delego-wania uprawnień Active Directory.

PodsumowanieTworzenie 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 zdefiniowa-nie jasnych ról. Należy limitować role do małych, zarządzalnych grup. Balansowanie jest trudne, zbyt wiele zmian spowoduje stworzenie ról nig-dy nie wykorzystywanych, natomiast za mało nie zezwoli na właściwy po-dział obowiązków.

Należy pamiętać podczas defi-niowania zadań, by grupować je pod względem częstotliwości, ważności i trudności. Po jednokrotnym zdefi-niowaniu zwróć uwagę na wdrożenie zestawów przypadków, które pomo-gą zidentyfikować, które role można, a których nie należy zautomatyzo-wać w procesie testowania. Dobrze przygotowane pozwolą przekonać osoby z zarządu do słusznej decyzji oraz pomogą w ewentualnych pro-blemach w przyszłości.

Na koniec, zawsze warto przygo-tować praktyczny test, przed wdroże-niem modelu delegowania uprawnień. Pamiętaj, że ułatwienie równa się jakości wspierania i stabilności mo-delu delegowania. Taki model będzie pełnił kluczową rolę w kontroli upraw-nień administratorskich w środowisku twojego Active Directory. l

Z artykulu dowiesz sie Powinieneś wiedzieć Jak ... · Jak delegować uprawnienia w Active...

Documents

Transcript of Z artykulu dowiesz sie Powinieneś wiedzieć Jak ... · Jak delegować uprawnienia w Active...