Windows Server 2008

Projektowanie produktywnych struktur jednostek organizacyjnych Udostępnij na: Facebook

Autor: Ken St. Cyr

Opublikowano: 14 listopada 2008

Zawartość strony
 Reguła 1: Zasady grup   Reguła 1: Zasady grup
 Reguła 2: Delegacja   Reguła 2: Delegacja
 Reguła 3: Administracja obiektami   Reguła 3: Administracja obiektami
 Wybór modelu   Wybór modelu
 Model płytki (Shallow Model)   Model płytki (Shallow Model)
 Model geograficzny (Geographic Model)   Model geograficzny (Geographic Model)
 Model bazujący na typach (Type-Based Model)   Model bazujący na typach (Type-Based Model)
 Dokumentowanie projektu   Dokumentowanie projektu

Nie należy nie doceniać wagi i złożoności problemu projektowania dobrej struktury jednostek organizacyjnych (Organizational Unit - OU). Jak wynika z doświadczeń autora niniejszego artykułu, działy IT obierają często jeden z dwóch niewłaściwych kierunków: kładą zbyt duży nacisk na strukturę OU lub nie poświęcają jej należytej uwagi. Każdy z tych kierunków może prowadzić do problemów związanych z modelem Active Directory®.

Przecenienie roli struktury OU niepotrzebnie odciąga uwagę od innych obszarów projektu Active Directory, takich jak planowanie topologii witryny lub rozmiaru kontrolera domeny. Z drugiej strony, gdy opracowanie jednostek organizacyjnych jest odkładane na dalszy plan, cierpią na tym zasady grupy oraz delegacja.

Jednym z argumentów, które słyszy się w takich sytuacjach, jest stwierdzenie, że struktura OU jest elastyczna i jeśli okaże się nieodpowiednia, można ją zmienić w przyszłości. To prawda, że struktura OU jest elastyczna, jednak administratorzy często przekonują się, iż dokonanie modyfikacji działającej struktury OU jest trudniejsze niż im się początkowo wydawało. Oczywiście można dodać nowe jednostki organizacyjne, ale nie jest łatwo uporządkować istniejące.

Słabo zaplanowana struktura OU ma skłonność do wymykania się spod kontroli. Gdy w katalogu tworzony jest nowy obiekt, a administrator nie wie, w którym miejscu struktury OU ma go umieścić, może stworzyć nową jednostkę organizacyjną lub umieścić obiekt w niewłaściwym miejscu. Oba scenariusze niosą za sobą pewne zagrożenia. Nowa jednostka organizacyjna jest łatwa w tworzeniu, ale na dłuższą metę trudna w śledzeniu. Nieograniczone tworzenie jednostek organizacyjnych przyczynia się do powstania chaotycznej struktury OU i do katalogu mogą łatwo zakradać się nieudokumentowane elementy. Z drugiej strony, jeśli obiekt dodany zostanie do niewłaściwej, istniejącej jednostki organizacyjnej, może zostać objęty przez nieodpowiednie zasady bądź uprawnienia obiektu mogą zostać oddelegowane do nieodpowiednich użytkowników.

Projektując struktury OU, warto mieć na uwadze proste równanie: prostota + możliwość dostosowywania = trwałość. Jeśli projekt jest zbyt prosty, może być trudny w dostosowywaniu, a wtedy będzie musiał być zbyt często modyfikowany. Natomiast zbytnia elastyczność projektu wiąże się często z nadmiernym rozdrobnieniem i prowadzi do zbyt dużego skomplikowania.

Istnieją trzy podstawowe reguły, które mogą pomóc w podejmowaniu decyzji projektowych i dotyczą one zasad grupy (Group Policy), delegacji oraz administracji obiektami. Reguły te można podsumować przy użyciu trzech pytań, które powinniśmy sobie zadać i które pomogą w zapewnieniu, że tworzona przez nas struktura OU zda egzamin czasu oraz zmian organizacyjnych:

