Usługi katalogowe Active Directory to fundament Windows 2000. Ich wdrożenie powinno być dobrze zaplanowane nie tylko dlatego że bez nich praca systemu serwerowego nie jest możliwa, ale również z powodu korzyści, jakie można odnieść, planując właściwie ich strukturę.

W ramach planowania struktury Active Directory uwzględnić należy przede wszystkim zaprojektowanie architektury internetowego systemu nazw DNS. Podobnie jak Active Directory stanowią fundament Windows 2000, tak podstawą samych usług katalogowych jest właśnie DNS. Dla wielu dużych firm, które dotychczas wykorzystywały płaską strukturę DNS, migracja na Windows 2000 oznaczać będzie konieczność znaczącej restrukturyzacji DNS, a w wielu przypadkach całkowitą rezygnację z wykorzystywanej dotychczas struktury i opracowanie nowej, spełniającej już wymogi wielodomenowego środowiska pracy w Windows 2000.

Adresowania DNS nie należy nie doceniać. Wykorzystywane jest ono bowiem na każdym kroku pracy z nowym systemem. Również użytkownicy logować się mogą do systemu z podaniem swoich pełnych adresów poczty elektronicznej - w tym pełnej nazwy domenowej. Struktura nazwy domenowej określa w tym przypadku lokalizację domeny w ramach struktury Active Directory, co pozwala procesowi autoryzacyjnemu odwołać się do odpowiedniego kontrolera domeny, zdolnego zidentyfikować użytkownika.

Korzenie katalogów

Usługi katalogowe Active Directory w sposobie organizacji można porównać do budowy drzewa. Najważniejszym elementem każdego drzewa jest korzeń, którym w przypadku Active Directory jest domena nadrzędna (root domain). Jej adres internetowy w strukturze DNS powinien być taki sam jak nazwa domeny internetowej, wykupionej u operatora internetowego. W przypadku firmy Powietrze SA jest to nazwa POWIETRZE.COM.PL.

Według zaleceń Microsoftu, w sieciach wielodomenowych w ramach domeny nadrzędnej nie powinny być przechowywane żadne obiekty. Pełnić ma ona tylko funkcję łącznika pomiędzy domenami podrzędnymi tworzącymi drzewo katalogowe.

Rolę pnia drzewa katalogowego, będącego zaczątkiem jego korony, pełnią domeny podrzędne (child domains), które przeznaczone są do przechowywania obiektów zgrupowanych, np. w danej lokalizacji. Te domeny mogą być również nadrzędne w stosunku do kolejnych domen podrzędnych itd. Microsoft nie zaleca jednak tworzenia zbyt dużej liczby domen. Zamiast tego proponuje, aby w ramach konkretnej domeny posługiwać się grupowaniem poszczególnych obiektów w tzw. jednostki organizacyjne (Organization Unit - OU), które również mogą tworzyć strukturę hierarchiczną. Nawet jeśli sieć korporacyjna obejmuje wiele lokalizacji połączonych nie zawsze najszybszymi łączami, to znacznie lepiej z punktu widzenia zarządzania jest mieć jak najmniejszą liczbę domen. Prawdą jest, że kilka bardzo dużych domen spotęguje replikację pomiędzy poszczególnymi kontrolerami domenowymi, ale stosując techniki optymalizacji ruchu można ją znacznie zmniejszyć.

Wspomniane już wcześniej jednostki organizacyjne OU są największym usprawnieniem w dziedzinie usług katalogowych, jakie wprowadza Active Directory. Zapewniają one w dużej mierze taką funkcjonalność, jaką osiągało się dotychczas poprzez stosowanie oddzielnych domen, a jednocześnie nie wymagają delegowania do ich obsługi oddzielnych kontrolerów domeny. Przykładowo, pozwalają rozdzielić uprawnienia administracyjne w ramach grup roboczych czy działów firmy bez dawania takim administratorom niższego szczebla kontroli nad całą domeną, tak jak to było w domenach Windows NT Server 4.0.

Lasy

Ponad strukturą domen nadrzędnych (root domains), reprezentującą pojedyncze drzewa katalogowe, możliwe jest utworzenie struktury nadrzędnej nazwanej lasem (forest). Las może konsolidować dowolną liczbę drzew, co jest przydatne np. w przypadku łączenia ze sobą kilku firm (co w dzisiejszych czasach nie jest już rzadkością). Przykładowo, niezależne struktury Active Directory firm Powietrze SA i amerykańskiego producenta Air Ltd. mogłyby być połączone w jeden las katalogowy, co zapewniłoby możliwość wymiany informacji pomiędzy dwoma, niezależnymi strukturami Active Directory.

Fragmenty dobrze połączone

W przypadku dużych sieci, łączących wiele lokalizacji, istnieje możliwość wirtualnego podzielenia struktury Active Directory na tzw. site'y. Ideą takiego podziału jest optymalizacja pracy sieci i m.in. przyspieszenie autoryzacji użytkowników. Site'y z założenia powinny bowiem dzielić sieć na segmenty, wewnątrz których komunikacja odbywa się relatywnie szybko, ale komunikacja między nimi odbywa się przez linie o małej przepustowości. Przy takiej organizacji sieci użytkownik autoryzowany będzie przez kontroler domeny znajdujący się w tym site, w którym i on aktualnie się znajduje - bez konieczności oczekiwania na "przepchnięcie się" pakietów autoryzacyjnych przez wąskie gardło, jakim jest łącze do innych kontrolerów domeny.