1. Czy nowa jednostka organizacyjna musi zostać stworzona, aby można było zastosować dla niej unikalny obiekt zasad grupy (Group Policy Object - GPO)?

2. Czy wybrana grupa administratorów musi posiadać uprawnienia do obiektów w tej jednostce organizacyjnej?

3. Czy nowa jednostka organizacyjna ułatwi administrowanie znajdującymi się w niej obiektami?

Jeśli odpowiedź na którekolwiek z tych pytań brzmi "tak", prawdopodobnie warto stworzyć jednostkę organizacyjną. Jeśli odpowiedź na wszystkie trzy pytania brzmi "nie", należy jeszcze raz przemyśleć układ i upewnić się, że nie istnieje inny, bardziej dopasowany projekt. Jednak zanim zagłębimy się w ten temat i poznamy metody stosowania wspomnianych reguł, warto zrozumieć, dlaczego są one tak istotne.

Reguła 1: Zasady grup

Pierwsza reguła projektu OU mówi, iż należy wziąć pod uwagę obiekty zasad grupy, które będą stosowane dla jednostki organizacyjnej. Obiekt GPO pozwala nam konfigurować ustawienia dla użytkowników oraz komputerów w egzekwowalny sposób. Możemy definiować wiele obiektów GPO w usłudze Active Directory i stosować je dla całej domeny, różnych jednostek organizacyjnych, a nawet witryn w domenie. Obiekty GPO dzielą się na dwie kategorie: dla użytkowników i dla komputerów.

Zarówno zasady komputera, jak i zasady użytkownika mogą być definiowane w tym samym obiekcie GPO. Sekcja Konfiguracja użytkownika (User Configuration) w obiekcie GPO definiuje przede wszystkim wrażenia użytkownika po zalogowaniu. Tego typu ustawienia znajdują się również w sekcji Konfiguracja komputera (Computer Configuration), ale sekcja ta zawiera również więcej ustawień związanych z zabezpieczeniami komputera, które określają m.in. kto może lokalnie zalogować się na komputerze oraz jak szyfrowane są dane.

Oto pewne podstawowe zasady, które należy mieć na uwadze, definiując jednostki organizacyjne wspierające obiekty GPO. Po pierwsze, to że zasady użytkownika i komputera mogą być definiowane w tym samym obiekcie GPO, wcale nie oznacza, że dobrym pomysłem jest umieszczanie obiektów użytkowników i komputerów w tej samej jednostce organizacyjnej. Łączenie ich w tym samym obiekcie GPO utrudnia rozwiązywanie problemów wynikających z ich zastosowania. Staje się to bardzo oczywiste, gdy włączony jest tryb sprzężenia zwrotnego zasad.

Po drugie, wiele osób zapomina, iż można stosować obiekty GPO na poziomie witryny i projektuje struktury OU tak, aby zamodelować strukturę swojej witryny. Jest to popularny model projektowy OU, zwany Modelem geograficznym (Geographic Model). Model ten zostanie omówiony w dalszej części tego artykułu. Trzeba zaznaczyć, że model geograficzny ma ustabilizowaną pozycję wśród projektów OU. Jednak jak będziemy mogli przekonać się później, zdaniem autora niniejszego artykułu stosowanie obiektów GPO nie powinno być główną pobudką do implementowania tego modelu.

Ponadto gdy planujemy własną strukturę OU w kontekście obiektów GPO, powinien przyświecać nam cel wyeliminowania złożoności. Należy upewnić się, że jednostka organizacyjna przyczynia się do zachowania płynności dziedziczenia obiektów GPO. Jeśli jednostka organizacyjna zawiera serwery, które wymagają tej samej zasady co inne serwery, warto rozważyć umieszczenie obiektów komputera w szerszej jednostce organizacyjnej Serwery (Servers) i stworzenie wielu jednostek organizacyjnych dla różnych typów serwerów pod jednostką organizacyjną Servers (patrz Rysunek 1). To może uprościć stosowanie zasad, gdyż każdy obiekt komputera w niższych jednostkach organizacyjnych otrzyma zasady z jednostki Servers, jak również wszelkie inne zasady charakterystyczne dla określonego typu serwera.

Rysunek 1: Tworzenie wielu jednostek organizacyjnych dla różnych typów serwerów.

Inna podstawowa zasada mówi, aby sprawdzać, czy nie tworzymy bądź nie łączymy wielu obiektów GPO bez potrzeby. Korzystając z obiektu GPO, możemy stworzyć jedną zasadę i zastosować ją dla wielu jednostek organizacyjnych. Czasem jest to pomocne, ale może być również szkodliwe. Jeśli musimy zmienić ustawienia obiektu GPO w nadmiernie skomplikowanym systemie połączonych obiektów GPO, możemy przypadkowo objąć modyfikacją nieodpowiednie obiekty. Im więcej połączeń tworzymy, tym trudniejsze jest określenie zakresu zasady. Ponadto należy unikać tworzenia dodatkowych zasad, które posiadają te same ustawienia co inne zasady. Jeśli sytuacja ta powtarza się dość często, warto rozważyć zmodyfikowanie struktury OU w celu zastosowania nowego modelu dziedziczenia GPO.

I na zakończenie, należy prawie zawsze tworzyć nową jednostkę organizacyjną dla obiektów użytkownika i obiektów komputera. Domyślnie obiekty użytkownika i komputera są umieszczone w kontenerach, co nie pozwala bezpośrednio łączyć z nimi obiektów GPO. Obiekty GPO można stosować dla kontenerów użytkownika i komputera z poziomu domeny, ale jeśli dziedziczenie nie zostanie zablokowane w innym miejscu, zasady będą stosowane dla każdego użytkownika i komputera w domenie. W systemie Windows Server® 2003 można użyć narzędzi rediruser.exe oraz redircomp.exe do zmodyfikowania domyślnej lokalizacji dla obiektów użytkownika i obiektów komputera na stworzoną dla nich jednostkę organizacyjną.

 Do początku strony Do początku strony

Reguła 2: Delegacja

Ważne jest, aby tworzyć strukturę OU w sposób spójny z delegowaniem uprawnień w domenie. Należy pamiętać, że gdy uprawnienia są delegowane w usłudze Active Directory, zmiany uprawnień są dokonywane tylko dla obiektu. A zatem jeśli przyznamy użytkownikowi Pełną Kontrolę nad określonym obiektem komputera, osoba ta będzie mogła modyfikować atrybuty obiektu, ale nie będzie posiadała uprawnień administratora na tym komputerze.

Oto kilka zalecanych praktyk delegacji przydatnych podczas projektowania struktury OU:

Projektowanie z myślą o dziedziczeniu uprawnień Powiedzmy na przykład, że chcemy, aby administratorzy Tier 1 mogli zmieniać hasła (Change Password) dla większości kont. Istnieje specjalna grupa użytkowników, dla których administratorzy nie powinni mieć możliwości resetowania haseł, ale powinni mieć możliwość modyfikowania nazw wyświetlanych (Change Display Names).

Istnieją dwie możliwości rozwiązania tej kwestii. Możemy stworzyć dwie osobne, równoległe jednostki organizacyjne i oddzielić użytkowników specjalnych od zwykłych użytkowników. Jednak to oznaczałoby, że gdybyśmy chcieli zmienić opcje delegacji dla wszystkich użytkowników, musielibyśmy zmodyfikować uprawnienia w dwóch osobnych miejscach. Jest to również niezgodne z zaleceniem, aby bez potrzeby nie tworzyć zasad o wielu połączeniach (patrz Rysunek 2 ).

Rysunek 2: Utrzymywanie dwóch osobnych, równoległych jednostek organizacyjnych.