Architektura site'ów przewiduje również optymalizację replikacji pomiędzy kontrolerami domenowymi. Wewnątrz site'u przebiega ona według standardowego scenariusza, ale pomiędzy site'ami może odbywać się znacznie rzadziej - tylko po to, by zminimalizować obciążenie łącza o małej przepustowości, jakie z założenia łączy dwa lub więcej site'ów.

Wytyczne dotyczące organizacji site'ów są bardzo jasne. W chwili konstruowania usług katalogowych Active Directory warto zacząć od umieszczenia całej sieci w jednym site. Dopiero potem obserwując natężenie ruchu na poszczególnych łączach, można dążyć do stworzenia nowych site'ów. Zawsze jednak należy kierować się prostą zasadą - im mniej site'ów, tym lepiej i tym prostsza jest konstrukcja sieci i replikacji pomiędzy poszczególnymi kontrolerami domenowymi.

Katalog globalny

Nieodłącznym elementem domeny Windows 2000 opartej na usługach katalogowych Active Directory jest globalny katalog (Global Catalog). Serwer taki, oprócz pełnienia funkcji, takich jak każdy kontroler domenowy, ma jeszcze pełny indeks wszystkich obiektów w danym lesie katalogowym (bez względu na to, z ilu domen się składa).

Podstawową zaletą stosowania serwerów pełniących funkcję globalnych katalogów jest możliwość szybkiego przeszukiwania całej struktury Active Directory, np. wyszukiwania z poziomu stacji roboczych, wyposażonych w klienta usług katalogowych, danych kontaktowych konkretnych użytkowników (wg dowolnego parametru). Global Catalog odpytywany jest zawsze wtedy, gdy poszukiwane przez użytkowników lub kontrolery domenowe obiekty nie są znajdowane w lokalnej domenie. Wymaga go również do swojej pracy oprogramowanie Active Directory Connector, zapewniające integrację pomiędzy serwerem komunikacyjnym Microsoft Exchange a Active Directory (piszemy o tym szerzej w artykule Spójne dane personalne).

Wdrożenie katalogów

Wbrew pozorom wprowadzenie Active Directory do firmy Powietrze SA nie będzie skomplikowaną operacją. Informatycy tej firmy zarządzają bowiem tylko jedną domeną Windows NT, tak więc nie muszą się martwić o tworzenie skomplikowanej struktury DNS ani usług katalogowych.

Przed migracją funkcję podstawowego serwera DNS (Primary DNS) pełnił serwer Saturn, na którym pracował system Windows NT Server 4.0. Po zaktualizowaniu serwera Neptun (pierwsza uaktualniana maszyna w sieci firmy Powietrze SA) procedura instalacyjna wymusiła instalację na tym serwerze oddzielnego serwera DNS, niezbędnego do poprawnej pracy również instalowanych na tym serwerze usług katalogowych Active Directory. Informatycy uznali, że nowy serwer DNS od chwili migracji pełnić będzie funkcję podstawowego serwera DNS w domenie Windows 2000. Aby jednak tak się stało, musieli przepisać wszystkie wpisy ze starego DNS pracującego na Saturnie (było ich zaledwie kilka - tylko nazwy serwerów firmowych z przyporządkowanymi im numerami IP oraz adres strony internetowej).

Informatycy wyszli z założenia, że nie będą zmieniali struktury DNS, gdyż środowisko jednodomenowe nie uzasadniałoby wprowadzania dodatkowych podziałów. Tak więc po zaktualizowaniu struktury domenowej do Active Directory wszystkie obiekty znalazły się tak naprawdę w tym samym miejscu, w którym były przed migracją - w ramach domeny internetowej POWIETRZE.COM.PL. Oznacza to, że domena nadrzędna (root domain) w Active Directory stała się jednocześnie jedyną domeną firmy Powietrze SA i nie zawiera ona pod sobą żadnych domen podrzędnych.

Pora na Saturna

Aby uniknąć ewentualnych kłopotów przy migracji serwera Saturn związanych z istnieniem dwóch serwerów typu Primary DNS, informatycy firmy Powietrze SA jeszcze przed przeprowadzeniem migracji całkowicie usunęli z tego serwera usługę DNS. Pozostał tam jednak serwer DHCP, który cały czas wskazywał jako docelowy serwer DNS, z którego powinny korzystać stacje klienckie, właśnie Saturna. Aby konfiguracji stało się zadość, administratorzy poprawili wpis wskazujący serwer DNS, umieszczając w nim adres IP serwera Neptun. Po wykonaniu tych zmian zaktualizowali serwer Saturn do systemu Windows 2000 i po aktualizacji uruchomili na nim program DCPROMO.EXE w celu jego awansowania do funkcji kontrolera domeny.

Ostatnim etapem konfiguracji środowiska Active Directory było skonfigurowanie Saturna jako serwera pełniącego funkcję globalnego katalogu. Informatycy zdecydowali się nie obciążać już tym zadaniem Neptuna, który - oprócz pełnienia funkcji kontrolera domenowego i serwera DNS - obsługuje również usługi plików i drukowania.