Inna opcja zakłada stworzenie zagnieżdżonej jednostki organizacyjnej i umieszczenie bezpośredniej odmowy uprawnienia dla jednostki organizacyjnej, w której znajdują się użytkownicy specjalni. Każdy ekspert od delegacji powie, że bezpośrednia odmowa nie jest pożądana, ale w tym przypadku musimy wybrać mniejsze zło (patrz Rysunek 3). Możemy albo zastosować duplikację i utrzymywać ustawienia w dwóch osobnych jednostkach organizacyjnych albo umieścić bezpośrednią odmowę dla jednej z jednostek organizacyjnych. Bezpośrednia odmowa jest w rzeczywistości lepszą długoterminową decyzją.

Rysunek 3: Wykorzystanie bezpośredniej odmowy uprawnienia.

Uwzględnienie kontenera AdminSDHolder Niniejszy przykład będzie działał dobrze, o ile użytkownicy specjalni nie należą do jednej z grup administratorów (Administratorów domeny, Administratorów schematu, Administratorów przedsiębiorstwa lub Administratorów), ponieważ uprawnienia dla kont w tych grupach są obsługiwane w inny sposób. Rozwiązanie to ma na celu zredukowanie ryzyka, iż uprawnienia do konta administratora zostaną przez przypadek przyznane nieuprawnionej osobie.

Jeśli stworzymy osobną jednostkę organizacyjną dla administratorów, przekonamy się, że delegowane im uprawnienia stale znikają. Dzieje się tak z powodu obiektu AdminSDHolder, czyli specjalnego kontenera stosującego swoją listę kontroli dostępu dla wszystkich kont administratorów z określoną częstotliwością. W efekcie wszystkie zmiany delegacji dokonane dla kont administratorów zostaną wycofane, jeśli nie zostały dokonane również dla kontenera AdminSDHolder. A zatem w kontekście delegacji oddzielanie kont administratorów od innych kont nie jest pożądane. Jednakże zalecane jest odseparowanie kont administratorów na potrzeby Zasad grup, w szczególności w przypadku systemu Windows Server 2008, w którym można posiadać wiele zasad hasła.

 Do początku strony Do początku strony

Reguła 3: Administracja obiektami

Jednostka organizacyjna powinna ułatwiać administrowanie obiektami. Grupowanie obiektów w tej samej jednostce organizacyjnej często ułatwia dokonywanie masowych zmian. Przystawka Użytkownicy i komputery usługi Active Directory (Active Directory Users and Computers) umożliwia nam edytowanie określonych atrybutów dla wybranego zbioru obiektów. A zatem gdy regularnie musimy modyfikować określony atrybut grupy obiektów, możemy ułatwić sobie zadanie, umieszczając wszystkie obiekty w tej samej jednostce organizacyjnej.

Jest to szczególnie przydatne w przypadku dokonywania uaktualnień przy pomocy skryptów. Języki skryptowe znacznie ułatwiają wyliczanie wszystkich obiektów w jednostce organizacyjnej i obsługiwanie ich jeden po drugim. Inną opcją jest wyszukiwanie i modyfikowanie każdego obiektu indywidualnie. Czasem proste umieszczenie obiektów w tej samej jednostce organizacyjnej pozwala oszczędzić godziny niepotrzebnej pracy administracyjnej tygodniowo.

Innym sposobem na ułatwienie administracji obiektami jest wydzielenie obiektów do innej jednostki organizacyjnej w oparciu o ich typ. Stworzenie osobnej jednostki organizacyjnej dla obiektów drukarki lub udostępnionych udziałów eliminuje konieczność odsiewania tych obiektów podczas wykonywania zadań administracyjnych na innych obiektach w jednostce organizacyjnej. Praktyka ta jest również zgodna z zaleceniem, aby nie grupować kont użytkowników i komputerów w tej samej jednostce organizacyjnej.

 Do początku strony Do początku strony

Wybór modelu

Po zapoznaniu się z omówieniem reguł projektu OU, możemy dokładniej przyjrzeć się pewnym typowym modelom projektowym. Ze względu na ograniczenie rozmiaru niniejszego artykułu przedstawionych zostanie jedynie kilka wybranych modeli, ale warto mieć świadomość, że istnieje ich dużo więcej. Co więcej, wcale nie musimy ograniczać się do pojedynczego modelu. Możemy wybrać elementy każdego z nich i zbudować własny model hybrydowy dostosowany do określonych potrzeb.

Prawie każdy model działa dobrze na małą skalę. Jednak w miarę jak przedsiębiorstwo rozwija się, nasza zdolność kontrolowania środowiska maleje. A zatem należy najpierw dokładnie przetestować wybrany model w odpowiednim środowisku testowym. Warto również pamiętać, że choć na początku można łatwo zmienić strukturę OU, staje się to tym trudniejsze, im dłużej jest ona w użyciu.

 Do początku strony Do początku strony

Model płytki (Shallow Model)

Nazwa modelu płytkiego wynika z faktu, że przeważnie jest on płaski. W modelu tym kilka jednostek organizacyjnych wyższego poziomu zawiera większość obiektów (patrz Rysunek 4). Model ten jest wykorzystywany głównie w mniejszych firmach, w których istnieje mały dział IT, nie ma wielu różnych oddziałów lub użytkownicy pełnią wiele ról. Autor niniejszego artykułu z reguły odradza stosowanie więcej niż dziesięciu podrzędnych jednostek organizacyjnych, choć firma Microsoft sugeruje, że dopiero przekroczenie limitu piętnastu podrzędnych jednostek organizacyjnych ma wyraźny wpływ na wydajność.

Rysunek 4: Model płytki posiada kilka jednostek organizacyjnych wyższego poziomu, które zawierają większość obiektów.

Jeśli osoba zajmująca się zasobami ludzkimi jest jednocześnie osobą zajmującą się listą płac, nie ma sensu tworzyć dwóch osobnych jednostek organizacyjnych dla Zasobów Ludzkich oraz Listy płac. W modelu płytkim wszystkie obiekty użytkownika mogą być zgrupowane w jedną wielką jednostkę organizacyjną Accounts lub mogą znajdować się w domyślnym kontenerze Users. Jednak należy przynajmniej oddzielić obiekty użytkownika od obiektów komputera.

W przypadku tego modelu autor artykułu zaleca również pójście o krok dalej i oddzielenie stacji roboczych od serwerów. Dzięki temu można przynajmniej stosować różne zasady grup bez konieczności definiowania obiektu GPO, który wykorzystuje kwerendę Windows® Management Instrumentation (WMI) do odfiltrowywania stacji roboczych lub serwerów.

Jedną z zalet utrzymywania szerokiej a nie głębokiej struktury OU jest krótszy czas operacji przeszukiwania Active Directory. Autor niniejszego artykułu z reguły zaleca, aby nie schodzić głębiej niż dziesięć podrzędnych jednostek organizacyjnych. Model ten nie zapewnia bardzo szczegółowej kontroli nad obiektami, jednak w przypadku zarządzania obiektami w małej firmie nie jest to wcale konieczne. A zatem choć model ten trudno byłoby wykorzystać z powodzeniem w dużym przedsiębiorstwie, w mniejszych organizacjach spisuje się on całkiem dobrze.

 Do początku strony Do początku strony

Model geograficzny (Geographic Model)

W modelu geograficznym możemy rozdzielić jednostki organizacyjne dla różnych regionów geograficznych. Model ten jest najodpowiedniejszy dla organizacji, które posiadają zdecentralizowane działy IT, ale nie chcą ponosić kosztów związanych z działaniem wielu domen (patrz Rysunek 5 ).

Rysunek 5: Model geograficzny rozdziela jednostki organizacyjne według regionów geograficznych.

Powiedzmy, że mamy oddziały w Atlancie, Baltimore oraz Seattle. Jeśli każda lokalizacja zarządza swoimi własnymi użytkownikami i komputerami, podejście to może być odpowiednie z punktu widzenia delegacji. Jednak co się stanie, gdy użytkownik z Seattle przyleci do Baltimore na szkolenie, a następnie zablokuje swoje konto. Pracownicy działu IT z Baltimore mogą nie być w stanie mu pomóc, jeśli nie zostały do nich oddelegowane uprawnienia do konta tego użytkownika. Gdy w Baltimore jest godzina ósma rano, w Seattle jest dopiero piąta, co oznacza, że użytkownik będzie musiał godzinami oczekiwać, aż ktoś w biurze w Seattle będzie mógł udzielić mu pomocy.

Niektóre międzynarodowe korporacje wykorzystują model "podążający za słońcem", w którym telefony do działu Help Desk są przekierowywane do lokalizacji znajdującej się w strefie czasowej, w której aktualnie wypadają standardowe godziny urzędowania. To oznacza, że firma nie musi posiadać całodobowego działu Help Desk w każdej lokalizacji, a mimo to może oferować swoim pracownikom stałą pomoc, np. w odblokowywaniu kont, gdy jest to konieczne.

W przypadku tego modelu tworzenie osobnych jednostek organizacyjnych w oparciu o geograficzną lokalizację prawdopodobnie nie jest wyborem najlepiej dopasowanym do potrzeb operacyjnych. Wymagałoby oddelegowania do każdego regionalnego działu Help Desk osobnych uprawnień do wszystkich jednostek organizacyjnych użytkowników. Jednak gdy lokalizacje posiadają swoje własne działy IT, model geograficzny może faktycznie być dobrym modelem dla organizacji.

Model geograficzny trudno jest również zastosować w pojedynczej domenie ze względu na naturę działania domeny. Domena ma skłonności do posiadania innego modelu zabezpieczeń niż inne domeny. Jest to bardziej oczywiste w przypadku aplikacji obejmujących swym zasięgiem całą korporację, takich jak Microsoft® Exchange.

Serwer Exchange w Atlancie może posiadać inne zasady obsługi wiadomości, ale dla wszystkich serwerów Exchange w przedsiębiorstwie zastosowane są prawdopodobnie te same obiekty GPO. W takiej sytuacji, umieszczenie serwerów Exchange w osobnych jednostkach organizacyjnych w oparciu o regiony mogłoby spowodować, że niechcący połączymy ten sam obiekt GPO z wieloma jednostkami organizacyjnymi. W aspekcie delegacji musimy zadać sobie pytanie, czy administratorzy Exchange naprawdę potrzebują unikalnych uprawnień do obiektów komputera dla serwerów Exchange. W większości przypadków gdy obiekty komputera są rozdzielane na geograficzne jednostki organizacyjne, dzieje się tak ze względu na zasady grup, nie na potrzeby delegacji.

 Do początku strony Do początku strony

Model bazujący na typach (Type-Based Model)

Model bazujący na typach klasyfikuje obiekty według ich zastosowań (patrz Rysunek 6). Jakiego typu obiekt użytkownika stworzyliśmy ostatnio, czy było to zwykłe konto użytkownika, konto administratora czy konto usługi? W modelu bazującym na typach każdy z tych obiektów jest traktowany inaczej.

Rysunek 6: Model bazujący na typach grupuje obiekty według ich funkcji.

W większości przypadków powinniśmy rozróżnić klasyfikacje obiektów użytkowników dla zasad. Nasze zasady będą najprawdopodobniej różniły się w zależności od typu konta użytkownika. Na przykład, zezwalanie pracownikom na logowanie się do komputera przy użyciu konta usługi stanowi z reguły złą praktykę biznesową. Hasła kont usług są z reguły znane wielu osobom, a zatem gdy ktoś zaloguje się przy użyciu konta usługi, jego tożsamość pozostaje praktycznie anonimowa. Gdyby wydarzyło się coś złego, mielibyśmy problem z określeniem, który użytkownik był zalogowany w momencie wystąpienia zdarzenia. W tym przykładzie musimy ustalić dla kont usług zasadę, która uniemożliwia interaktywne logowanie. To doskonale pasuje do modelu hierarchicznego pokazanego na Rysunku 3.

W tej sytuacji moglibyśmy wykorzystać dziedziczenie obiektów GPO. Na przykład moglibyśmy określić zasadę Wszyscy Użytkownicy, która zawiera ustawienia dotyczące wszystkich obiektów użytkownika. Dodatkowo moglibyśmy posiadać odrębną zasadę dla kont usług, która bazuje na zasadzie Wszyscy Użytkownicy. Takie podejście pozwala zapewnić, że konta usługi mają ten sam podstawowy zestaw zasad co wszystkie pozostałe konta, jak również indywidualne ograniczenia logowania.

Takie podejście sprawdza się również podczas delegacji, gdzie wykorzystujemy dziedziczenie uprawnień zamiast dziedziczenia GPO. Przypuśćmy, że chcemy, aby administratorzy Tier 2 mieli możliwość resetowania haseł dla wszystkich kont za wyjątkiem kont administratorów Tier 3. W przypadku płaskiej struktury OU musielibyśmy delegować uprawnienia do każdej jednostki organizacyjnej, która przechowuje konta użytkowników. Jednak w modelu bazującym na typach ze strukturą hierarchiczną możemy nadać grupie Tier 2 uprawnienia do "resetowania hasła" dla jednostki organizacyjnej Accounts, a następnie w jednostce organizacyjnej Tier 3 moglibyśmy po prostu nie dziedziczyć uprawnień, a nawet ustawić bezpośrednią odmowę uprawnienia do resetowania haseł dla Tier 2.

Podejście to sprawdza się także dla obiektów komputera. Serwery oraz stacje robocze mogą zostać rozdzielone, umożliwiając stosowanie dla nich innych zasad. Serwery mogą zostać dodatkowo podzielone ze względu na funkcje (patrz Rysunek 1). W omawianym projekcie możemy ustawić dla jednostki organizacyjnej Servers zasadę wysokiego poziomu, która wpływa na wszystkie serwery. A następnie ustawić osobne zasady dla każdej jednostki organizacyjnej niższego poziomu.

Powiedzmy na przykład, że mamy konto usługi Microsoft Operations Manager (MOM). W tym warstwowym modelu możemy stworzyć obiekt GPO MOM i zastosować go dla jednostki organizacyjnej MOM Servers. A następnie wewnątrz tego obiektu GPO możemy nadać koncie usługi MOM prawo do logowania w roli usługi. Prawo to obejmie jedynie serwery MOM w tej jednostce organizacyjnej. Serwery MOM nadal znajdować się będą w zasięgu obiektu GPO Servers z jednostki organizacyjnej wyższego poziomu Servers, ale będą również korzystać ze specjalistycznego obiektu GPO MOM połączonego z jednostką organizacyjną MOM.

 Do początku strony Do początku strony

Dokumentowanie projektu

Zaprojektowanie struktury OU, która przetrwa wiele zmian wprowadzanych w środowisku Active Directory, może przynieść wiele satysfakcji. Jednak trzeba także w określony sposób śledzić dynamiczne właściwości jednostek organizacyjnych. W przeciwnym wypadku można łatwo utracić kontrolę nad środowiskiem. Kiedy trzeba wprowadzić określone zmiany i konieczne jest dodanie lub usunięcie jednostki organizacyjnej, muszą istnieć jasne wytyczne jak zapewnić zgodność modelu z modelem projektowym i przestrzeganie trzech podstawowych reguł. Z tego powodu potrzebny jest dobrze udokumentowany projekt.

Firma Microsoft przedstawia zalecenia dotyczące dokumentacji w zestawie Resource Kit Windows Server. Wskazówki te są odpowiednie w sytuacji, gdy struktura jest stabilna i nie powinna ulegać wielu zmianom. Jednak większość organizacji posiada bardzo dynamiczną strukturę, która jest często modyfikowana. Z tego względu istnieją również pewne istotne wskazówki, których przestrzeganie pozwala zapewnić, iż struktura OU będzie odpowiednio udokumentowana i gotowa do wspierania dynamicznego środowiska.

Należy sprawdzić, czy wszystkie informacje są przydatne Autor niniejszego artykułu jest przekonany, że dokumentowanie ma sens. Jednak zbyt wiele dokumentów operacyjnych zawiera tyle zbędnej treści, że trudno jest odnaleźć w nich istotne informacje. Nie należy wpadać pułapkę dokumentowania dla samego dokumentowania. Czy naprawdę musimy opisać wszystkie obiekty w każdej jednostce organizacyjnej lub udokumentować każdy wpis kontroli dostępu (ACE) na liście kontroli dostępu (ACL)? W przypadku dokumentacji jednostki organizacyjnej z reguły wystarczające są następujące informacje:

• Nazwa jednostki organizacyjnej

• Krótki opis

• Kto ją stworzył lub z kim należy kontaktować się w sprawie dodatkowych informacji lub zmian

• Kiedy została stworzona

Uaktualnienia nie powinny być utrudnione Gdy musimy mozolnie uaktualniać złożony dokument Microsoft Word, bardziej prawdopodobne jest to, że odłożymy wpisywanie uaktualnień na później. Nie ma w tym nic złego, o ile odkładamy odnotowanie małych zmian, ponieważ w planach mamy wprowadzenie dodatkowych informacji i chcemy zrobić wszystko naraz. Niestety ludzie często zapominają o tych małych zmianach lub po prostu stale je odkładają i w efekcie zadanie to nigdy nie zostaje wykonane. Z tego względu uaktualnianie dokumentu musi być bardzo łatwe, aby nie zniechęcać do jego przeprowadzania. W większości przypadków wystarczy prosty arkusz Microsoft Excel® z kilkoma kolumnami.

Dodawanie komentarzy do samych obiektów Obiekty OU posiadają atrybut opisu, w którym możemy umieszczać komentarze. A zatem zamiast wpisywać komentarze w dokumencie projektowym, warto rozważyć umieszczenie ich w atrybucie opisu, aby inne osoby mogły od razu stwierdzić, do czego służy dana jednostka organizacyjna. Jeśli musimy dołączyć więcej szczegółowych informacji, umieśćmy w atrybucie opisu krótkie objaśnienie, a dodatkowe informacje zamieśćmy w dokumencie OU.

Automatyzacja dokumentacji Możemy napisać skrypt, który zrzuca zawartość struktury OU do pliku tekstowego, arkusza Excel, a nawet pliku HTML. Skrypt ten powinien być uruchamiany każdej nocy jako zaplanowane w harmonogramie zadanie. Może być to bardzo przydatne, gdy umieszczamy komentarze w polu opisu jednostki organizacyjnej. Później wystarczy już tylko zrzucić atrybut opisu do pliku i automatycznie otrzymujemy kompletną i stale aktualną dokumentację struktury OU. Jeśli uruchamiając skrypt, zamiast nadpisywać istniejący dokument za każdym razem tworzymy nowy plik, możemy przechowywać historyczny zapis modyfikacji struktury OU w czasie.

Niestety większość administratorów uświadamia sobie wagę dobrej dokumentacji struktury OU dopiero wtedy, gdy okazuje się ona naprawdę potrzebna. Gdy o trzeciej nad ranem wydedukowanie, które jednostki organizacyjne zostały przypadkowo usunięte, bez przeprowadzenia przywracania staje się prawie niemożliwe.

Nie czekajmy aż to przytrafi się także nam. Autor tego artykułu zdecydowanie zachęca do przyjęcia proaktywnej postawy w tym obszarze i bezzwłocznego stworzenia dokumentu OU oraz przydzielenia osoby odpowiedzialnej za jego aktualizację. I jeśli będziemy przestrzegać reguły, iż dokumentacja powinna być łatwa w aktualizacji, okaże się to bardzo prostym zadaniem.

O autorze

Ken St. Cyr jest konsultantem firmy Microsoft z 10-letnim doświadczeniem w branży IT. Od początku powstania Active Directory zajmuje się projektowaniem i implementacją rozwiązań katalogowych bazujących na tej technologii.

 Do początku strony Do początku strony  

Windows Server 2008