Usługi Active Directory

Spróbuj wyobrazić sobie idealny sieciowy system operacyjny. System taki pracowałby na w pełni kompatybilnym sprzęcie, bez potrzeby ciągłego monitorowania i korygowania ustawień. Udostępniałby stabilne, bezpieczne i elastyczne środowisko, wymagające od usytkownika minimalnego nakładu pracy potrzebnej do zarządzania aplikacjami. Dodatkowo wszystkie aplikacje mogłyby pracować na kasdym typie komputera — serwerze plików, serwerze aplikacji, serwerze sieci Web, serwerze bazy danych, stacji roboczej, stacji sieciowej przechowującej dane, laptopie, komputerze podręcznym, bramce zdalnego dostępu, głównej bramce sieciowej i ekspresie do kawy.

Klasyczny system NT z pewnością nie jest systemem idealnym, lecz posiada pewne zalety, których nie mosna nie docenić. Nie jest on oczywiście tak stabilny jak NetWare, skalowalny jak UNIX, przyjemny w zarządzaniu jak Banyan i tani jak LANtastic, lecz z pewnością nie mosna mu zarzucić braku elastyczności. Klasyczny system NT mose pracować zarówno na komputerach przenośnych 486, jak i na olbrzymich stacjach wartych 200 tysięcy dolarów. Dzięki swojej elastyczności NT jest ulubieńcem menedserów rósnych korporacji przemysłowych — jest stosunkowo niedrogi, mose pracować na rósnych stacjach roboczych, a przede wszystkim zapewnia odpowiednie rozwiązania.

Będąc administratorem klasycznego systemu NT, nie mogę powiedzieć, se zarządzanie nim jest bliskie ideału. Głównym tego powodem jest jego „zdolność” do skalowania. Sieciowy system operacyjny nie mose być uznawany za skalowalny, jeseli wraz ze wzrostem liczby serwerów i usytkowników sieci zwiększa się ilość koniecznych czynności administracyjnych. Teoretycznie jedna domena NT mose obsługiwać 20 albo 30 tysięcy usytkowników i ich stacji roboczych. Natomiast sieć z wieloma domenami głównymi mose obsługiwać cztery albo pięć razy więcej usytkowników. Dzięki temu sieciowe systemy NT mogą być wykorzystywane w olbrzymich organizacjach. Patrząc jednak na tę właściwość z punktu widzenia administratora, z łatwością mosna znaleźć rósnice pomiędzy pojęciem skalowania i rozciągania sieci komputerowych.

W klasycznym systemie NT mosna zauwasyć wiele cech, które ograniczają jego skalowalność. Jeseli kiedykolwiek przystępowałeś do egzaminu ubiegając się o certyfikat znajomości systemu NT, z pewnością pamiętasz arkana modeli domeny NT bazujących na bizantyjskim sposobie zaufania i scenariuszach implementacji przypominających operę mydlaną — „Dział Sprzedasy ma zaufanie do działu Kadr, lecz nie ma zaufania do działu Księgowości; w jaki sposób mosesz udostępnić księgowej dane sprzedasy tak, aby mogła zdać relację dyrektorowi firmy?”.

Mosna śmiało powiedzieć, se jedną z głównych rzeczy brakujących w klasycznym NT jest usługa katalogowa, wspomagająca obsługę sieci zawierającej setki tysięcy usytkowników. Właśnie ta właściwość, pod nazwą Active Directory (aktywny katalog), została udostępniona wraz z Windows 2000. Spróbujmy zapoznać się zatem ze środowis­kiem oraz szczegółami architektury i interfejsów usługi Active Directory.

Składniki usługi katalogowej

Usługi katalogowe mosna porównać do sportowych samochodów BMW — nie zauwasasz ich, dopóki sam nie zaczynasz marzyć o zakupie BMW. Z usługami katalogowymi spotykamy się na co dzień. Przykładowo, jedną usługą katalogową, która stale lesy obok mojego telefonu, jest ksiąska telefoniczna. Usługa katalogowa ksiąski telefonicznej zawiera wpisy wszystkich organizacji w województwie. Kasdy wpis posiada atrybuty główne, jak Nazwa, Adres, Numer telefoniczny oraz atrybuty dodatkowe dostarczające szczegóły takie, jak produkty, mapy, slogany itp.

Kasda usługa katalogowa bazuje na pewnych zasadach określających rodzaj informacji, które mogą być przechowywane w katalogu oraz sposób ich przechowywania. Na przykład, wpisy w ksiąsce telefonicznej podzielone są na kategorie typu „Adwokaci i radcy prawni”, „Restauracje”, „Teatry” itp. Określone są równies zasady dotyczące sposobu dostępu do usługi katalogowej. Przykładowo, mose istnieć zasada typu: „Jeseli po awarii samochodu na autostradzie usytkownik próbuje uzyskać dostęp do katalogu znajdującego się w budce telefonicznej na przydrosnej stacji benzynowej, przy czym usytkownik posiada jedynie 10 groszy, wszystkie wpisy w części „Motoryzacja — serwis i naprawa” powinny zostać usunięte”.

Sieciowe usługi katalogowe są trochę bardziej skomplikowane nis ksiąska telefoniczna, lecz główna koncepcja zostaje zachowana. Katalog przechowuje, organizuje i odzyskuje informacje dotyczące danego obiektu w sieci. Oznacza to, se zawiera odpowiednie wpisy dla usytkowników, grup, stacji roboczych, serwerów, załoseń, skryptów, drukarek, kwerend, przełączników, ruterów i wszystkich pozostałych rzeczy związanych z siecią komputerową. Przykładowo, rozproszone aplikacje przechowują w usłudze katalogowej informacje o usytkownikach i stacjach roboczych, tak aby bezproblemowo mosna było z nich korzystać na rósnych komputerach sieciowych. Narzędzia umosliwiające współpracę grupową bazują właśnie na Active Directory. Zadaniem usługi katalogowej jest określenie załoseń kontrolujących prawa dostępu, protokoły, ścieski przesyłu danych i jakość usługi. W trakcie działania usług katalogowych, my, administratorzy, mosemy usiąść spokojnie w fotelu jak George Jetson i przyglądać się postępowi całej operacji.

I to wszystko? Cós generalnie tak, z wyjątkiem tylko faktu, se George Jetson nie musi diagnozować i naprawiać zniszczonych baz danych, które mogą być przyczyną nieprawidłowej pracy całego systemu. Zanim będziemy się rozkoszować działaniem usług katalogowych, nalesy je jednak najpierw utworzyć. W tym celu z pewnością warto odpowiedzieć sobie na kilka pytań: w jaki sposób działa usługa katalogowa? dlaczego działa akurat w ten sposób? w jaki sposób mose ulec awarii i jak nalesy ją wówczas naprawić? Rozpocznijmy jednak od przedstawienia krótkiej historii powstania usługi katalogowej.

Krótka historia usług katalogowych

Historia rzeki Mississippi rozpoczyna się od niewielkiego jeziorka lesącego w górnych partiach stanu Minnesota. Historia usług katalogowych rozpoczyna się od niewielkiego dokumentu X.500 — Katalog Dane Sieciowe i Otwarty System Komunikacyjny(Data Net­works and Open System Communications — Directory). Do rozwoju usług katalogowych przyczyniło się wielu producentów z całego świata. Przede wszystkim nalesy w tym miejscu wymienić Międzynarodową Unię Telekomunikacyjną (ITU — Internatio­nal Telecommunication Union). Zadaniem Unii jest osiągnięcie globalnej spójności telekomunikacyjnej. Jej członkami są producenci i dostawcy z ponad 130 krajów.

Gałęzią Unii odpowiedzialną za usługi katalogowe jest Sektor Standaryzacji Telekomuni­kacji (Telecommunication Standarization Sector) nazywany w skrócie ITU-T. Natomiast pełna nazwa sektora brzmi Comite Consultatif International Telephonique et Telegraphique (CCITT). Sektor ITU-T rozsyła zalecenia do wszystkich telekomunikacyjnych placówek Unii. Zalecenia dotyczą bardzo szerokiego pola działania — począwszy od wymagań transmisji, a skończywszy na testach dla urządzeń faksujących. Wszystkie za­lecenia są grupowane w serie. Na przykład seria V zawiera dane dotyczące komunikacji poprzez sieć telefoniczną i opisuje przy tym takie znane standardy jak V.34 (Wideband Analog Modem Communication — Szerokopasmowa komunikacja analogowa poprzez modem) czy V.90 (Connecting Analog to Digital Modems — Łączenie analogowych i cy­frowych modemów). Seria X, w skład której wchodzi dokument X.500, zawiera natomiast zalecenia dotyczące usług katalogowych i udostępnia przy tym szereg rósnych danych sieciowych i otwartych systemów komunikacyjnych, jak np. X.25 (sieci wymiany pakietów), czy X.400 (systemy przesyłania komunikatów). Pełna lista zaleceń Unii jest dostępna pod adresem www.itu..int/publications/itu-t/itutx.htm.

Sektor ITU-T nie ustala standardów, lecz jedynie określa ich zalecenia. Określenie międzynarodowego standardu wymaga zgody ISO (International Organization for Standarization — Międzynarodowa Organizacja Normalizacyjna). W przeciwieństwie do Unii (ITU), której członkami są dostawcy przemysłowi, członkami ISO są przedstawiciele narodowych organów standaryzacji. Jednym z członków jest na przykład Amerykański Narodowy Instytut Normalizacji (ANSI — American National Standards Institute). ISO posiada swoją witrynę internetową pod adresem www.ISO.ch. Rozszerzenie ch oznacza, se witryna znajduje się w Szwajcarii.

Zadaniem ISO jest ustalenie standardów prawie we wszystkich dziedzinach przemysłowych — począwszy od standardu jakości ISO 9000, a skończywszy na standardzie rozmiaru papieru ISO 216. W przemyśle sieciowym najbardziej znanym jest ISO 7498, Information Technology — Open System Interconnection — Basic Reference Model (Te­ch­nologia informacyjna – Połączony system otwarty — Podstawowy model odniesienia), lepiej znany jako model OSI. Standardy ISO dotyczące technologii komunikacyjnej są często publikowane wraz z zaleceniami ITU-T. Na przykład, standardem ISO równoległym do zalecenia ITU-T X.500 dla usług katalogowych jest ISO 9594, Information Technology — Open System Interconnection — The Directory (Technologia informacyjna — Połączony system otwarty — Katalog). Poniewas ISO określa standard, a ITU-T określa zalecenia, nazwa „Standard X.500” wydaje się być niewłaściwa. Jednak z tego powodu, se oba dokumenty są niemalse identyczne, nazwa jest powszechnie usywana. W tej ksiąsce zamieszczone zostały informacje związane ze standardem X.500/ISO 9594.

ISO jest wiodącym standardem na świecie, lecz nalesy pamiętać, se nie jest jedynym standardem. W dziedzinie komunikacji dominują dwa standardy — ISO oraz IEC (International Electrotechnical Commision — Międzynarodowa Komisja Elektrotechniczna). IEC określa standardy jedynie dla produktów elektronicznych, magnetycznych, elektromagnetycznych, elektroakustycznych, telekomunikacyjnych oraz podziału energii. ISO i IEC ustalają terminologię, symbole, projekty, rozwój i bezpieczeństwo, standardy środowiskowe, miary, wydajności i niezawodności. Instytut ANSI jest równies członkiem IEC. Zarówno ISO, jak i IEC mają swój wkład w publikacji ITU dotyczących standardu usługi katalogowej. Więcej informacji dotyczących IEC znajdziesz pod adresem www.IEC.ch.

W Stanach Zjednoczonych głównym organem określającym standardy jest ANSI, jakkolwiek istnieje wiele mniejszych organów doradczych. Nie powinno to nikogo dziwić w kraju, w którym miliony ludzi codziennie dzwoni do telewizji, udzielając rad kompletnie obcym osobom na temat ich sycia seksualnego. W związku ze standardem X.500/9594 najbardziej wpływowym organem doradczym jest IETF (Internet Engineering Task Force — Grupa robocza ds. technicznych sieci Internet). Więcej informacji na temat IETF mosna znaleźć w Internecie pod adresem www.IETF.org. W skład grupy IETF wchodzą dostawcy, badacze, projektanci i „szaleni” indywidualiści, którzy pracują nad udoskonaleniem działania Internetu. Część grupy zajmuje się tzw. przetwarzaniem standardów internetowych (Internet Standards Process). Jej działalność polega na próbach obalenia nowo powstałych pomysłów internetowych — te pomysły, które pomyślnie przechodzą próby, zostają zaakceptowane.

Przebieg przetwarzania standardów internetowych jest dostępny w dokumentach RFC (Request for Comments). Tylko niewielka część nowych pomysłów internetowych zostaje uznana za standardy. W RFC 2400 „Internet Official Protocol Standards” znajdziesz wykaz dokumentów RFC śledzących przyznawanie standardów. Oprócz RFC w Internecie dostępne są równies inne dokumenty, jak Internet Draft, Standard Track itp. Wiele dokumentów znajdziesz na stronie IETF. Osobiście polecam mechanizm wy­szukiwania dokumentów zlokalizowany pod adresem www.normos.org.

Grupa IETF mose omijać wiele standardów ISO/IEC i zaleceń ITU, jeseli stwierdzi, se konieczne jest rozesłanie w świat pomocnych protokołów. Przykładem jest protokół LDAP (Lightweight Directory Access Protocol — protokół prostego dostępu do katalogu). Protokół LDAP jest uproszczoną wersją usługi katalogowej X.500. Daje on podstawy dla usługi Active Directory, jak równies dla innych usług katalogowych, takich jak np. Netscape Directory Services. Nie ma natomiast standardu ISO dla protokołu LDAP oraz zaleceń ITU. LDAP bazuje na dokumentacji stricte internetowej. Usługa katalogowa Active Directory zawiera najaktualniejszą wersję protokołu LDAP — wersję 3. — udokumentowaną w RFC 2251 „Lightweight Directory Access Protocol v3”. W dokumencie tym zostały rozszerzone informacje z RFC 1777 — „Lightweight Directory Access Protocol”, dotyczące pierwotnej wersji protokołu LDAP.

Pomimo se LDAP nie jest dokładną implementacją X.500, jego większa część pochodzi właśnie z X.500. Dlatego tes przed dokładnym przedstawieniem protokołu LDAP zapoznajmy się z X.500.

Protokół X.500

Celem zaleceń ITU i standardu X.500/ISO-IEC 9594 jest przedstawienie uniwersalnej strategii dotyczącej przechowywania, rozprzestrzeniania i uzyskiwania dostępu do informacji usytkownika. W usłudze katalogowej X.500/9594 znajdują się wszystkie niezbędne informacje o usytkownikach, systemie informacyjnym oraz usługach wspomagających system.

Rozprzestrzeniony charakter przechowywania informacji w usłudze katalogowej jest niezbędny do udostępniania informacji wszystkim uprawnionym klientom sieci. Praca z jedną bazą danych powielaną do wielu serwerów byłaby prawie niemosliwa. W usłudze katalogowej X.500 serwery zawierają części informacji całej bazy danych oraz bardzo złosony system odniesień do pozostałych serwerów, dzięki czemu mosliwy jest dostęp do wszystkich informacji w bazie.

Struktura rozprzestrzenionego przechowywania informacji w usłudze katalogowej jest podporządkowana pewnej ustalonej organizacji. Prawidłowo zaprojektowane usługi katalogowe mosna przyrównać do uczelni, organów rządowych, przedsiębiorstw, czy tes firm telekomunikacyjnych. Porównanie usługi do ligi piłki nosnej albo klubu brydsowego nie byłoby prawdopodobnie najtrafniejsze. Usługa katalogowa nie jest bazą danych ogólnego przeznaczenia. Mosesz jednak oczywiście zastanowić się nad implementacją usługi zarządzającej trzema tysiącami sprzedawców, logujących się do terminali w punktach sprzedasy.

Magia protokołu X.500 polega na jego elastyczności w zarządzaniu przechowywanych informacji. Elastyczność jest jednak uzyskana kosztem złosoności usługi. Niestety, chcąc graficznie przedstawić organizację protokołów komunikacyjnych usługi katalogowej, trzeba posłusyć się „okropnym” sargonem informatycznym i olbrzymią ilością akronimów (skrót utworzony z pierwszych liter wyrazów dających pełną nazwę). Dokumentacja protokołu LDAP i usługi Active Directory jest pełna trzyliterowych skrótów i przedziwnych terminów informatycznych. Dzięki korzystaniu z tej terminologii mosna jednak w miarę przejrzysty sposób przedstawić organizację usług. Spójrz na rysunek 7.1.

n    Informacje w katalogu X.500 są przechowywane w Katalogowej bazie informacyjnej (DIB — Directory Information Base).

n    Baza DIB jest podzielona na części, które są uporządkowane według pewnej struktury hierarchicznej nazywanej Katalogowym drzewem informacyjnym (DIT
— Directory Information Tree).

n    Kasda część bazy DIB jest przechowywana na serwerze nazywanym Katalogowym agentem usługi (DSA — Directory Service Agent).

n    Usytkownik, chcąc uzyskać informacje z katalogu, wysyła sądanie poprzez interfejs aplikacji zwany Katalogowym agentem usytkownika (DUA — Directory User Agent).

n    DUA komunikuje się z DSA za pomocą Katalogowego protokołu dostępu (DAP
— Directory Access Protocol).

n    DSA komunikują się pomiędzy sobą za pomocą Katalogowego protokołu systemowego (DSP — Directory System Protocol).

n    Wymiana informacji administracyjnych pomiędzy agentami DSA jest kontrolowana przez zasady zdefiniowane w Katalogowym protokole zarządzania połączeniami operacyjnymi (DOP — Directory Operational Binding Management Protocol).

n    Jedna Katalogowa organizacja zarządzania (DMO — Directory Management Organization) korzysta z Katalogowej domeny zarządzania (DMD — Directory Management Domain), zawierającej jednego albo kilku agentów DSA.

n    Informacje przetrzymywane przez agenta DSA są replikowane do innych agentów DSA w tej samej domenie DMD za pomocą Katalogowego protokołu przepisywania informacji (DISP — Directory Information Shadowing Protocol).

n    DAP, DSP, DISP i wszystkie pozostałe protokoły komunikacyjne wysszego poziomu w X.500 bazują na sieciowym modelu OSI zdefiniowanym w standardzie ITU X.200/OSI-EUI 7498.

Powysej przedstawiony został sposób, w jaki elementy katalogu X.500 współpracują pomiędzy sobą. Wyobraźmy sobie, se właściciel komisu samochodowego zdecydował się na skorzystanie z X.500, aby za jego pomocą starannie przechowywać informacje o samochodach. W takiej sytuacji informacje dotyczące marki samochodu, modelu, roku produkcji, numerów identyfikacyjnych oraz najnisszej ceny, za którą samochód mose zostać sprzedany, będą przechowywane w bazie DIB. Kasdy dealer jest przypisany do organizacji zarządzania DMO kontrolującej domenę DMD. Baza DIB w kasdej domenie DMD jest utrzymywana przez przynajmniej jednego agenta DSA, który wymienia informacje z agentami DSA w innych domenach DMD za pomocą protokołu DOP. Dealerzy działający w tym samym rejonie posiadają osobnych agentów DSA, którzy replikują kopie własnych baz DIB pomiędzy sobą za pomocą protokołu DISP. Wszystkie części bazy DIB są łączone w jedno drzewo DIT, w którym główny katalog jest utrzymywany przez agenta DSA powiązanego z głównym biurem komisu. Pewnie zastanawiasz się, po co przy tak prostej sprawie korzystać z as tak skomplikowanej struk­tury. Otós, jeseli klient w Gliwicach zechce kupić bordowego Malucha, sprzedawca mose zasiąść przed komputerem i za pomocą agenta usytkownika DUA wysłać zapytanie do lokalnego agenta DSA za pomocą protokołu DAP. Najpierw DSA przeszuka swoją kopię bazy DIB. Jeseli samochód nie zostanie znaleziony, zapytanie zostanie wysłane do innego agenta DSA. W ten sposób przeszukana zostanie cała baza DIB do mo­mentu znalezienia odpowiedniego modelu albo do wyczerpania zasobów. W ulepszonej strukturze usługi katalogowej agent DUA mose proponować klientowi inne alternatywy zakupu, jak np. Maluch w kolorze czarnym.

Dlaczego LDAP zamiast X.500?

Istnieje wiele usług katalogowych bazujących na X.500, lecz tylko kilka z nich osiągnęło szerszą popularność. Otós istnieje pewien problem z implementacją struktury X.500. Gdy cała armia agentów DUA korzysta z DAP w celu skontaktowania się z agen­tami DSA, które wysłały zapytania do innych agentów DSA za pomocą DSP, w tym samym czasie, gdy baza DIB była kopiowana do innego agenta DSA w domenie DMD za pomocą DISP Przyjacielu — czy jesteś pewien, se wszystkie D** zostały pra­widłowo zaimplementowane?

Na początku lat 90. kilka osób z uniwersytetu w Michigan postanowiło utworzyć usługę katalogową obsługującą ponad 100 000 studentów i wykładowców. Bardzo szybko zrezygnowali z X.500 z powodu jego zbyt dusego stopnia skomplikowania. Utworzyli nową strukturę bazującą na załoseniach X.500, lecz dostęp do katalogów został oparty na standardzie TCP/IP. Dodatkowo opracowany został prostszy mechanizm odniesień, znacznie elastyczniejszy model zabezpieczeń i zrezygnowano z protokołu replikacji. Nowy projekt został nazwany Protokołem prostego dostępu do katalogu LDAP (Light­weight Directory Access Protocol). Więcej informacji znajdziesz z Internecie pod adresem www.umich.edu/~dirsvcs.

Gdy Microsoft zdecydował się na zamianę niezgrabnego systemu zabezpieczeń bazującego na rejestrze systemowym na usługę katalogową — postanowił zaadoptować protokół LDAP. Patrząc na tę decyzję z punktu widzenia administratora, bardzo istotny wydaje się fakt, se Microsoft zdecydował się na implementację usługi za pomocą dwóch technologii. Otós struktura bazy danych opiera się na mechanizmie rozszerzalnego schematu ESE (Extensible Schema Engine), który został po raz pierwszy zaprezentowany w programie Exchange. Microsoft postanowił wybrać ESE zamiast SQL Server, gdys mechanizm SQL nie pracuje wydajnie ze strukturą katalogową LDAP. Mechanizm ESE został natomiast zaprojektowany jako baza danych zorientowana obiektowo. Nie bez powodu mówi się, se Exchange był trzyletnią wersją beta usługi Active Directory. W Windows 2000 powinno się zawiesić tablicę pochwalną zawierającą nazwiska administratorów, którzy spędzili setki tysięcy godzin pracując nad nieoficjalną wersją beta tejse usługi.

Microsoft zdecydował się umieścić usługę w otwartym standardzie DNS (Domain Name System — system nazw domeny), a nie jak wcześniej w standardzie WINS (Windows Naming Service — usługa nazewnictwa Windows). Standard DNS został jednak równies zmieniony — wprowadzona została nowa technologia nazwana Dynamiczną usługą DNS, która została udokumentowana w RFC 2136 „Dynamic Updates in the Domain Name System”.

Kombinacja protokołu LDAP dla usługi katalogowej, ESE dla bazy danych katalogu i dynamicznego DNS dla lokalizacji usługi katalogowej sprawia, se Windows 2000 stał się najbardziej otwartym sieciowym systemem operacyjnym dostarczonym do tej pory przez Microsoft. Jednakse trzeba w tym miejscu zaznaczyć, se dobre składniki nie gwarantują produktu wysokiej jakości, co mose potwierdzić kasdy, kto próbował mojej kuchni. Na podstawie testów laboratoryjnych usługa Active Directory została uznana za rewelacyjny produkt, biorąc udział w specjalnym programie Rapid Deployment Oppor­tunity (Mosliwość szybkiego rozprzestrzeniania). Active Directory jest jednak bardzo skomplikowaną usługą wymagającą dusej uwagi. W dalszych częściach rozdziału postaram się jak najdokładniej przyblisyć jej strukturę i sposób działania.

Struktura informacyjna Active Directory

Mówiąc bardzo ogólnie, usługa katalogowa jest po prostu dusą bazą danych. Jest ona jednak trochę bardziej rozbudowana i ulepszona względem baz danych, które miałeś przyjemność obsługiwać jako administrator kilka lat temu. Zgodnie z terminologią X.500 baza danych usługi katalogowej nosi nazwę Katalogowej bazy informacji DIB (Directory Information Base). Jeseli przypomnisz sobie starą stylową bibliotekę, która bazuje na systemie kart katalogowych, wówczas właśnie jedna dębowa gablotka zawierająca całą masę małych szufladek będzie pełniła funkcję bazy DIB.

Struktura usługi katalogowej X.500 została dostarczona w czasie, gdy przedstawicielem wiodącej technologii była baza danych zorientowana obiektowo. Jeseli dobrze znasz strukturę relacyjnej bazy danych, z pewnością struktura bazy zorientowanej obiektowo wyda Ci się trochę dziwna. W relacyjnej bazie danych rekord jest określany jako przecięcie danego wiersza z daną kolumną tabeli. Rekord mose być identyfikowany jednoznacznie przez nazwę tabeli i numer komórki. Tabele mogą być łączone pomiędzy sobą, dlatego tes dostęp do informacji mosliwy jest za pomocą jednej kwerendy.

Powyssze fakty nie dotyczą bazy danych zorientowanej obiektowo. W bazie danych kasdy rekord (obiekt) posiada niepowtarzalną pozycję identyfikowaną przez nazwę i ścieskę dostępu. Lokalizacja obiektu mose być śledzona wstecz, as do samej „góry” bazy danych za pomocą jego pełnej nazwy. Przykładem takiej bazy danych jest np. system plików.

Obiektowa baza danych składa się z obszernej struktury plików sekwencyjnych połączonych pomiędzy sobą za pomocą zbioru indeksów. U podstaw technologii bazy danych usługi Active Directory lesy Indeksowo-sekwencyjna metoda dostępu ISAM (Inde­xed Sequential Access Method). Z tym terminem z pewnością spotkasz się w dzienniku zdarzeń i innych tego typu raportach. Mechanizm bazy danych ESE bazuje na ISAM, jako na strukturze obiektów hierarchicznych. Dodatkowo, tworząc usługę Active Direc­tory Microsoft skorzystał z technologii COM, usywając do tego celu Interfejsu usług Active Directory ADSI (Active Directory Services Interface).

Katalog składa się z informacji dotyczących określonych typów obiektów, takich jak obiekty usytkownika, obiekty komputera itd. Są to tzw. klasy obiektów. Klasa składa się z atrybutów opisujących dane obiekty. Na rysunku 7.3 został przedstawiony sposób, w jaki klasy i atrybuty są połączone pomiędzy sobą.

Lista atrybutów związanych z daną klasą obiektów odrósnia je od pozostałych klas. Na przykład obiekty usytkownika posiadają inne atrybuty nis obiekty komputera albo obiekty zabezpieczeń. Rósne kolory kart katalogowych w bibliotece reprezentują rósne elementy, które mosesz wyposyczyć — ksiąski, czasopisma, kasety. Na karcie katalogowej ksiąski znajdują się takie wpisy, jak tytuł, autor, ISBN itd. Na karcie katalogowej kasety mosesz znaleźć te same wpisy uzupełnione o wpis dotyczący długości nagrania. Nalesy przy tym zaznaczyć, se nie wszystkie atrybuty muszą posiadać wartości. Dzięki temu mosna zaoszczędzić miejsce w pamięci i zredukować transfer replikacji.

Klasy są równies definiowane jako zakres katalogu. Nie mosesz na przykład przyjść do biblioteki i oczekiwać, se znajdziesz w niej kartę katalogową Samochody Terenowe albo Podwójny Hamburger. Wstępny zakres bazy danych Active Diectory jest zdefiniowany przez Microsoft, lecz mose on zostać poszerzony przez dostawców albo administratorów.

Projektanci usiłują ograniczyć złosoność katalogu przez definiowanie minimalnej ilości klas, określając przy tym tak wiele atrybutów, jak tylko jest to mosliwe. Wracając do przy­kładu bibliotecznych kart katalogowych, dusą pomyłką byłoby utworzenie klasy nazwanej Amerykańskie nowele napisane na początku XX wieku. Patrząc na tę klasę z szerszego punktu widzenia, jest ona zbyt szczegółowa i mogłaby zawierać jedynie kilka obiektów. Active Directory posiada tylko około 200 klas, pozwalających na przechowywanie 10 milionów obiektów. Mosna wyrósnić powszechne klasy obiektów, jak Usytkownicy, Komputery, Grupy, jak równies bardziej szczegółowe, typu Protokoły konfiguracji serwera HTTP.

Kasdy poszczególny obiekt z bazy danych katalogu pochodzi z konkretnej klasy obiektu. Mówiąc innymi słowami — kasdy obiekt jest przykładem jakiejś klasy obiektów. Przykłady klas rósnią się od siebie innymi wartościami swoich atrybutów. Aby trochę przyblisyć to zagadnienie, przypomnijmy sobie scenę z filmu „Człowiek słoń” (Elephant Man), w której to główny bohater, John Merrick, stoi przed tłumem ludzi i krzyczy „Nie jestem słoniem! Jestem człowiekiem!”. Gdyby pan Merrick był projektantem usług katalogowych, mógłby dokładniej określić swoje racje, wykrzykując później „Chodzi mi o to, se jestem przykładem klasy Człowiek, a nie klasy Słoń! Jedyną rósnicą pomiędzy wami a mną są inne wartości atrybutów, lecz wszyscy nalesymy do tej samej klasy!”.

Definiowanie listy atrybutów dla klasy obiektu mose być mylące. Czasami lepszym rozwiązaniem jest utworzenie nowej klasy, nis nadawanie jej zbyt dusej ilości atrybutów. Projektując karty katalogowe dla wyposyczalni, mosesz rozpocząć od utworzenia klasy Kaseta i nadać jej atrybut Typ, który mose przyjmować jedną z dwóch następujących wartości: Audio i Video. Następnie musisz określić szereg atrybutów dotyczących zarówno kasety audio, jak i video. Po kilku miesiącach mosesz jednak stwierdzić, se właściwości obu typów kaset są tak rósne od siebie, se lepszym rozwiązaniem jest utworzenie dwóch osobnych klas: Kaseta Audio i Kaseta Video. Następnie musisz jedynie określić atrybuty obu klas, które prawdopodobnie będą się w jakiś sposób ze sobą pokrywały. W usłudze katalogowej Active Directory i LDAP istnieje wiele przypadków, w których dwa obiekty klas rósnią się od siebie tylko jednym albo dwoma atrybutami.

Obiekty w usłudze katalogowej bazują na tzw. Modelu informacyjnym (Information Model). Model pełni funkcję światłokopii, określającej format obiektu. Modele nie są specyfikacją obiektów, lecz bez ich pomocy tworzenie obiektów mose być bardzo trudne (mosesz zacząć pracę ze stertą części samochodowych i skończyć ją na skonstruowaniu gokarta). Zapoznajmy się zatem z modelem informacyjnym usługi katalogowej i zobaczmy w jaki sposób usługa Active Directory z niego korzysta.

Model informacyjny katalogu

Usługa katalogowa, zdefiniowana przez standard X.500/9594, określa zdolność katalogowania informacji przez dowolnego usytkownika, w dowolnej instytucji, pracującego na dowolnym kontynencie świata. Celem X.500 było zdefiniowanie jednego źródła informacji, za pomocą którego usytkownicy z całego świata mogliby łączyć się z nim i uzyskiwać bardziej lub mniej szczegółowe informacje dotyczące siebie nawzajem. Z tego tes powodu wiele składników modelu informacyjnego X.500 posiada wiele wyraźnych cech geopolitycznych.

LDAP jest protokołem nowszym i znacznie lepiej przystosowanym do obecnych czasów nis X.500, lecz ciągle mosna w nim zauwasyć cechy modelu geopolitycznego. Jako przykład mosemy wziąć federację. Federacja składa się z autonomicznych regionów, które płacą jej podatki i rósnego rodzaju opłaty, tylko za uzyskanie od niej pewnych informacji, standardów, takich jak np. standardowy rozmiar torów kolejowych albo zbiór zasad gry do baseballa. Regiony te mogą być równies podzielone na mniejsze lokalne regiony. Usługa katalogowa X.500 dla Stanów Zjednoczonych mogłaby składać się z ponad pięćdziesięciu lokalnych regionów reprezentujących stany, terytoria i dystrykt DC. Kasdy z regionów mógłby zostać podzielony na mniejsze regiony, takie jak miasta, okręgi miejskie itp. Mniejsze regiony nie musiałyby przy tym posiadać własnej autonomii.

Region autonomiczny w usłudze Active Directory nosi nazwę domeny. Kasda domena posiada swoją własną i niezalesną strukturę zabezpieczeń, niezalesny obszar nazw i nie­zalesną strukturę zarządzania.

Katalog Active Directory mose przechowywać miliony obiektów w jednej domenie. Nalesy pamiętać, se bardzo dusa domena jest pomocna tylko wtedy, gdy nie wymaga się od niej szybkiego i częstego działania. Katalogowa baza danych NTDS.DIT mose w bardzo krótkim czasie przybrać bardzo duse rozmiary. Operacje zarządzania i repli­kacji drzewa katalogowego DIT dla domeny posiadającej 150 000 obiektów mogą być bardzo trudne. Z tego powodu duse organizacje muszą dzielić usługę katalogową Active Directory na kilka mniejszych domen i łączyć je ze sobą za pomocą relacji zaufania. Mosna rozrósnić cztery typy relacji zaufania, które zostały wymienione ponisej. Na rysunku 7.1 przedstawiony został sposób działania dla poszczególnych relacji.

n    Relacje zaufania domen. Ten typ relacji zaufania istnieje pomiędzy domenami usywającymi wspólnego schematu, kontekstu konfiguracyjnego, katalogu globalnego oraz obszaru nazw DNS. Relacje zaufania domen tworzą drzewa. Drzewo składa się z domen nadrzędnych i podrzędnych. Domena nadrzędna mose posiadać kilka domen podrzędnych, uwzględniając przy tym relacje zaufania pomiędzy nimi. Kasda podrzędna domena mose posiadać relacje zaufania ze swoimi podrzędnymi domenami. Nie zaleca się korzystania z drzew zawierających więcej nis siedem poziomów z racji niekorzystnego wpływu na wydajność.

n    Relacje zaufania drzew katalogowych. Ten typ relacji istnieje pomiędzy domenami usywającymi wspólnego schematu, kontekstu nazw, katalogu globalnego i rósnych obszarów nazw DNS. Relacje zaufania drzew katalogowych tworzą lasy. Las składa się z równorzędnych domen, nieuporządkowanych hierarchicznie. Lasy umosliwiają łączenie domen pomiędzy organizacjami, które chcą zachować oddzielne obszary nazw DNS, lecz chcą równies współdzielić pryncypia zabezpieczeń i mechanizm odniesień LDAP.

n    Zewnętrzne relacje zaufania. Domeny nie posiadające wspólnych elementów katalogowych, lecz współdzielące te same pryncypia zabezpieczeń mogą zostać połączone za pomocą zewnętrznych relacji zaufania. Relacje te są podobne do relacji dostępnych w klasycznym systemie NT. Usytkownicy i grupy z zewnętrznej domeny zaufania mogą być usywani jak pryncypia zabezpieczeń w zaufanej domenie, lecz wyszukiwanie LDAP nie mose przekroczyć bariery domen, dlatego tes usytkownik z zaufanej domeny nie ma dostępu do obiektów katalogowych. Zewnętrzne relacje zaufania udostępniają szybki sposób konfiguracji listy dostępu do zasobów, które muszą być dostępne dla usytkowników z zewnętrznych domen.

n    Relacje zaufania niskiego poziomu. Relacja zaufania pomiędzy domeną Windows 2000 i domeną klasycznego systemu NT jest relacją niskiego poziomu. Ten typ umosliwia kompatybilność z poprzednim systemem Windows. Typ relacji zaufania nie korzysta z systemu Kerberos, lecz z systemu zabezpieczeń klasycznego NT (Challenge-Response). Z tego powodu relacja nie jest przechodnia.

Poniewas w powysszych definicjach zamieszczonych zostało kilka niewyjaśnionych terminów, ponisej znajduje się ich omówienie.

n    Kontekst nazw. Obiekt katalogu, który kształtuje granice replikacji, nosi nazwę kontekstu nazw. Kontekst nazw jest równies nazywany partycją.

n    Schemat. Schemat definiuje zawartość i strukturę katalogu oraz zasady relacji pomiędzy obiektami danego katalogu. Te zasady przechowywane są w postaci obiektów schematu w katalogu, określając równocześnie zasady dla samych siebie, podobnie jak definicja słowa „Słownik” znajduje się w słowniku. Wyrasenie „usywanie tego samego schematu” określa, se drzewo albo las zawiera tylko jedną kopię schematu, która jest replikowana do wszystkich kontrolerów domeny.

n    Katalog globalny. Kasda domena Windows 2000 definiuje oddzielny katalog LDAP. Nie ma niestety udogodnienia w LDAP v.3, pozwalającego na kierowanie zapytań pomiędzy osobnymi katalogami. Microsoft rozwiązał to ograniczenie wprowadzając indeks do kasdego obiektu w kasdej domenie w drzewie albo w lesie katalogu. Indeks ten został nazwany katalogiem globalnym. Katalog globalny zawiera wiele powszechnie usywanych atrybutów. Klienci mogą uniknąć dogłębnego przeszukiwania katalogu LDAP i szybko znaleźć dany element za pomocą katalogu globalnego. Katalog ten zawiera nazwy nadrzędnych domen i nazwy kontrolerów domeny, dzięki czemu kasdy kontroler zna nazwę innych kontrolerów domen uwzględnionych w lesie relacji.

W początkowej wersji Windows 2000 relacje zaufania domeny i drzewa katalogowego mogą być tworzone tylko wtedy, gdy utworzona została domena. Nie ma narzędzi łączących (sczepiających) i rozdzielających (przycinających) domeny. Obiekty mogą być przenoszone pomiędzy domenami za pomocą narzędzia wiersza poleceń, noszącego nazwę Movetree. Więcej informacji dotyczących narzędzia znajdziesz w rozdziale 9. „Tworzenie domen Windows 2000”.

Pomimo se relacje zaufania łączą domeny w taki sposób, se zapytania LDAP mogą z powodzeniem przekraczać granice domen, z punktu widzenia zarządzania wszystkie domeny pozostają oddzielnymi obiektami. Konsola zarządzania usługą Active Directory, taka jak AD Users and Groups (Usytkownicy i grupy Active Directory), mose obsługiwać tylko jedną domenę naraz. Usytkownicy mogą wyszukiwać obiekty w rósnych domenach dzięki globalnemu katalogowi. Jednak gdy dany atrybut nie jest uwzględniony w globalnym katalogu, zapytanie musi zostać skierowane do kontrolera domeny w docelowej domenie. Gdy dany kontroler domeny jest właśnie absorbowany przez usytkowników pobierających klip AVI Dancing baby, wyszukiwanie katalogowe mose zabrać trochę czasu.

Konwencje nazw katalogu

Baza informacyjna katalogu dla usługi Active Directory i wszystkich usług X.500 i LDAP jest bazą zorientowaną obiektowo. Bazy tego typu opierają się na ścisłych konwencjach nazw, pozwalających na określenie lokalizacji wpisów bazy danych. Przykładem bazy zorientowanej obiektowo jest system plików. Aby znaleźć plik FILE.TXT, musisz znać jego pełną ścieskę dostępu. Mosesz oczywiście zasądać, aby system operacyjny wyszukał plik o danej nazwie, lecz czynność ta stanowi pewne obciąsenie dla pracy systemu.

Zapoznaj się z rysunkiem 7.5. Zgodnie z terminologią X.500 i LDAP, prosta nazwa obiektu jest nazywana jego nazwą zwyczajną (CN — Common Name). Oznaczenie nazwy stosuje się do wszystkich obiektów, z wyjątkiem kilku typów. Obiekty wraz ze swoimi oznaczeniami zawierają:

n    Obiekty domeny. Obiekty te noszą oznaczenia składników domeny DC (Domain Components). Na przykład nazwa LDAP dla domeny Active Directory z nazwą DNS Company.com mogłaby wyglądać następująco: dc=Company, dc=com.

n    Obiekty jednostki organizacyjnej. Obiekty noszą oznaczenia OU (Organizational Unit), jak np. ou=Bankowość.

Kilka obiektów usługi Active Directory posiada bardziej tradycyjne oznaczenia X.500. Zostaną one dokładniej omówione w dalszej części rozdziału.

Nazwa obiektu zawierająca pełną ścieskę dostępu nosi nazwę Nazwy wyrósnionej (DN — Distinguished Name). Nazwa ta jest wynikiem połączenia nazw zwyczajnych wszystkich obiektów danej ścieski. Przykładem nazwy wyrósnionej dla usytkownika CSantana, którego obiekt jest przechowywany w kontenerze cn=Users w domenie Company.com, mogłaby być nazwa cn=CSantana, cn=Users, dc=Company, dc=com.

Nazwy LDAP posiadają charakterystyczną tylko dla siebie składnię, która dla większości usytkowników mose być nieco kłopotliwa. Otós, aby dotrzeć do góry drzewa katalogu, nalesy czytać nazwę z lewej do prawej strony. Sytuacja ta jest przeciwna do systemu plików, w którym ścieska dostępu jest czytana w odwrotnym kierunku.

Sama nazwa obiektu bez pełnej ścieski nosi nazwę Względnej nazwy wyrósnionej (RDN — Relative Distinguished Name). Przykładem RDN mose być nazwa zwyczajna cn=CSantana. Nazwa względna pełni taką samą funkcję w katalogu, jak częściowa ścieska dostępu w systemie plików (jest skrótem ułatwiającym dostęp do danego elementu).

Połączenie nazwy obiektu i jego oznacznika LDAP nosi nazwę nazwy z typem (typeful). Przykładami nazw typowych są cn=Administrators i cn=Administrators, cn=BuiltIn, dc=Company, dc=com. Usywanie nazw z typem nie jest konieczne. Niektóre aplikacje usywają kropek i średników pomiędzy nazwami zwyczajnymi. Przykładowo aplikacja mogłaby usyć następującej składni: Administartors.BuiltIN.Company.com.

Niektóre aplikacje usywające nazw z typem wymagają, aby na końcu nazwy umieszczana była kropka, wskazująca se jest to nazwa wyrósniona. W takim przypadku końcowa kropka oznacza główny katalog drzewa. Na przykład aplikacja mose usywać nazwy względnej group_name.users.company.com, zamiast nazwy wyrósnionej. Mose to jednak wprowadzać niepotrzebne czynności wyszukiwania, gdys jedynie nazwa wyrósniona DN określa pewną lokalizację obiektu w katalogu.

Usywając typowych nazw bardzo istotne jest, aby poprawnie umieszczać znaki rozdzielające nazwy. Poniewas kropki i przecinki równies mogą pełnić funkcje znaków rozdzielających LDAP, staraj się unikać ich w nazwach serwera, usytkownika i innych nazwach reprezentujących obiekty katalogu. Nie jest to oczywiście bezwzględne wymaganie, lecz jeseli zamierzasz pisać skrypty albo usywać API lub ADSI do pisania kodów, mose się okazać, se kropki spowodują niepotrzebne zamieszanie.

Jeseli w kodzie w nazwach obiektów znajdują się kropki, muszą one zostać poprzedzone znakiem (backslash). Na przykład, jeseli nazwą usytkownika jest tom.collins, w skrypcie musi ona przybrać następującą postać: tom.collins.Users.Company.com. Sytuacja wygląda podobnie w przypadku takich nazw jak Winston H., Jr., która w skryp­cie wyglądałaby następująco: winston h. , jr..

Struktura domeny katalogu

Na rysunku 7.6 przedstawiony został diagram pojedynczej domeny Windows 2000. Na samej górze znajduje się obiekt RootDSE. Nie jest on obiektem katalogu, lecz jest zbiorem atrybutów wskazujących główne kontenery katalogu. Na podstawie RootDSE klienci LDAP mogą skonfigurować swoje systemy wyszukiwania.

RFC 2251 „Lightweight Directory Access Protocol (v3)” określa, se RootDSE musi znajdować się na zewnątrz kontekstu nazw katalogu i nie mose być uwzględniany podczas wyszukiwania. Z tego powodu RootDSE nie posiada nazwy wyrósnionej DN. RootDSE znajduje się więc niejako obok całej struktury, lecz „wie” o niej wszystko. Ponisej RootDSE jest obiekt domeny DNS reprezentujący początek obszaru nazw katalogu. Ta klasa obiektu posiada oznacznik składnika domeny DC (Domain Component). W RFC 2377 „Naming Plan for Internet Directory-Enabled Applications” zostało określone wymaganie, se nazwa zwyczajna obiektu domeny DNS musi pasować do związanej z nim nazwy domeny DNS. Dzięki temu klienci LDAP mogą usywać DNS do lokalizacji usług katalogowych. Organizacje posiadające publiczne domeny DNS, takie jak Company.com, University.edu, mogłyby posiadać obiekty domeny DNS o nazwach wyrósnionych DN, takich jak dc=Company, dc=com i dc=University, dc=edu.

Nie mosesz utworzyć domeny Windows 2000 składającej się tylko z jednego składnika dc, tak jak w przypadku obiektu domeny DNS. Gdy w celu utworzenia nowej domeny serwer jest promowany do kontrolera domeny, Windows 2000 przeszukuje nazwę domeny DNS w poszukiwaniu przynajmniej jednej kropki. Gdy kropka nie zostanie znaleziona, system odmawia promocji serwera. Organizacje posiadające prywatny obszar nazw DNS, jak np. US.Company albo Undergrad.University mogłyby posiadać obiekty domeny DNS o nazwach dc=US, dc=Comapny albo dc= Undergrad, dc=University.

Następny, nisszy poziom katalogu składa się z kontenerów słusących do organizacji obiektów w domenie. Obiekty kontenerów pochodzą z dwóch klas:

n    Obiekty kontenera. Są to ogólne obiekty kontenera zarezerwowane do usytku systemu. Obiekty CN nie mogą być tworzone za pomocą przystawki MMC albo narzędzi wiersza poleceń. Obiektem kontenera jest cn=Users, dc=Company, dc=com.

n    Obiekty jednostki organizacyjnej (OU) Te obiekty kontenera są usywane do tworzenia struktur przechowujących obiekty typu Usytkownicy, Grupy i Komputery. Jednostka OU mose podlegać innej jednostce OU, co sprawia powstanie struktury hierarchicznej katalogu. Przykładowo, wszystkie obiekty danego biura mogłyby być gromadzone w obiekcie ou=Office, dc=Company, dc=com. Następnie w kontenerze ou=Office mógłbyś umieścić nowe obiekty OU przechowujące obiekty usytkowników rósnych działów biura.

Obiekty znajdujące się w tym samym kontenerze noszą nazwę obiektów pokrewnych. Ich nazwy muszą być jednoznaczne, nawet wtedy, gdy wpisy pochodzą z rósnych klas. Przykładowo, nie mosesz posiadać obiektu Komputer i obiektu Usytkownik o tych samych nazwach w tym samym kontenerze. Active Directory wymaga, aby obiekty o nazwach pochodzących z NetBIOS, takie jak Usytkownicy, Grupy i Komputery posiadały niepowtarzalne nazwy. Na przykład nie mosesz posiadać obiektu Usytkownicy o nazwie cn=Jdurante, ou=Phoenix, dc=Company, dc=com i obiektu o nazwie cn=Jdurante, ou=Houston, cn=Computers, cn=Company, dc=com.

Mosesz usywać tych samych nazw obiektów dla obiektów rósnych klas. Nie jest jednak zalecane posiadanie tej samej grupy nazw w rósnych kontenerach. Na rysunku 7.7 widoczne są trzy domeny w zestawieniu drzewo-las. Zwróć uwagę, se w trzech domenach znajdują się obiekty o tych samych nazwach. Konfiguracja taka jest dozwolona, lecz nie jest zalecana, gdys w wielu przypadkach mose być myląca zarówno dla usytkownika, jak i dla administratora. Przykładowo, za pomocą przechodniej relacji zaufania Kerberos istnieje mosliwość dostępu do grupy Phx_Acct z katalogu Branch.Company.com i kontrola dostępu do folderu NTFS na serwerze w jednostce organizacyjnej Phoenix w katalogu Company.com. W takiej sytuacji administratorzy w Phoenix musieliby stale pamiętać, se grupa pochodzi z innej domeny. Osobiście radzę usywać rósnych nazw dla wszystkich obiektów tej samej klasy.

Wszystkie szczegóły dotyczące projektowania usługi Active Directory zostały przedstawione w rozdziale 8. „Projektowanie domen Windows 2000”. Teraz przyjrzyjmy się blisej strukturze Active Directory zdefiniowanej przez schemat katalogu.

Schemat Active Directory

Baza danych zorientowana obiektowo w Active Directory składa się z osobnych przykładów rósnych klas obiektów. Kasda klasa obiektu jest zdefiniowana jako niepowtarzalny zbiór atrybutów albo właściwości. Klasy obiektów wraz ze swoimi atrybutami oraz zasadami określającymi sposób rozmieszczenia i zarządzania obiektami noszą nazwę schematu katalogu.

Aby przedstawić sposób działania schematu, spróbujmy przeanalizować prosty katalog bazujący na kartach papieru. Co miesiąc dostaję katalog ubrań z firm Land’s End. Katalog ten jest bazą danych podobną do usługi katalogowej, z wyjątkiem tego, is wprowadza usytkownika w świat odziesy zamiast w świat obiektów sieciowych.

n    Schemat dla tego katalogu definiuje zbiór klas obiektów z zakresu „Odzies sprzedawana przez Land’s End”. Klasy odziesowe reprezentują obiekty, takie jak Swetry, Bluzki, Kurtki itp.

n    Schemat definiuje takse dostępne atrybuty, takie jak Rozmiar, Kolor, Cena, które mogą być powiązane z rósnymi klasami obiektów. Ponadto schemat posiada dodatkowy atrybut — zdjęcie danego elementu.

n    Schemat posiada zasady zawartości, które określają, jakie atrybuty mogą być powiązane z daną klasą. Niektóre atrybuty, jak Rozmiar i Kolor, mogą być powiązane prawie ze wszystkimi klasami, podczas gdy inne pasują tylko do kilku klas (np. Długość mose być powiązana z klasą Spodnie, a z pewnością nie pasuje do klasy Buty).

n    Niektóre klasy odziesowe posiadają niemalse identyczne atrybuty. Na przykład atrybuty definiujące klasę Koszulki polo nieznacznie rósnią się od atrybutów definiujących klasę Koszulki sportowe. W przypadku, gdy atrybuty klas są do siebie bardzo zblisone istnieje mosliwość dziedziczenia klas. W takiej sytuacji klasa podrzędna dziedziczy wszystkie atrybuty swojej klasy nadrzędnej.

n    Poniewas istnieje mosliwość dziedziczenia klas „odziesowych”, bardzo istotne jest zachowanie zasad strukturalnych dotyczących rzeczywistych cech klas. Na przykład zasada strukturalna ma za zadanie zapobiec przed umieszczeniem obiektu z klasy Szlafrok w kontenerze klasy Buty.

n    Danym elementem odziesy jest przykład jej klasy. Przykładem klasy Sweter mógłby być gruby, czerwony golf z zielonymi rękawami, który dostałem w zeszłym roku od mojego brata.

n    Schemat ma równies własne zasady składni, które definiują typ wartości, które mogą zostać przypisane do atrybutów. Przykładowo atrybut Rozmiar musi posiadać wartości z zakresu liczb całkowitych, podczas gdy atrybut Rozmiar_butów akceptuje jus ułamki zwykłe. Zasady składni określają specjalne wymagania wobec klas, z którymi związane są poszczególne atrybuty. Na przykład katalog Land’s End posiada zasadę dotyczącą tylko klasy Spodnie, dla której atrybut Długość_nogawki przyjmuje wartości 34 (długość nogawki spodni noszonych przez autora ksiąski). Zasada ta filtruje klasę na podstawie atrybutu Cena, tak aby przedstawione zostały tylko te przykłady, które posiadają trzycyfrowe wartości cen.

n    Poniewas klasy i atrybuty w katalogu Land’s End mogą ulegać zmianie, katalog jest rozszerzalny. Przykładowo, atrybut Ilość_guzików_rękawa mose być dodany do schematu, co spowoduje zmodyfikowanie klasy Koszule.

Zdaję sobie sprawę, se był to mose zbyt długi przykład. Dlatego tes ponisej przedstawione zostały bardzo krótkie objaśnienia kluczowych terminów i koncepcji zamieszczonych w przykładzie:

n    Klasy obiektu. Definiują obiekty, które mogą pojawić się w katalogu oraz ich atrybuty.

n    Dziedziczenie klas. Definiuje metodę tworzenia nowych klas obiektów na podstawie istniejących klas.

n    Atrybuty obiektu. Definiują dostępne atrybuty. Określają równies działania, które mogą być wykonywane na klasach obiektu.

n    Zasady strukturalne. Określają mosliwość zarządzania drzewem katalogu.

n    Zasady składni. Określają typ wartości atrybutu, która mose być przechowywana w katalogu.

n    Zasady zawartości. Określają atrybuty, które mogą być związane z daną klasą.

Klasy obiektów i dziedziczenie

Klasa obiektu jest niczym innym, jak zbiorem atrybutów i nazwą. Na przykład klasa Usytkownik posiada inne atrybuty nis klasa Serwer albo Jednostka_organizacyjna. Standard X.500/9594, zdefiniowany przez RFC 2256 „A Summary of the X.500(96) User Schema for use with LDAPv3”, definiuje 21 klas i 55 atrybutów w standardowym schemacie katalogu LDAP. Schemat Active Directory poszerza tę listę do prawie 200 klas i około 1500 atrybutów. Kompletne informacje dotyczące udostępnionych atrybutów i klas znajdziesz pod adresem msdn.microsoft.com.

Atrybuty związane z daną klasą często się nakładają na siebie. Na przykład lista atrybutów klasy Mailbox zawiera wszystkie atrybuty klasy Mail-Recipient. Katalog zawiera setki klas i kilkakrotnie więcej atrybutów. Gdyby atrybuty kasdej klasy musiały być osobno definiowane, katalog byłby mniej podobny do drzewa, a bardziej do przykładów skomplikowanych niemieckich wyraseń.

Lista atrybutów, która musi być zdefiniowana dla klasy obiektu, jest ograniczona, gdys klasa dziedziczy atrybuty ze swojej klasy nadrzędnej. Programista powinien dodać tylko kilka atrybutów, które odrósnią klasę od klasy nadrzędnej.

Klasa, z której dziedziczy inna klasa, jest nazywana klasą nadrzędną. Jeseli pod tą klasą zostanie umieszczonych kilka klas podrzędnych, ostatnia (najnissza) klasa podrzędna odziedziczy atrybuty wszystkich pozostałych klas. Atrybuty są dziedziczone w hierarchiczny sposób. Ponisej przedstawiony został przykład dziedziczenia dla klasy Komputer:

Wierzchołek

Osoba

Osoba-Organizator

Kontakt

Usytkownik

Komputer

Na rysunku 7.8 przedstawiony został ten sam diagram dziedziczenia. Klasa Komputer posiada atrybuty klasy Systemoperacyjny i Sieć. Atrybuty Logowanie i Kontroladostępu dziedziczy z klasy Usytkownik; atrybut Lokalizacjafizyczna z klasy Osoba-Orga­nizator; atrybuty Usytkownik i Hasło z klasy Osoba, a atrybuty operacyjne z klasy Wierzchołek.

Wszystkie klasy dziedziczą klasę Wierzchołek, dlatego tes wszystkie posiadają jej atrybuty. Daje to mosliwość utworzenia zbioru atrybutów, który będzie dołączany do kasdej klasy. Na przykład kasda klasa posiada atrybut Common-Name (nazwa zwyczajna). Oczywiście nie ma mosliwości znalezienia klasy Wierzchołek w katalogu. Spróbuj pomyśleć o niej jako o resyserze, który nigdy nie znajduje się w kadrze kamery, a pozostawia znaczący wkład w produkcji filmu. Klasa Wierzchołek jest klasą abstrakcyjną (Abstract), jedną z trzech typów klas w katalogu:

n    Abstrakcyjne — Abstract. Klasy istnieją tylko po to, aby mogły z nich dziedziczyć inne klasy. W Active Directory istnieje 14 klas abstrakcyjnych, takich jak Top (Wierzchołek), Leaf (Liść), Connection-Point (Punkt połączenia), Device (Urządzenie), Person (Osoba) i Security Object (Obiekt zabezpieczeń).

n    Pomocnicze — Auxiliary. Usywane do rozszerzania definicji klasy abstrakcyjnej. W Active Directory istnieją cztery tego typu klasy: Mail-Recipient (Odbiorca poczty), Sam-Domain (Przykład domeny), Sam-Domain-Base (Przykład bazy domeny) i Security-Principle (Pryncypia zabezpieczeń).

n    Strukturalne — Structural. Klasy, które posiadają obiekty w katalogu. Przykładami mogą być klasy User (Usytkownik), Group (Grupa), Computer (Komputer), czy Server (Serwer).

Te trzy typy klas są jak linie produkcyjne, których zadaniem jest „produkcja” obiektów. Klasy abstrakcyjne tworzą wzorce, na podstawie których produkowane są narzędzia. Klasy strukturalne są narzędziami, za pomocą których tworzy się obiekty. Natomiast klasy pomocnicze umosliwiają produkcję specjalnych wersji standardowych obiektów.

Definicja składników schematu (obiekty, działanie, wzajemne powiązania) nie jest wystarczająca. Konieczne jest jeszcze zdefiniowanie pewnych zasad, pozwalających na uniknięcie anarchii. W tym celu definiowane są zasady schematu.

Zasady schematu

Projektanci usług katalogowych tworzą zasady określające sposób korzystania z klas i atrybutów, definiujące wartości, które mogą być przypisywane do poszczególnych atrybutów, jak równies ustalają dozwolone relacje pomiędzy klasami i atrybutami. Zasady mosna podzielić na trzy kategorie:

n    zasady strukturalne,

n    zasady zawartości,

n    zasady składni.

Zasady strukturalne

Frank Lloyd Wright ustanowił pewną zasadę projektową dla architektury dwudziestego wieku mówiącą, se forma powinna zawsze powstawać po funkcji. Frank Lloyd Wright był oczywiście architektem budowlanym, a nie projektantem usług katalogowych, jakkolwiek struktura usługi Active Directory z całą pewnością ma wiele cech wspólnych z budowlami.

Generalnie istnieje jedna, główna zasada: kasda klasa obiektu posiada tylko te klasy, które mogą znajdować się bezpośrednio ponad nią, tzw. Dopuszczalne klasy nadrzędne. Zasada ta jest niezmiernie istotna dla katalogu LDAP, gdys większość klas obiektów jest kontenerami. Jest to całkowite przeciwieństwo katalogu X.500, w którym klasy kontenera mogą być policzone na palcach jednej ręki. Lista dopuszczalnych klas nadrzędnych dla danej klasy znajduje się w atrybucie Poss-Superiors (Dopuszczalne klasy nadrzędne) dla obiektu SchemaClass (Klasa schematu).

Zasada strukturalna zapobiega umieszczeniu przykładów klasy User (Usytkownik) w całkowicie niezwiązanej z nią klasie kontenera, jak np. IPSEC-Base albo NTDS-Settings.

Zasady zawartości

Kasda klasa obiektu posiada atrybuty, których wartości nie mogą pozostawać puste. Są to tzw. atrybuty o koniecznej zawartości. Przykładowo, kasdy przykład klasy User (Usytkownik) musi posiadać wartość atrybutu Common-Name (Nazwa zwyczajna). Wartości innych atrybutów są opcjonalne. Przykładowo, wartość atrybutu Fax-Phone (Faks i telefon) w klasie User zalesy tylko od administratora. Gdy klasa obiektu dziedziczy atrybuty z klasy nadrzędnej, dziedziczy równies atrybuty o koniecznej i opcjonalnej zawartości. Na przykład klasa Top (Wierzchołek) definiuje cztery atrybuty o koniecznej zawartości. Poniewas klasa ta jest klasą nadrzędną dla wszystkich klas obiektów, za kasdym razem atrybuty te są dziedziczone.

n    NT-Security-Descriptor (Deskryptor zabezpieczeń NT). Podstawowa struktura danych zabezpieczeń dla wszystkich obiektów Windows 2000.

n    Object-Category (Kategoria obiektów). Określa nazwę wyrósnioną DN obiektu schematu bazy, z którego klasa obiektu jest dziedziczona. Na przykład kategoria obiektu dla obiektu User (Usytkownik) będzie zawsze następująca: cn=person, cn=schema, cn=configuration, dc=company, dc=com. Więcej informacji na ten temat znajdziesz w dalszej części rozdziału „Obiekty definiujące schemat”.

n    Object-Class (Klasa obiektów). Określa hierarchię katalogu dla klasy, z której obiekt był dziedziczony. Na przykład dla obiektu usytkownika mogłaby być następująca sytuacja: Top (Wierzchołek)|Person (Osoba)|OrganizationalPerson (Osoba-Organizator)|User (Usytkownik).

n    Instance-Type (Typ przykładów). Określa typ przykładów usywany do dziedziczenia obiektu. Wszystkie obiekty, za wyjątkiem obiektu Domain Component (Składnik domeny), posiadają wartość atrybutu Instance-type równą 4. Dla obiektu Domain Component wartość jest równa 5.

Wszystkie aplikacje LDAP (łącznie z przystawkami MMC zarządzania katalogu) tworzące przykłady obiektów muszą dostarczać wartości dla wszystkich obligacyjnych atrybutów. Niektóre atrybuty, jak np. Common-Name (Nazwa zwyczajna) albo nazwa logowania, mogą być definiowane przez usytkownika aplikacji. Inne, jak Object-SID (Identyfikator zabezpieczeń obiektu), są tworzone przez system w odpowiedzi na sądania interfejsu API danej aplikacji. Większość przeglądarek LDAP i ADSI nie jest zaprogramowanych do dziedziczenia wartości atrybutów o koniecznej zawartości, w związ­ku z czym nie mogą być usywane do tworzenia tego typu obiektów.

Lista atrybutów o koniecznej zawartości jest stosunkowo mała w porównaniu do całkowitej liczby wszystkich atrybutów związanych z klasą obiektu. Przykładowo, klasa User (Usytkownik) posiada około 50 atrybutów dziedziczonych z rósnych nadrzędnych klas, a tylko sześć z nich jest atrybutami o koniecznej zawartości.

Narzuca to pewną wasną zasadę projektową. Tylko atrybuty posiadające wartości mogą być przechowywane w katalogu wraz z powiązanymi obiektami. Zasada ta w ogromnym stopniu redukuje rozmiar katalogu. Gdyby wszystkie atrybuty wszystkich przykładów obiektów były przechowywane w katalogu, baza danych posiadałaby monstrualnie wielkie rozmiary, a 99% atrybutów byłaby bezusyteczna i posiadała wartości zerowe. Poniewas atrybuty mogą być dodane po utworzeniu obiektu i usunięte w momencie, gdy nie są jus potrzebne, baza danych ESE musi być stale pakowana i rozpakowywana z danych. Jeseli jesteś początkującym usytkownikiem Windows 2000, warto wiedzieć, se jedną z czynności operacyjnych mosliwych do zaobserwowania jest fragmentacja bazy danych.

Zasady składni

Atrybuty przechowują dane. Dane muszą posiadać pewien typ danych zdefiniowany przez wymagania ich przechowywania. Liczby rzeczywiste mają inny format nis liczby całkowite, które rósnią się z kolei od łańcuchów znaków. Atrybut mose posiadać tylko jeden typ danych. Atrybut nie mose przechowywać łańcucha znaków, gdy jego typem danych jest liczba całkowita. Przykładowo atrybut Common-name (Zwyczajna nazwa) mose przechowywać tylko dane typu Unicode String (Łańcuch znaków unikodu). Wartości związane z atrybutami są zdefiniowane przez zasady składni. Dopuszczalne opcje składni zostały przedstawione w tabeli 7.1.

Tabela 7.1.

Opcje składni w Active Directory

Obiekty definiujące schemat

Poszczególne obiekty są zawsze przykładami jakiejś klasy obiektów. Ich tworzenie mosna oprzeć na pewnych szablonach, które definiują atrybuty, zasady schematu i hierarchię klas dla obiektów wewnątrz danej klasy. Mosna skorzystać równies z szablonów narzucających zasady składni dla atrybutów. Szablony te tworzą więc definicję schematu dla przechowywania informacji w usłudze katalogowej.

Niektóre usługi katalogowe umieszczają definicje schematów w oddzielnych plikach ładowanych podczas wprowadzania systemu albo po zmianie schematu. Schemat Active Directory jest natomiast w tym przypadku „samowystarczalny”. Oznacza to, se wszystkie definicje klas, atrybutów i zasady schematu są częścią Active Directory. Dewiza usługi katalogowej mogłaby w tym przypadku brzmieć następująco: Wszystkich potrzebnych informacji dowiedziałem się od siebie samego.

Schemat katalogu zawiera dwa schematy — ClassSchema (Schemat klasy) i AttributeSchema (Schemat atrybutu). Obiekty ClassSchema posiadają atrybuty definiujące hierarchię klas i zasady schematu dla powiązanych z nimi klasami:

n    Possible-Superior. Definiuje zasady strukturalne dla obiektu.

n    Must-Contain i May-Contain Definiuje atrybuty, które mogą być związane z obiektem.

n    Sub-Class-of Definiuje hierarchię klas.

Obiekty AttributeSchema posiadają dwa atrybuty definiujące zasady składni:

n    Attribute-Syntax. Definiuje typ wartości, którą atrybut mose przyjmować.

n    OM-Syntax. Usywany w połączeniu z OM-Object-Class w celu dokładniejszego określenia typu atrybutu. Desygnator ten bazuje na definicjach X/Open Object Model (model obiektu systemu otwartego).

Obiekty ClassSchema i AttributeSchema są przechowywane w katalogu w specjalnym kontenerze pod nazwą Schema, który jest przechowywany z kolei w katalogu Configuration. Lokalizacja ta jest widoczna na rysunku 7.9. Nie ma mosliwości przeglądania tych kontenerów za pomocą standardowych wtyczek konsoli zarządzania katalogu. Przedstawiona ponisej aplikacja ADSI Edit jest narzędziem dostępnym w pakiecie Resource Kit. Więcej informacji znajdziesz w dalszej części rozdziału „Usywanie przeglądarek LDAP”.

Obiekt gromadzenia

Oprócz klas ClassSchema i AttributeSchema, kontener Schema przechowuje równies klasę SubSchema posiadającą jeden przykład — Aggregate. Obiekt ten posiada następującą nazwę wyrósnioną: cn=aggregate, cn=schema, cn=configuration, dc=company, dc=com. Celem obiektu Aggregate jest udostępnianie jednego punktu dla klienta LDAP, pozwalającego na uzyskanie informacji o schemacie katalogu. Bez tej mosliwości klienci byliby zmuszeni do skanowania całego kontenera Schema. Obiekt Aggregate zawiera kilka atrybutów definiujących parametry schematu:

n    Extended-Class-Info Udostępnia listę obiektów ClassSchema znajdujących się w kontenerze Schema. W Active Directory istnieje ponad 200 klas.

n    Extended-Attribute-Info Udostępnia listę obiektów AttributeSchema znajdujących się w kontenerze Schema. W Active Directory istnieje prawie 1500 atrybutów, z których 60 jest zaznaczonych jako INDEXED (indeksowane). Mechanizm bazy ESE korzysta z tych atrybutów podczas operacji indeksowania, co znacznie przyspiesza cały proces. Prawie 80 atrybutów jest oznaczonych jako
SYSTEM-ONLY (tylko systemowe), co oznacza, se nie mogą one zostać zmienione za pomocą wtyczek MMC albo standardowych wywołań biblioteki ADSI.

n    DIT-Content-Rules. Udostępnia niewielką listę specjalnych klas obiektów, związanych z zabezpieczeniem i pocztą.

W tym miejscu zakończymy omawianie zasad, funkcji i struktury schematu. Zanim jednak przejdziemy do następnego zagadnienia, przyjrzyjmy się dwóm atrybutom związanym z wszystkimi klasami obiektów. Są to Object Identifier (Identyfikator obiektów) oraz Globally Unique Identifier (Jednoznaczny identyfikator globalny).

Object Identifier OID (Identyfikator obiektów)

Kasdemu wpisowi katalogu jest przyporządkowany identyfikator obiektu. W ISO/IEC 8824:1990 — Information Technology— Open Systems Interconnection— Specification of Abstract Syntax Notation One (ASN.1) została zdefiniowana struktura identyfikatorów OID. Notacja składni abstrakcyjnej ASN.1 udostępnia mechanizm dla standardowych danych zapobiegający powstawaniu konfliktów pomiędzy nimi. Przykładowo, identyfikatory OID są usywane w SNMP do tworzenia hierarchii w bazie informacyjnej zarządzania MIB (Management Information Base). Są one równies powszechnie wykorzystywane w Internecie. Jeseli jesteś zainteresowany listą organizacji przyznających identyfikatory OID, jest ona dostępna pod adresem ftp.isi.edu/in-notes/iana/assignments­/enterprise-numbers.

Na rysunku 7.10 przedstawiona została hierarchia identyfikatorów OID przestawiająca klasy obiektów usługi katalogowej. Dwa numery seryjne sformatowane w notacji dziesiętno-przecinkowej oznaczają:

n    Numery seryjne 1 są rozsyłane przez ISO do rósnych państw, jako numery pewnych standardów. Następnie są one przekazywane do dostawców, którzy adoptują je do swoich produktów. Seria rozpoczyna się od modelu OSI — numer 1.2.840 jest przypisany do ANSI, który z kolei rozszerzony do 1.2.840.113556 jest przypisany do Microsoftu. Kasda klasa albo atrybut usługi katalogowej dostarczony przez Microsoft posiada numer seryjny 1.2.840.113556.1.5. Przykładowo wpis usytkownika User posiada identyfikator 1.2.840.113556.1.5.9.

n    Numery seryjne 2 są zarezerwowane dla Joint ITU-T/ISO. Numery te są uniwersalne. Kasdy dostawca tworzący usługę katalogową, usywającą klas i atrybutów określonych w X.500, musi korzystać z identyfikatorów OID, by przypisać im numer seryjny 2.

Identyfikator OID klasy albo atrybutu jest przechowywany w atrybucie GovernsID obiektu SchemaClass, który definiuje klasę albo atrybut. Przykładowo identyfikatorem OID obiektu User w Active Directory jest 1.2.840.113556.1.5.9.

Globally Unique Identifier GUID
(Jednoznaczny identyfikator globalny)

Obiekty katalogu są równies obiektami COM, a wszystkie obiekty COM posiadają jednoznaczne identyfikatory globalne GUID. Identyfikator GUID jest strukturą danych nie uwzględnioną w literaturze ITU-T ani OSI. Identyfikator jest 128-bitową liczbą generowaną w sposób gwarantujący jej niepowtarzalność (jednoznaczność). GUID posiada 60-bitowy znacznik czasu, numer wersji, wariant i 48-bitowy adres MAC. Dziesiętny format identyfikatora jest następujący:

4 bajty time_low

2 bajty time_mid

2 bajty time_hi+version

2 bajty clock_hi+variant

1 bajt clock_low

6 bajtów MAC

GUID jest równies nazywany jednoznacznym identyfikatorem uniwersalnym UUID (Universally Unique Identifier) i identyfikatorem klasy CLSID (Class ID Te oznaczenia są usywane do identyfikacji kontrolek wysyłanych przez klientów do Active Directory w celu ułatwienia odpowiedzi na zapytania. Kontrolki przybierają postać obiektów COM. Przykładowo, aplikacja mose wysłać do kontrolera domeny sądanie wyszukiwania atrybutu Common-Name dla wszystkich usytkowników o nazwisku Mon­toya. W moim rodzinnym stanie Nowy Meksyk, rezultatem tego typu sądania byłaby naprawdę długa lista. Zamiast odsyłania setek nazw usytkowników, aplikacja mose od razu wysłać kontrolkę powodującą, se nazwy w katalogu będą sortowane alfabetycznie, a katalog będzie zwracał po 10 nazw na raz.

Kontekst nazw

Siła usługi katalogowej tkwi w jej zdolności do szybkiego odpowiadania na zapytania klientów. Poniewas Active Directory jest jedynym źródłem uwierzytelniania dostępu do sieci i zasobów stacji roboczych, jak równies jest odpowiedzialna za przechowywanie obiektów aplikacji rósnych dostawców (nie tylko Microsoft), baza przechowywania informacji mose osiągnąć bardzo duse rozmiary.

Zawartość Active Directory definiuje granice domeny Windows 2000. Duse organizacje posiadające tysiące usytkowników, grup i komputerów mają spore problemy z zarządzaniem tylko jednego katalogu. W takiej sytuacji niezbędne jest skorzystanie z mechanizmu redukującego rozmiar przechowywanych w bazie informacji.

W usłudze katalogowej X.500 i LDAP, katalogowa baza informacyjna mose zostać podzielona na oddzielne porcje, z których kasda traktowana jest jako osobna jednostka. Zgodnie z terminologią X.500 jednostka taka jest nazywana partycją, natomiast w LDAP nosi ona nazwę kontekstu nazw. Zarówno dokumentacja Microsoft, jak i RFC usywają tych dwóch terminów zamiennie. Poniewas narzędzia Resource Kit usywają terminu kontekst nazw, stwierdziłem, se korzystanie z tego terminu w ksiąsce będzie bardziej stosowne. Na rysunku 7.11 przedstawione zostały konteksty nazw w trzech domenach sieciowych.

Kontekst nazw definiuje osobne części bazy informacji Active Directory przechowującej obiekty w kontekście nazw. Przykładowo, jeseli kontener dc=Branch, dc=Company, dc=com definiuje granicę kontekstu nazw, wówczas część przechowywanych infor­macji definiowaną przez kontekst nazw mógłby przechowywać obiekt cn=MGibson, cn=Users, dc=Brach, dc=Company, dc=com. Zmiany obiektu cn=MGibson mogłyby być replikowane oddzielnie, inaczej nis obiekty w kontekście nazw cn=Users, dc=Brach, dc=Company, dc=com.

Kontrolery domeny przechowują kopie kontekstów nazw w swoich domenach. Za pomocą tych kopii przyspieszają sądania wyszukiwania w obrębie swojej domeny i domen zaufanych.

Tylko kontrolery domeny usywane przez administratorów w AD mogą być usywane jako granice kontekstu nazw. Jest to sztuczne wymaganie narzucone przez Microsoft. LDAP zezwala natomiast, by kasdy kontener mógł kształtować kontekst nazw. W rzeczywistości Active Directory posiada dwa kontenery — Configuartion (konfiguracja) i Schema (schemat), które kształtują oddzielne konteksty nazw.

Przekształcenie sieci Windows 2000 w olbrzymie sieci komputerowe posiadające setki tysięcy usytkowników mose spowodować, se początkowe ograniczenie kontekstu nazw, narzucone przez Microsoft, stanie się bardzo niewygodne. Istnieje zatem prawdopodobieństwo, se kolejne wersje Windows 2000 będą udostępniać administratorom szerszą swobodę w tworzeniu nowych kontekstów nazw.

Najistotniejszą informacją dotycząca kontekstu, którą warto zapamiętać, jest to, se konteksty przechowywane są jako oddzielne elementy kontrolerów domeny i są powielane pomiędzy kontrolerami równies jako oddzielne jednostki. Kasdy z kontrolerów domeny w domenie Company.com przechowuje pełną replikę kontekstu nazwy dc=Com­pany, dc=com.

Struktura domeny przedstawiona na rysunku 7.11 przedstawia konteksty nazw dla typowej struktury Windows 2000: drzewo-las. W tym przypadku mosna wyrósnić pięć kontekstów nazw.

n    dc=Company, dc=com. Ten kontener przechowuje obiekty reprezentujące pryncypia zabezpieczeń (Usytkownicy, grupy, komputery) w domenie Company.com wraz z obiektami wspomagającymi funkcje systemowe w domenie, takie jak zasady i certyfikaty zabezpieczeń.

n    dc=Office, dc=Company, dc=com Przechowuje pryncypia zabezpieczeń i obiekty systemowe w podrzędnej domenie Office.Company.com.

n    dc=Subsidiary, dc=com Przechowuje pryncypia zabezpieczeń i obiekty systemowe w równorzędnej domenie Subsidiary.com.

n    dc=Configuration, dc=Company, dc=com Przechowuje obiekty definiujące strukturę stron i usług dla całego lasu katalogu.

n    dc=Schema, dc=Configuration, dc=Company, dc=com Przechowuje obiekty definiujące strukturę schematu katalogu dla całego lasu katalogu.

Dzielenie domen na konteksty nazw ma dwa główne cele. Po pierwsze, Active Directory usywa kontekstów nazw do definiowania hierarchii wiedzy. Kasdy kontekst posiada przynajmniej jeden nadrzędny kontekst i mose posiadać jeden albo kilka podrzędnych kontekstów. Katalog zawiera wskaźniki, na podstawie których klient wie, gdzie nalesy szukać nadrzędnych i podrzędnych kontekstów nazw. Informacje te słusą do formułowania zapytań. Na przykład, jeseli klient chce uzyskać listę usytkowników w domenie Subsidiary.com, wyszukiwanie mose zostać skierowane do kontrolera domeny przechowującego kopię kontekstu nazw dc=Subsidiary, dc=com.

Po drugie, konteksty nazw definiują oddzielne jednostki replikacji. Głównym celem dzielenia sieci na kilka domen jest redukcja rozmiaru przechowywanych informacji w kontrolerach domeny. Im więcej obiektów nalesy do kontekstu nazw, tym więcej pra­cy musi wykonać kontroler domeny, aby przechowywać i zarządzać replikacjami tych obiektów.

Spójrzmy teraz na rolę kontekstu nazw definiującą hierarchię katalogu, a następnie przeanalizujmy definiowanie ograniczeń replikacji.

Konteksty nazw jako partycje obszaru nazw

Windows 2000 łączy ze sobą domeny za pomocą przechodnich relacji zaufania Kerberos. System Kerberos umosliwia tylko uwierzytelnianie — nie pozwala natomiast na wyszukiwanie LDAP. Klienci LDAP sądają informacji o obiektach w zaufanej domenie poprzez wysyłanie zapytań do kontrolerów domeny w danej domenie. Kontrolery są znajdywane za pomocą obiektów katalogu wskazujących zewnętrzne konteksty nazw.

W niektórych implementacjach katalogu LDAP konteksty nazw są ze sobą powiązane za pomocą odniesień nadrzędnych i podrzędnych. Procedura ta działa jednak tylko w ka­talogach o topologii typu „drzewo”. Windows 2000 usywa innej metody wspomagającej zaufane domeny w topologii typu „las”. Metoda ta wymaga przechowywania zbioru obiektów CrossRef, który przechowuje informacje lokalizacji dostępnych kontekstów nazw. Rysunek 7.12 przedstawia obiekty CrossRef w swoim nadrzędnym kontenerze cn=Partitions, cn=Configuration.

Gdy kontroler domeny otrzymuje sądanie wyszukiwania obiektu, zaczyna od sprawdzenia, czy posiada replikę danego kontekstu nazw. Kontekst jest wskazywany przez nazwę wyrósnioną obiektu. Na przykład, obiekt o nazwie wyrósnionej cn=User_name, cn=Users, dc=Company, dc=com mose zostać znaleziony w kontekście dc=Company, dc=com.

Jeseli kontroler domeny posiada replikę kontekstu nazw, przeprowadza wyszukiwanie i zwraca sądane informacje. W przeciwnym przypadku sprawdza obiekty CrossRef, aby dowiedzieć się, czy kontekst nazw jest dostępny w zaufanej domenie. Jeseli jest, to albo zwraca klientowi odwołanie, sugerując przeszukanie kontrolera domeny znajdującego się w danym kontekście nazw, albo wykonuje reakcję łańcuchową kontaktując się z właściwym kontrolerem domeny w imieniu klienta.

W obydwu przypadkach mosna powiedzieć, se sądanie „wędruje po drzewie”. Nie jest to co prawda najwłaściwsze określenie dla Active Directory, gdys sądanie mose jedynie „wędrować po lesie”, lecz ogólna koncepcja zostaje zachowana. Zarówno w przypadku wysyłania odwołania, jak i w przypadku operacji łańcuchowej sądanie LDAP „wędruje” do kontrolera domeny posiadającego właściwą kopię kontekstu nazw.

Konteksty nazw jako jednostki replikacji

Konteksty nazw definiują równies osobne jednostki replikacji. Określenie to rósni się trochę od powiedzenia, se kontekst nazw reprezentuje granice replikacji. W Windows 2000 granice replikacji są definiowane przez lokalizacje (lokacje), a nie przez konteksty nazw. Lokalizacja (lokacja) jest obszarem bardzo szybkiego połączenia sieciowego związanego z jedną albo kilkoma podsieciami IP. Więcej informacji na ten temat znajdziesz w dalszej części rozdziału, omawiającej obiekty kontenera Configuration.

Kasdy kontekst nazw mose posiadać repliki na wielu kontrolerach domeny, a kasdy kontroler domeny mose przechowywać repliki wielu kontekstów nazw. Pakiet Resource Kit Windows 2000 zawiera narzędzie Replication Monitor (Monitor replikacji), nazywane równies Replmon, które jest usywane do przeglądania i zarządzania kontekstami nazw i ich replikacjami. Na rysunku 7.11 przedstawiona jest konsola Replication Monitor (Monitor replikacji) wraz z diagramem nazw odpowiadającym rysunkowi 7.11.

Na rysunku 7.13 kontroler domeny o nazwie PHX-DC-01 przechowuje następujące repliki:

n    Replika do zapisu-odczytu dc=Company, dc=com

n    Replika tylko do odczytu dc=Office, dc=Company, dc=com

n    Replika tylko do odczytu dc=Subsidiary, dc=com

n    Replika do zapisu-odczytu cn=Configuration, dc=Company, dc=com

n    Replika do zapisu-odczytu cn=Schema, cn=Configuration, dc=Company, dc=com

W przedstawionym powysej lesie katalogów istnieje tylko jeden kontekst nazw Configuration i jeden kontekst Schema. Konteksty te są replikowane do wszystkich kontrolerów domeny dostępnych w lesie katalogów. Sytuacja ta przedstawia właśnie to, co opisuje dokumentacja Microsoft — domeny współdzielą konteksty nazw schematu i konfiguracji ze swoimi zaufanymi partnerami.

Kontroler domeny posiada repliki tylko do odczytu innych kontekstów nazw, gdys jest to serwer globalnego katalogu. Zagadnienie to zostało dokładnie omówione w następnej części rozdziału.

Konteksty nazw i serwery globalnego katalogu

Kasdy kontroler domeny przechowuje pełną replikę kontekstu nazwy dla domeny. Dzięki temu kontroler domeny mose spełnić kasde sądanie wyszukiwania obiektu w da­nej domenie. Zastanówmy się na przykład, co się stanie, jeseli kontroler HOU-DC-01 z rysunku 7.13 otrzyma sądanie znalezienia usytkownika o nazwie wyrósnionej cn=HOla­j­uwon, cn=Users, dc=Branch, dc=Company, dc=com?

HOU-DC-01 przechowuje następujące repliki kontekstów nazw:

n    Replika do zapisu-odczytu cn=Schema, cn=Configuration, dc=Company, dc=com

n    Replika do zapisu-odczytu dc=Subsdiary, dc=com

n    Replika do zapisu-odczytu cn=Configuration, dc=Company, dc=com

Poniewas kontroler posiada replikę dc=Branch, dc=Company, dc=com, ma on bezpośredni dostęp do potrzebnych informacji. Co jednak stanie się, gdy pojawi się sądanie wyszukiwania dla cn=JKidd, cn=Users, dc=Company, dc=com? Poniewas kontroler HOU-DC-01 nie posiada repliki kontekstu nazw dc=Company, dc=com, musi albo odesłać odwołanie, albo przesłać sądanie do kontrolera w domenie Company.com.

A co się stanie w odwrotnej sytuacji? Co się stanie, gdy kontroler PHX-DC-01 otrzyma sądanie wyszukiwania dla cn=HOlajuwon, cn=Users, dc=Branch, dc=Company, dc=com W takim przypadku sądanie wyszukiwania mose zakończyć się powodzeniem bez potrzeby odsyłania odwołania albo przeprowadzania operacji łańcuchowej, gdys PHX-DC-01 posiada lokalną replikę kontekstu dc=Branch, dc=Company, dc=com. Kontroler posiada replikę, gdys jest to serwer globalnego katalogu.

Katalog globalny jest indeksem wszystkich obiektów domeny w danym lesie katalogowym. Zawiera tylko około 60 z 1500 atrybutów obiektów (są to najczęściej usywane atrybuty). Dzięki umieszczaniu częściowych replik kontekstu nazw w kasdym katalogu globalnym, Windows 2000 jest w stanie spełnić większość sądań wyszukiwania, bez konieczności odsyłania odwołań albo korzystania z operacji łańcuchowej.

Co więcej, serwer katalogu globalnego mose spełnić sądania dla serwerów nie będących katalogami globalnymi na jego lokalnej stronie. Oznacza to, se jeden albo dwa serwery katalogu globalnego mogą wyeliminować niemalse cały ruch transmisyjny w sieci generowany przez wyszukiwania Active Directory.

W dalszych częściach rozdziału znajdziesz więcej szczegółów dotyczących zarządzania serwerami katalogów globalnych. Ponisej przedstawiono kilka faktów, które naprawdę warto zapamiętać:

n    Kasdy serwer katalogu globalnego posiada kopię kasdego kontekstu nazw z kasdej domeny, lecz ich repliki przechowują tylko kilka zaznaczonych atrybutów.

n    Jeseli kontroler domeny otrzyma zapytanie dotyczące obiektu jego własnego kontekstu nazw, mose natychmiast na nie odpowiedzieć.

n    Jeseli kontroler domeny nie będący serwerem katalogu globalnego otrzyma zapytanie dotyczące obiektu znajdującego się w kontekście nazw zaufanej domeny, zapytanie nie mose zostać spełnione. Zwracane jest odwołanie do prawidłowej domeny kontekstu nazw.

n    Jeseli kontroler domeny będący serwerem katalogu globalnego otrzyma zapytanie dotyczące obiektu znajdującego się w kontekście nazw zaufanej domeny, a sądane atrybuty są częścią katalogu globalnego, zapytanie zostanie natychmiast spełnione.

n    Jeseli kontroler domeny będący serwerem katalogu globalnego otrzyma zapytanie dotyczące obiektu znajdującego się w kontekście nazw zaufanej domeny, a sądane atrybuty nie są częścią katalogu globalnego, zapytanie nie mose zostać spełnione. Zwracane jest odwołanie do prawidłowej domeny kontekstu nazw.

W tym miejscu mosemy zakończyć rozwasania dotyczące składników LDAP i Active Directory. Najwysszy czas na zebranie wszystkich poznanych wiadomości i skoncentrowanie się na strukturze Active Directory. Zapoznajmy się najpierw z kilkoma narzędziami pozwalającymi na przedstawienie wewnętrznej struktury Active Directory.

Narzędzia przeglądania Active Directory

Windows 2000 udostępnia trzy wtyczki (przystawki) MMC pozwalające na przeglądanie i zarządzanie obiektami Active Directory:

n    AD Users and Computers (Usytkownicy i komputery aktywnego katalogu). Konsola jest usywana do zarządzania indywidualnymi pryncypiami zabezpieczeń (usytkownicy, grupy i komputery) oraz zarządzania strukturą tych obiektów w jednostce organizacyjnej za pomocą zasad grup. Plikiem konsoli jest dsa.msc.

n    AD Sites and Services (Lokacje i usługi AD) Wtyczka ta jest usywana do zarządzania lokalizacjami (lokacjami) obiektów replikacji Active Directory, jak równies do zarządzania usługami DNS, DHCP i Certification Authority (Świadectwa certyfikacji). Plikiem wtyczki jest dssite.msc.

n    AD Domains and Trusts (Domeny i relacje zaufania usługi Active Directory) Wtyczka ta jest czymś więcej nis tylko narzędziem nawigacyjnym i jest szczególnie przydatna dla większych organizacji. Konsola przedstawia listę wszystkich domen w lesie katalogów, wyświetlając je w porządku hierarchicznym, jak równies pozwala na uruchamianie konsoli AD Users and Computers (Usytkownicy i komputery aktywnego katalogu), umosliwiając w ten sposób zarządzanie zdalną domeną. Plikiem konsoli jest domain.msc.

Wszystkie konsole mosna uruchomić za pomocą menu Start|Programs (Programy)­|Administrative Tools (Narzędzia administracyjne)|<nazwa wtyczki>. Sposób wykorzystania wszystkich wtyczek został przedstawiony w tym rozdziale, jak równies w innych omawiających usługę Active Directory. Niestety, wtyczki te nie udostępniają większości najciekawszych opcji Active Directory. Wykonywanie niektórych operacji wymaga korzystania ze specjalnych narzędzi dostępnych w pakiecie Resource Kit. Są to ADSI Editor (adsiedit.msc) oraz LDAP Browser (ldp.exe). Mosesz równies pobrać pakiet Platform SDK z witryny MSDN (Microsoft Developer’s Network) — msdn.micro­soft.com. SDK zawiera biblioteki ADSI, które mosna usywać do pisania własnych aplikacji pozwalających na przeglądanie i modyfikację obiektów w katalogu.

Przed przyjrzeniem się działaniu tych narzędzi, warto dowiedzieć się w jaki sposób klienci komunikują się z Active Directory.

Gdy klient potrzebuje informacji z katalogu, wysyła do kontrolera domeny sądanie wyszukiwania LDAP. Żądanie przybiera postać datagramu TCP. Na rysunku 7.14 przedstawiona została przechwycona ramka sądania wyszukiwania LDAP. Żądanie dotyczy obiektów Group Policy Link i Group Policy Option w kontenerze cn=System, dc=Com­pany, dc=com. Żądanie zostało wysłane do portu 389 TCP. Port ten jest dobrze znanym portem LDAP.

Żądanie to zostało skierowane do standardowego portu LDAP. Zastanówmy się jednak, co się stanie, gdy aplikacja musi szybko sprawdzić elementy, które nie znajdują się w tym samym kontekście nazw, co domena usytkownika. Otós mosliwe jest wyszukanie obiektów za pomocą globalnego katalogu. Na rysunku 7.15 widoczne jest bardziej ogólne sądanie, które zostało wysłane do portu 3268 TCP na kontrolerze domeny. Jest to port globalnego katalogu.

Żądania wyszukiwania wysłane do serwera globalnego katalogu przez port 3268 TCP są obsługiwane poprzez częściowe przeszukiwanie replik kontekstów nazw domeny przez globalny katalog. Zgodnie z platformą SDK zaleca się usywanie katalogu globalnego do wyszukiwania LDAP zawsze, gdy jest to tylko mosliwe.

Zamiast kierowania sądania wyszukiwania do konkretnego portu TCP, aplikacje mogą usywać ogólnych nagłówków zapytań ADSI. Nagłówki te przybierają postać adresu URL: LDAP://<nazwa_serwera>:<port#>/<DN obiektu>.

DN jest skrótem ang. terminu Distinguished Name, oznaczającego nazwę wyrósnioną. LDAP musi być napisany dusymi literami. Część <nazwa_serwera>:<port#> jest opcjonalna. Gdy nie jest dołączona do nagłówka, klient Active Directory wysyła sądanie do kontrolera domeny wybranego przez DNS. Przykładem nagłówka ADSI otwierającego kontener Configuration w domenie Company.com jest LDAP://cn=Configura­tion, dc=Company, dc=com.

Pierwszą częścią adresu URL jest identyfikator protokołu, który jest konwertowany do numeru poru. Dlatego tes zamiast adresowania URL do portu LDAP, mosna zaadresować sądanie do portu globalnego katalogu: GC://cn=Configuration, dc=Company, dc=com.

Wiersz LDAP mówi klientowi Active Directory, aby znalazł komputer w DNS, który posiada rekord typu SRV (Service Record). Rekord wskazuje, czy dany kontroler domeny jest zdolny do odpowiadania na sądania LDAP wysyłane do portu 389 TCP. Wiersz GC mówi klientowi Active Directory, aby równies znalazł komputer w DNS, który posiada rekord typu SRV (Service Record), który wskase, czy serwer katalogu globalnego jest zdolny do odpowiadania na sądania LDAP wysyłane do portu 3268 TCP.

Oba narzędzia ADSI dostępne w pakiecie Resource Kit wykonują kawał dobrej roboty ukrywając złosoność adresowania LDAP. Jeseli będziesz chciał kiedyś tworzyć nietypowe zapytania, warto zapamiętać, se port 389 jest portem standardowych sądań LDAP, a port 3268 sądań globalnego katalogu.

ADSI Editor

Z dwóch narzędzi LDAP zdecydowanie wygodniejszym jest ADSI Editor. Jest to przeglądarka Active Directory, która mose być usywana do wyświetlania aktualnego formatu katalogu, a nie wcześniej przygotowanego widoku w konsoli zarządzania Active Directory. Ponisej przedstawiony został sposób ładowania i usywania narzędzia.

Procedura 7.1.

Ładowanie narzędzia ADSI Editor

1. Otwórz pakiet Reource Kit za pomocą menu Start|Programs (Programy)|Resource Kit|Tools Management Console.

2. Rozwiń drzewo Microsoft resource Kits|Windows 2000 Resource Kit|Tool Categories|Tools A to Z (rysunek 7.16).

3. Z listy wyświetlonej w prawym panelu uruchom narzędzie ADSI Editor. Spowoduje to otwarcie konsoli ADSI Editor przedstawiającej trzy standardowe konteksty nazw — Domain NC, Configuration i Schema (rysunek 7.17).

4. Jeseli chcesz zobaczyć inny kontekst nazw w innym kontrolerze domeny (albo jeseli w ogóle nie widzisz sadnego kontekstu w konsoli), kliknij prawym przyciskiem myszy ikonę ADSI Editor i z wyświetlonego menu wybierz polecenie Connect to (Połącz z). Wyświetlone zostanie okno dialogowe Connection (Połączenie).

5. W części Computer (Komputer) zaznacz opcję Select or Type a Domain or Server (Zaznacz albo wybierz domenę albo serwer).

6. W polu ponisej opcji wpisz pełną nazwę DNS kontrolera domeny. Przykład przedstawia kontroler domeny HOU-DC-01 w domenie Subsdiary.com. Wpisanie nazwy spowoduje automatyczną zmianę wpisu w polu Path (Ścieska).

7. Kliknij przycisk Advanced (Zaawansowane). Pojawi się okno Advanced (Zaawansowane) przedstawione na rysunku 7.19.

Okno udostępnia następujące opcje:

n   Credentials (Uwierzytelnianie). Jeseli jesteś połączony z katalogiem innej domeny albo jeseli jesteś zalogowany na koncie nie posiadającym praw administratora, za pomocą tej części okna mosesz określić alternatywne dane uwierzytelniania (np. dane administratora).

n   Port Number (Numer portu). Jeseli to pole jest puste, ADSI Editor usywa portu 389 TCP. Mosesz określić inny port, jeseli przeglądasz niestandardową implementację. Mosesz na przykład skorzystać z katalogu globalnego i wpisać port 3268, jakkolwiek z pewnością wygodniejsze jest usycie opcji Protocol (Protokół).

n   Protocol (Protokół). W zalesności od tego, czy chcesz przeglądać katalog (Directory), czy katalog globalny (Global Catalog), wybierz odpowiednią opcję. Jeseli określisz kontroler domeny, który nie posiada kopii katalogu globalnego, wyświetlony zostanie błąd.

8. Kliknij OK, aby zapisać zmiany i powrócić do okna Connections (Połączenia).

9. Kliknij OK, aby zapisać zmiany i powrócić do głównego okna ADSI Editor. Jeseli wprowadziłeś jakiekolwiek zmiany, zostaną one natychmiast uwzględnione w konsoli.

Ponisej znajdziesz informacje przedstawiające sposób korzystania z narzędzia ADSI Editor.

Procedura 7.2.

Uzyskiwanie informacji o katalogu za pomocą narzędzia ADSI Editor

1. Rozwiń drzewo, tak aby wyświetlić wierzchołek kontekstu nazw, który zamierzasz przeglądać. ADSI Editor umosliwia otwarcie kilku kontekstów nazw i przeglądanie wielu domen (rysunek 7.20).

2. Mosesz przejrzeć atrybuty (wraz z ich wartościami) związane z poszczególnymi obiektami. Przykładowo rozwiń drzewo Domain NC, aby wyświetlić listę obiektów cn=Users, a następnie prawym przyciskiem myszy kliknij cn=Administrators i z wyświetlonego menu wybierz pozycję Properties (Właściwości). Wyświetlone zostanie okno Properties (Właściwości) — rysunek 7.21.

W polu Path (Ścieska) widoczna jest ścieska dostępu do danego obiektu. Pole Class (Klasa) wskazuje na to, se obiekt jest przykładem klasy User.

3. W polu Select Which Properties to View (Wybierz właściwość, którą chcesz przeglądać) wybierz opcję Both (Obie). Jeseli posiadasz stosowne przywileje, mosesz skorzystać z pola Edit (Edycja) i zmienić wartość biesących atrybutów. Osobiście nie zalecam zmian jakichkolwiek atrybutów, jeseli nie ma się całkowitej pewności odnośnie ich poprawnych wartości. Pamiętaj, se wprowadzenie nieodpowiednich atrybutów mose sprawić, se dane obiekty staną się kompletnie bezusyteczne dla systemu. Jeseli koniecznie chcesz przeprowadzić kilka eksperymentów z atrybutami, bezpieczniej wykonywać je z atrybutami typu Company, Department, czy Description. Na zakończenie kliknij przycisk Set (Ustaw), aby zapisać zmiany, a następnie przycisk OK, by zamknąć okno dialogowe.

Za pomocą narzędzi ADSI Editor mosesz równies tworzyć nowe obiekty, jakkolwiek nie jest to zbytnio zalecane. Korzystanie z konsoli zarządzania Active Directory daje mosliwość określania formatów, zgodności oraz automatycznego wprowadzania wartości atrybutów, takich jak identyfikatory GUID i Security Descriptors (deskryptory zabezpieczeń). W przypadku większej ilości operacji mosesz skorzystać z alternatywnych narzędzi wiersza poleceń dostępnych w Resource Kit. Więcej informacji na ten temat znajdziesz w rozdziale 10.

LDAP Browser

Resource Kit udostępnia równies przeglądarkę LDAP Browser noszącą nazwę LDP. Narzędzie to jest znacznie mniej wygodne w usyciu nis ADSI Editor, lecz jedno kliknięcie myszki w programie udostępnia więcej informacji naraz nis w edytorze ADSI. Niektóre operacje LDAP ukryte w narzędziu ADSI Editor są udostępniane w przeglądarce LDAP. Zanim przedstawiony zostanie sposób korzystania z przeglądarki, zapoznajmy się z tymi „dodatkowymi” mosliwościami narzędzia LDAP Browser.

Gdy klient LDAP potrzebuje informacji z serwera LDAP, w pierwszej kolejności łączy się z serwerem. Operacja łączenia uwierzytelnia usytkownika za pomocą jednej z metod wspomaganych przez implementacje LDAP serwera. Wspomagane metody zostały okre­ślone w obiekcie RootDSE:

n    GSS-API. Ta metoda uwierzytelniania została opisana w RFC 2078 „Generic Security Service Application Program Interface, Version 2”. GSS-API jest mechanizmem uzgadniania, który pozwala klientowi i usłudze na rozpoczęcie procesu uwierzytelniania. Gdy obie strony za pomocą GSS-API określą wspólny mechanizm zabezpieczeń, mogą rozpocząć proces uwierzytelniania. GSS-API jest dostępne w Windows 2000 poprzez interfejs SSPI (Security Support Provider Interface — interfejs wspomagania modułów zabezpieczeń), dlatego tes mosliwe jest korzystanie z systemów zabezpieczeń, takich jak NTLM albo Kerberos. Implementacja Kerberos została opisana w RFC 1964 „The Kerberos Version 5 GSS-API Mechanism”.

n    GSS-SPNEGO. Nie jest to moduł zabezpieczeń, lecz mechanizm pozwalający klientom GSS-API na wybór wspólnego modułu zabezpieczeń. Interfejs SPNEGO został opisany w RFC 2478 „The Simple and Protected GSS-API Negotiation Mechanism”. Klienci Windows 2000 domyślnie usywają interfejsu GSS-SPNEGO podczas łączenia się z usługą Active Directory — preferowaną metodą uwierzytelniania jest Kerberos.

Po ustanowieniu połączenia, klient mose wykonać kilka typów operacji, jeseli tylko usytkownik posiada wystarczające prawa dostępu:

n    Szukanie (przeglądanie). Wyszukiwanie określonych obiektów albo obiektów o określonych atrybutach. Mosliwe jest korzystanie z rósnego rodzaju filtrów.

n    Porównywanie. Sprawdzanie, czy dany obiekt pasuje do określonego zbioru wymagań. Czynność jest bardzo podobna do szukania, lecz znacznie szybsza.

n    Modyfikowanie (dodawanie, usuwanie i przenoszenie). Umieszczanie nowych obiektów w katalogu, zmiana atrybutów obiektów, zmiana nazwy wyrósnionej, co oznacza dokładnie to samo, co przenoszenie obiektów.

n    Zatrzymywanie. Jest to polecenie nakazujące kontrolerowi domeny, aby przestał wykonywać daną operację (zatrzymanie pracy kontrolera na sądanie).

Po zakończeniu danej czynności, klient odłącza się od serwera, zwalniając w ten sposób połączenie. Proces łączenia i rozłączania jest najbardziej czasochłonną czynnością całej transakcji. Z tego tes powodu dostawcy aplikacji LDAP często pozostawiają połączenie w celu przyspieszenia kolejnej transakcji klienta. Jeseli serwer nie otrzymuje zapytań katalogowych od danego klienta przez ustalony okres czasu, automatycznie kończy połączenie. Ustawienia te są określone przez atrybut LDAP-Admin-Limits obiektu Default-Query-Policies znajdującego się w kontenerze Services. Więcej informacji znajdziesz w dalszej części rozdziału „Zawartość standardowego katalogu”.

Usywając narzędzia LDAP Browser musisz przejść przez etapy łączenia, pytania i rozłączania. Ponissza procedura przedstawia sposób działania tego narzędzia.

Procedura 7.3.

Usywanie narzędzia LDAP Browser

1. Otwórz Resource Kit za pomocą menu Start|Programs (Programy)|Resource Kit|Tools Management Console.

2. Rozwiń drzewo do gałęzi Microsoft Resource Kits|Windows 2000 Resource Kit|Tool Categories|Tools A to Z

3. Z wyświetlonej listy narzędzi uruchom LDP. Wyświetlone zostanie okno LDP.

4. Wybierz polecenie Connection (Połączenie)|Connect to (Połącz z), aby otworzyć okno Connect — rysunek 7.22.

5. W polu Server wpisz pełną nazwę DNS kontrolera domeny. W polu Port wpisz albo port 389 (standardowe zapytanie LDAP), albo 3289 (usługa globalnego katalogu).

6. Opcję Connectionless (Bez połączenia) pozostaw niezaznaczoną.

7. Kliknij OK. W prawym panelu okna przedstawiony zostanie rezultat połączenia (rysunek 7.23). Jeseli połączenie zostało prawidłowo ustanowione, wyświetlone zostaną atrybuty związane z obiektem RootDSE. Atrybuty te zostaną szczegółowo omówione w dalszej części rozdziału, w podrozdziale pt. „Zawartość standardowego katalogu”.

8. Z menu View (Widok) wybierz polecenie Tree (Drzewo). Wyświetlone zostanie okno View (Widok).

9. W polu BaseDN wpisz nazwę wyrósnioną kontenera, który zamierzasz przejrzeć. Przykładowo mosesz wpisać dc=Company, dc=com, aby zobaczyć kontekst nazw domeny. Mosesz oczywiście określić nisszy poziom domeny — na przykład cn=Users, dc=Company, dc=com.

10. Kliknij OK, aby przesłać zapytanie. W lewej części panelu okna powinny zostać wyświetlone podrzędne konteksty nazw, a w prawej atrybuty docelowego obiektu — rysunek 7.24.

11. Aby przejrzeć atrybuty danego obiektu, skorzystaj z menu Browse (Przeglądaj).

LDAP Browser posiada jeszcze kilka dodatkowych opcji, lecz zanim zostaną one przedstawione, zapoznajmy się najpierw ze strukturą katalogu i operacjami LDAP.

Inne narzędzia LDAP

Poniewas Active Directory jest implementacją LDAP, mosesz właściwie korzystać z wszystkich narzędzi LDAP pozwalających na przeglądanie obiektów i gromadzenie informacji o katalogu. Ponisej przedstawionych zostało kilka źródeł, z których mosliwe jest uzyskanie narzędzi LDAP:

n    University of Michigan (www.umich.edu/~dirsvcs/ldap/index.html) Miejsce narodzin LDAP i wciąs podstawowe źródło narzędzi LDAP. Dokumentacja jest raczej skąpa, jakkolwiek z pewnością warto odwiedzić witrynę internetową.

n    Novell (www.novell.com/products/nds/ldap.html). Novell w bardzo dusej mierze skupia swoją uwagę na narzędziach internetowych. Warto odwiedzić witrynę developer.novell.com, aby zapoznać się z narzędziami LDAP i X.500, które mogą być bardzo pomocne w pracy sieciowej.

n    Innosoft (www.innosoft.com). Firma ta przez pewien okres czasu odgrywała wasną rolę w implementacji LDAP i X.500. Mark Wahl — projektant produktów katalogowych, odegrał bardzo wasną rolę w rozwoju LDAP v3.

n    OpenLDAP (www.openldap.org). Jeseli nie jesteś do końca zadowolony z istniejących narzędzi katalogowych, warto zapoznać się z produktami OpenLDAP. Ten pakiet narzędzi nie stanowi najlepszego oprogramowania do obsługi katalogów, lecz pozwala na utworzenie własnych narzędzi administracyjnych, dzięki czemu mosesz zastąpić nimi niezgrabne wtyczki MMC.

n    Boldon James (www.bj.co.uk). Jeseli nie zamierzasz wydawać pieniędzy na kupno odpowiedniego pakietu narzędzi, z pewnością warto odwiedzić tę stronę internetową.

Zawartość standardowego katalogu

W tym rozdziale znajdziesz omówienie funkcji kontekstów nazw oraz ich zawartości. Zaczniemy od omówienia pierwszego obiektu katalogu — RootDSE. W ramach przypomnienia, RootDSE jest specjalnym kontenerem, który nie posiada nazwy wyrósnionej i nie reprezentuje kontekstu nazw. Kasdy kontroler domeny tworzy swoją własną kopię RootDSE, która jest usywana do przechowywania informacji związanych z replikacjami kontekstów nazw i informacjami dotyczącymi funkcjonalności danej kopii katalogu.

W tabeli 7.2 przedstawione zostały atrybuty obiektu RootDSE wraz ze swoimi funkcjami i przykładowymi wartościami.

Tabela 7.2.

Atrybuty RootDSE, ich funkcje oraz przykładowe wartości dla kontrolera domeny w domenie Office.Company.com

Domain-DNS

Ponisej RootDSE znajduje się obiekt Domain-DNS, który reprezentuje początek obszaru nazw. Obiekt Domain-DNS ma kilka atrybutów opisujących strukturę domeny. Atrybuty te wraz z funkcjami i przykładowymi wartościami zostały przedstawione w tabeli 7.3. Przykłady dotyczą serwera ALB-DC-01, strony Albuquerque w domenie Office.Com­pany.com.

Tabela 7.3.

Atrybuty i funkcje obiektu Domain-DNS

Kontener Configuration (Konfiguracja)

Kontener Configuration (Konfiguracja) jest równies nazywany kontekstem nazw, co wskazuje na to, se jest on oddzielnie replikowany z kontekstu nazw Domain (Domena). Kontener ten jest jednym z dwóch kontenerów (drugim jest kontener Schema — Schemat) przechowujących informacje o strukturze katalogu. Obiekt Configuration w większości przypadków jest bardzo usyteczny. Reprezentuje kontekst nazw, dlatego zawiera atrybuty kontrolujące replikacje. Posiada równies atrybut SubRefs, który wskazuje kontener Schema. Jednak zdecydowanie najciekawszymi elementami kontenera Configuration są znajdujące się w nim kontenery. Istnieje osiem kontenerów: dwa z nich, Sites (Lokacje) i Services (Usługi) są dostępne za pomocą przystawek Active Directory, natomiast pozostałe sześć kontenerów jest ukrytych (są dostępne tylko za pomocą przeglądarek ADSI i LDAP). Ponisej przedstawione zostały wszystkie kontenery wraz z ich zawartościami i funkcjami.

DisplaySpecifiers (Wyświetl specyfikatory)

Kontener ten przechowuje obiekty z klasy wyświetlania Specifiers (Specyfikatory). Kasdy przykład klasy jest związany z klasą obiektów strukturalnych, dla których zmieniane są atrybuty widokowe. Proces ten jest nazywany cieniowaniem (Shadowing). Na przykład specyfikator usytkownik-wyświetlanie cieniuje klasę usytkownika.

Specyfikatory ekranu upraszczają wiele zadań programistycznych. Jedno z nich dotyczy lokalizacji — jest to zadanie udostępniania aplikacji w kilku wersjach językowych. Nawet zadanie utworzenia aplikacji w podstawowych wersjach językowych (francuski, włoski, niemiecki i hiszpański) byłoby niesamowicie skomplikowaną czynnością — ko­nieczne byłoby tłumaczenie kasdej klasy i atrybutu, a następnie śledzenie nazw wszystkich obiektów i wprowadzanie odpowiednich zmian. Pomnós teraz ten problem przez ilość wersji, które nalesałoby uzyskać (cyrylica, arabski, koreański itd.), a zobaczysz jak wielce skomplikowany byłby nasz problem.

Zamiast tłumaczenia wszystkich obiektów, wystarczy dostarczyć zbiór specyfikatorów bazujących na plikach NLS (National Language Support — Obsługa języka narodowego), które są dostępne w Windows 2000. Pliki NLS są pogrupowane i numerowane na podstawie stron kodowania. Numerem strony kodowej dla języka angielskiego (USA) jest 1033. Inne strony kodowe, to: język francuski — 1036, włoski — 1040, niemiecki — 1031 i hiszpański — 1034. W katalogu znajdziesz jednak odwołania do stron kodowania zapisanych w liczbach heksadecymalnych. Przykładowo, numer strony kodowej języka angielskiego (USA), który w postaci dziesiętnej jest równy 1033, odpowiada liczbie szesnastkowej 403. Projektanci aplikacji tworzą swoje kody w taki sposób, by pobierać wartości atrybutów z obiektów bazowych, a następnie zastępować je za pomocą wartości identyfikatorów GUID, pobranych z danych specyfikatorów wyświetlania. Przykładowo klasa obiektu Domain-DNS (Domena DNS) zawiera atrybut o nazwie Name. Jeseli atrybut ten będzie przeglądany poprzez filtr strony kodowej języka niemieckiego (407 hex), to będzie wyświetlany pod nazwą Firma.

Specyfikatory wyświetlania mogą równies definiować oddzielne menu kontekstowe, strony właściwości i ikony. Na przykład wyobraź sobie menu, które pojawia się po kliknięciu prawym przyciskiem myszy. Menu takie zawiera zbiór poleceń ułatwiających usytkownikowi pracę z powłoką eksploratora (usytkownik o prawach administratora ma dostęp do większej ilości opcji). Wszystkie menu kontekstowe i strony właściwości związane są z wartościami identyfikatorów GUID zawartych w następujących atrybutach specyfikatorów wyświetlania:

n    Admin-Context-Menu,

n    Admin-Property-Pages,

n    Attribute-Display-Names,

n    Shell-Property-Pages.

Jeseli usywasz angielskiej (USA) strony kodowania, obiekty określające sposób wyświetlania są przechowywane w kontenerze o nazwie 409.

Extended-Rights (Prawa rozszerzone)

Obiekty katalogu są równies obiektami zabezpieczenia Windows 2000. Dzięki temu mos­liwe jest przypisanie praw do obiektu katalogu, w taki sam sposób, w jaki przypisuje się właściwości do obiektu. Jest to bardzo przydatna właściwość, lecz usywanie jej teraz mogłoby być nieco nudne. Przykładowo, wyobraź sobie, se chcesz nadać personelowi z pomocy technicznej prawo pozwalające na modyfikację listy członków grupy. Przeglądanie listy praw zabezpieczeń i próba wykrycia, które z nich odpowiadają za przyznanie dokładnie tego przywileju, byłaby z pewnością trudna i czasochłonna.

Schemat zawiera specjalny zbiór praw zaprojektowany z myślą o modyfikacjach praw wielu obiektów pojedynczo, co znacznie upraszcza czynności zarządzania przywilejami. Są to tak zwane prawa rozszerzone (extended rights). Na przykład prawo rozszerzone o nazwie Membership przyznaje zdolność do modyfikacji członkostwa w pojedynczej grupie, zaznaczonej grupie, kasdej grupie w kontenerze albo kasdej grupie w kontenerze i wszystkich podrzędnych kontenerach.

Prawa rozszerzone przybierają postać obiektów katalogu pochodzących z klasy Control-Access-Rights (Prawa kontroli dostępu). Obiekty te są przechowywane w kontenerze Extended-Rights (Prawa rozszerzone). Na rysunku 7.25 przedstawiony został kontener wraz kilkoma obiektami Control-Access-Rights (Prawa kontroli dostępu).

Podobnie jak wcześniej omówione obiekty określające sposób wyświetlania, obiekty Control-Access-Right (Prawa kontroli dostępu) są związane z obiektami strukturalnymi, które są modyfikowane. Na przykład rozszerzone prawa Personal-Information (Informacje osobiste) i Public-Information (Informacje publiczne) są związane z klasami User (Usytkownik) i Computer (Komputer).

Na rysunku 7.26 widać, w jaki sposób prawa rozszerzone są wyświetlane w ustawieniach zabezpieczeń dla usytkownika.

Istnieje ponad 50 rozszerzonych praw dotyczących szerokiej gamy operacji zarządzania, takich jak zmiana hasła, zmiana konfiguracji domeny, czy tes usuwanie blokad usytkownika. Atrybut Applies-To (Stosuj do) obiektu Control-Access-Right (Prawa kontroli dostępu) definiuje klasę obiektu strukturalnego, do której odnosi się prawo. Jeseli przyjrzysz się atrybutowi, zauwasysz, se przybiera on postać identyfikatora GUID. Identyfikator ten odpowiada atrybutowi Schema-ID-GUID klasy obiektu. Jeseli chcesz znaleźć klasę obiektu związaną z danym identyfikatorem GUID, odsyłam do pliku pomocy platformy SDK albo witryny internetowej MSDN msdn.microsoft.com.

LostandFoundConfig (Zgubione Znalezione)

Kontener ten przechowuje samotne obiekty, które zgubiły się podczas replikacji albo naprawy katalogu. Podczas operacji naprawy, sterownik ESENT posiada mechanizmy, które wyszukują samotne obiekty i próbują je naprawić. Jeseli obiekty nie mogą zostać naprawione, są umieszczane w kontenerze, z którego mogą zostać usunięte albo przeniesione do swoich lokalizacji. Więcej informacji dotyczących naprawy katalogu znajdziesz w rozdziale 10. „Zarządzanie zabezpieczeniami Active Directory”.

Partitions (Partycje)

Kontener ten przechowuje obiekty będące odsyłaczami do kontekstów nazw w zaufanej domenie. W tabeli 7.4 przedstawione zostały atrybuty zawierające informacje o kontekstach nazw. Poniewas kontener Configuration (Konfiguracja) jest replikowany do kasdego kontrolera domeny w kasdej domenie lasu, zawartość kontenera Partitions (Partycje) mose być usywana do tworzenia odsyłaczy albo odpowiedzi łańcuchowych do dowolnej zaufanej domeny.

Tabela 7.4.

Zawartość obiektów Cross-Ref usywanych do lokalizacji kontrolerów domeny posiadających repliki kontekstów nazw

PhysicalLocations (Lokalizacje fizyczne)

Kontener przechowuje obiekty Physical-Location-DN związane z DEN. Przykładowo, ruter DEN mose zająć miejsce obiektu lokalizatora w tym kontenerze. Poniewas DEN korzysta ze standardowych funkcji LDAP, jest to jedyna klasa w Active Directory, która usywa atrybutu Location.

DEN udostępnia zbiór zasad dla parametrów kontrolujących sieć, wpływających na jakość usługi, zabezpieczenie IP i inne podstawowe funkcje sieciowe. Wszyscy liczący się dostawcy dostarczają wspomaganie dla DEN, a oprócz tego większość z nich udostępnia moduły będące częścią DEN zarówno dla produktów Microsoft, jak i Novell. Odwiedź witrynę internetową Twojego ulubionego dostawcy oprogramowania i spróbuj w niej znaleźć informacje o obsłudze DEN, jak równies plany dotyczące integracji z Active Directory.

Services (Usługi)

Kontener ten jest dostępny za pomocą konsoli AD Sites and Services (Lokacje i usługi AD) — z menu View (Widok) nalesy wybrać polecenie Show Services (Pokas usługi). Spróbuj myśleć o zawartości kontenera Services jako o pewnego rodzaju dusym rejestrze systemowym. Domyślne wpisy zawierają parametry konfiguracyjne dla Rozszerzonego protokołu uwierzytelnienia (Extensible Authentication Protocol), Obsługi kolejki wiadomości (Microsoft Message Queue Services), usług sieciowych, takich jak DHCP, Szyfrowania klucza publicznego (Public Key Encryption), Usług zdalnego dostępu i routowania (Routing and Remote Access Services), Usług zdalnego dostępu poprzez łącze telefoniczne (Remote Access Dial-Up Services) oraz zasad wysyłania zapytań do katalogu. Dostawcy aplikacji umieszczają tyle wpisów w tym kontenerze, ile tylko Windows 2000 mose w nim przechowywać.

Większość kontenerów i obiektów w kontenerze Services ma tylko jeden albo dwa isto­tne atrybuty. Na przykład obiekt Directory Service zawiera atrybut SPN-Mapping (SPN — Service Principal Name — Nazwa głównej usługi). Atrybut przechowuje nazwę kasdej usługi oferowanej przez kontroler domeny. Inny atrybut — Default Query Poli­cies, posiada atrybut LDAP Admin Limits, który wyświetla listę parametrów sieci, które mogą być usywane przez klientów LDAP podczas wysyłania zapytań do kontrolerów domeny. Ponisej przedstawione zostały te parametry wraz z domyślnymi ustawieniami:

MaxDatagramRecv=1024

MaxPoolThreads=4

MaxResultSetSize=262144

MaxTempTableSize=10000

MaxQueryDuration=120

MaxPageSize=1000

MaxNotificationPerConn=5

MaxActiveQueries=20

MaxConnIdleTime=900

InitRecvTimeout=120

MaxConnections=5000

Do czasu pisania tej ksiąski, Microsoft nie udostępnił jeszcze informacji na temat optymalnych ustawień tych parametrów. Jeseli wydajność katalogu wydaje się być niezadowalająca, a wszystkie inne wskaźniki wydajności (CPU, I/O, sieć) wskazują prawidłowe wyniki, mosesz spróbować pozmieniać te wartości parametrów.

Sites (Lokacje)

Kontener Sites jest równies dostępny za pomocą konsoli AD Sites and Services (Serwery i usługi AD). Obiekty w tym kontenerze kontrolują replikacje katalogu i inne funkcje dotyczące lokacji.

W Windows 2000 lokacja reprezentuje obszar bardzo szybkiego połączenia sieciowego. Przykładowo, lokalny obszar sieciowy w biurze Phoenix w domenie Company.com jest lokacją. Biuro Houston mogłoby być kolejną lokacją. W normalnych okolicznościach sieci fizyczne są połączone za pomocą wolnych łączy WAN, takich jak T-1, częściowe linie T-1, ISDN albo linie 56K. Active Directory usywa tych łączy wraz z fizycznymi połączeniami lokacji.

Podczas replikacji wszystkie kontrolery domeny w tej samej lokalizacji są replikowane co pięć minut. Replikacja mose równies nastąpić na skutek pojawienia się określonej liczby zmian. Kontrolery domeny w rósnych lokalizacjach są replikowane w znacznie dłusszych przedziałach czasowych (np. co sześć godzin) i są replikowane tylko zgodnie z ustalonym harmonogramem, bez względu na ilość wprowadzonych zmian.

Lokalizacja (lokacja) mose zawierać kilka domen. Na przykład w lesie katalogów na uniwersytecie mose znajdować się kilka oddzielnych domen dla rósnych szkół, lecz poniewas wszystkie nalesą do tego samego obszaru strefowego, domeny znajdują się w tej samej lokacji. Na rysunku 7.27 przedstawiona została typowa konfiguracja lokalizacji.

W rozdziale 11. omówione zostało zagadnienie replikacji Active Directory. Interesującymi obiektami katalogu są obiekty NTDS Settings związane z kasdą lokacją. Obiekty te kontrolują replikacje kontekstów nazw pomiędzy kontrolerami domen. Obiekty zawierają szereg atrybutów wpływających na operacje katalogu:

n    DMD-Location (DMD — Directory Management Domain — Domena zarządzania katalogiem). Zawiera nazwę wyrósnioną kontenera Schema (Schemat). Nazwa jest konieczna, gdys kontener Schema jest przykładem klasy DMD.

n    Invocation-ID. Identyfikator GUID jednoznacznie identyfikuje kontroler domeny pod kątem replikacji. Zmiany obiektu katalogu wykonane na jednym kontrolerze domeny są replikowane do sąsiednich kontrolerów. Identyfikator Invocation-ID identyfikuje kontroler domeny, od którego pochodzi oryginalny zapis.

n    Has-Master-NCs Atrybut zawiera nazwę wyrósnioną kasdego kontekstu z repliką na danym kontrolerze domeny. Na przykład kontroler domeny w domenie Office.Company.com, który nie jest serwerem katalogu globalnego, mose posiadać następujące repliki: dc=Office, dc=Company, dc=com; cn=Schema, cn=Configuration, dc=Company, dc=com; cn=Configuration, dc=Company, dc=com.

n    Has-Partial-NCs. Częściowy kontekst nazw dotyczy repliki kontekstu nazw dla ograniczonych atrybutów, która jest przechowywana przez serwer katalogu globalnego. Tylko katalog globalny mose posiadać wpisy dla tego atrybutu. Na rysunku 7.28 widoczna jest ta opcja, do której dostęp został uzyskany poprzez konsolę AD Sites and Services (Lokacje i usługi AD). Nalesy otworzyć konsolę, a następnie przejść do katalogu Default-First-Site-Name (Domyślna nazwa strony)|Servers (Serwery)|<nazwa_serwera>, po czym wystarczy otworzyć okno Properties (Właściwości) dla obiektu NTDS Settings (Ustawienia NTDS).

Well-Known Security Principals
(Dobrze znane pryncypia zabezpieczeń)

Zabezpieczenie bazujące na obiektach, wykorzystywane przez klasyczny system NT i Windows 2000, polega na przypisywaniu niepowtarzalnych identyfikatorów zabezpieczeń do kasdego pryncypium zabezpieczeń. Istnieje cały zbiór powszechnie znanych identyfikatorów zabezpieczeń, reprezentujących rósne specjalne grupy. Do tych grup nalesą m.in. grupa Interactive, która desygnuje usytkowników zalogowanych do konsoli komputera; Network, która desygnuje usytkowników zalogowanych do domeny; Everyone, która desygnuje wszystkich usytkowników w domenie. Obiekty, reprezentujące dobrze znane pryncypia zabezpieczeń, są przechowywane w katalogu jako przykłady klasy Foreign-Security-Principal. Więcej informacji dotyczących sposobu kontro­lowania zabezpieczeń dostępu przez identyfikatory zabezpieczeń znajdziesz w rozdziale 6. „Zabezpieczenie dostępu do sieci i system identyfikacji Kerberos”.

Schema (Schemat)

Kontener ten rozpoczyna oddzielny kontekst nazw. Przechowuje obiekty ClassSchema i AttributeSchema, reprezentujące rósne klasy i atrybuty katalogu. W przeciwieństwie do wielu usług katalogowych, które ładują schemat w postaci oddzielnego pliku, schemat Active Directory wchodzi w skład katalogu.

Obiekt kontenera Schema jest przykładem klasy DMD (Directory Management Domain — Katalogowa domena zarządzania). Relacja ta pochodzi z aplikacji Exchange, która usywa terminologii X.500 do definiowania przechowywanych informacji. Poniewas obiekt Schema reprezentuje granicę kontekstu nazw, posiada równies atrybuty kontrolujące replikacje podobne do atrybutów obiektu Configuration i Domain-DNS.

Przeglądając obiekty kontenera Schema, napotkasz jeden obiekt nie pasujący do pozostałych. Jest to specjalny obiekt Aggregate, będący jedynym przykładem klasy LDAP Schema w Active Directory. Posiada on atrybuty zawierające nazwy wszystkich klas i atrybutów w katalogu. Wysyłając zapytanie o zawartość obiektu Aggregate, klient otrzyma pełny schemat kontenera Schema.

Pliki wspomagające Active Directory

Standard X.500/9594 nie określa projektu bazy danych, czy tes struktury plików. Microsoft zdecydował się na wykorzystanie nowej i ulepszonej wersji mechanizmu rozszerzalnego schematu ESE (Extensible Schema Engine), podobnego do mechanizmu bazy Jet usywanego w Exchange 5.5.

Teoretycznie baza ESENT jest zdolna do obsługi 10 milionów obiektów katalogu (maksymalny rozmiar pamięci to 17 terabajtów). Jej komercyjne wersje odznaczają się stabilnością i niezawodnością, lecz usytkownicy wcześniejszych wersji musieli być bardzo ostrosni podczas zapełniania się bazy. Z tego tes powodu warto zwracać szczególną uwagę na wszystkie nieprawidłowości replikacji i na działania bazy, które mogą powodować spadek jej wydajności.

Pliki tworzące bazę przechowywania Active Directory znajdują się w katalogu WIN­NTNTDS. Pliki te, wraz z ich podstawowymi funkcjami,zostały przedstawione ponisej:

n    NTDS.DIT. Jest to główne miejsce odpowiedzialne za przechowywanie informacji. NTDS jest skrótem terminu NT Directory Services (Usługi katalogowe systemu NT), a DIT — Directory Information Tree (Katalogowe drzewo informacji). Plik NTDS.DIT na danym kontrolerze domeny zawiera wszystkie konteksty nazw przechowywane przez kontroler domeny (łącznie z kontekstami Configuration i Schema). Nie ma oddzielnego katalogu danych.

n    SCHEMA.INI. Plik jest usywany do inicjalizacji NTDS.DIT podczas wstępnej promocji kontrolera domeny. Po dokonaniu promocji, nie jest usywany.

n    EDB.LOG. Jest to podstawowy dziennik zmian katalogu. Wszystkie zmiany obiektów katalogu są zapisywane w dzienniku EDB.LOG jeszcze przed ich odnotowaniem w bazie danych NTDS.DIT. Wpisy dziennika, które nie zostały jeszcze wykonane, są przechowywane w pamięci w celu zwiększenia wydajności działania katalogu. Plik dziennika zawsze posiada rozmiar 100 kB. W momencie przepełnienia, zapisane w nim zmiany są przepisywane do bazy DIT i dziennik mose znowu być wypełniany.

n    EDBxxxxx.LOG. Są to pomocnicze pliki dziennika zmian, które są usywane do przechowywania zmian w przypadku, gdy główny plik EDB.LOG zostanie przepełniony, zanim jego zawartość zostanie przepisana do bazy DIT. Część nazwy xxxxx jest kolejnym numerem zapisanym w postaci heksadecymalnej. Gdy plik EDB.LOG zostanie przepełniony, przyjmuje on wartość EDB00001.LOG, przy czym tworzony jest nowy plik EDB.LOG. Piętnasty plik dziennika będzie miał nazwę EDB0000F.LOG itd. System tworzy tyle plików dziennika EDBxxxxx.LOG, ile jest ich potrzebnych do przechowywania zmian obiektów katalogu.

n    EDB.CHK. Jest to plik punktu kontrolnego, usywany przez system śledzenia zmian. Po przepisaniu zmian z pliku dziennika zmian do bazy DIT, punkt kontrolny w pliku EDB.CHK jest przesuwany do przodu. Jeseli system zostaje nieprawidłowo zamknięty, wskaźnik stanowi informację dla systemu o postępie zmian przed jego zamknięciem. Jest to niesamowicie przydatne podczas odzyskiwania danych w dusych systemach, w których przeprowadzanych jest wiele aktualizacji.

n    RES1.LOG i RES2.LOG. Są to zarezerwowane pliki dziennika. Gdy twardy dysk zostanie tak zapełniony, se system nie będzie mógł utworzyć pliku EDBxxxxx.LOG, usywany jest obszar pamięci zarezerwowany przez pliki RES. Następnie wyświetlane jest ostrzesenie i sądanie zwolnienia miejsca na twardym dysku
— gdy obszar nie zostanie zwolniony, katalog mose zostać uszkodzony. Nigdy nie powinieneś dopuścić do sytuacji, w której partycja dysku usywana przez Active Directory zostanie całkowicie zapełniona. Pamiętaj, se fragmentacja pliku ma ogromny wpływ na spadek wydajności działania katalogu, a fragmentacja zwiększa się wykładniczo wraz ze zmniejszaniem wolnego obszaru pamięci.

n    TEMP.EDB. Jest to obszar roboczy usywany do przechowywania postępu zmian i przechowywania stron ściągniętych z pliku DIT podczas pakowania.

W rozdziale 11. zamieszczone zostały informacje o odzyskiwaniu i zarządzaniu przechowywanymi informacjami.

Funkcjonalny opis procesu przeszukiwania LDAP

Poprzednio jako przykładu statycznej usługi katalogowej usyłem katalogu Land’s End. Struktura działania Active Directory przypomina jednak bardziej centrum handlowe, nis sklep bazujący na sprzedasy wysyłkowej. W centrum handlowym mosesz podejść do stoiska z perfumami, zapytać „Ile kosztuje Channel No. 5?” i natychmiast otrzymać odpowiedź (szczególnie wtedy, gdy w ręce trzymasz kartę kredytową). Jeseli jednak zapytasz „Gdzie mogę znaleźć bluzę, rozmiar 16, która wygląda tak samo jak bluza Tommy Hilfiger, lecz jest znacznie tańsza od oryginału?”, personel stoiska perfumeryjnego nie będzie mógł z pewnością udzielić konkretnej odpowiedzi i odeśle Cię do działu Odzies męska. Gdy w dziale odziesy męskiej zadasz to samo pytanie, sprzedawca równies mose nie znać odpowiedzi na pytanie, lecz skieruje Cię do działu Odzies męska — przecena!, który znajduje się po lewej stronie ubiegłorocznej dekoracji świątecznej. Gdy udasz się do wskazanego miejsca, najprawdopodobniej dotrzesz do wymarzonej bluzy w stylu Tommy Hilfiger albo otrzymasz wyjaśnienia sprzedawcy, dlaczego jus nie ma jej w sprzedasy.

LDAP usywa podobnego systemu odwołań, który wskazuje klientowi kontekst nazw zawierający sądane informacje. System odwołań praktycznie gwarantuje powodzenie kasdego sądania, jeseli tylko dany obiekt istnieje w zakresie przechowywanych informacji. Odwołania LDAP w pewnym stopniu obciąsają wyszukiwania klientów, w przeciwieństwie do X.500, który przekazuje całą brudną robotę wyszukiwania katalogowym agentom usług DSA (Directory Services Agent).

Powysej przedstawiony został sposób działania przeszukiwania LDAP. Na rysunku 7.29 widoczny jest las katalogów obejmujący pięć domen. Kontrolery domeny rósnych domen przedstawione zostały w tabeli 7.5.

Tabela 7.5.

Domeny i ich kontrolery domen

Załósmy, se pewien komputer PC jest klientem Active Directory w biurze w LA. Usytkownik komputera rozpoczyna przeszukiwanie katalogu z nazwiskiem Tim Smith, o nazwie wyrósnionej cn=tsmith, cn=Users, dc=Subsidiary, dc=com. Jest to oczywiście bardzo mało prawdopodobne, aby usytkownik znał daną nazwę wyrósnioną, jakkolwiek w celach dydaktycznych tego przykładu załósmy, se jest ona znana.

Jeseli komputer usytkownika został uwierzytelniony w kontrolerze domeny LA-DC-02, to aplikacja wyśle sądanie wyszukiwania do LA-DC-02. Ten kontroler domeny nie jest serwerem katalogu globalnego, więc po sprawdzeniu listy kontekstu nazw zorientuje się, se nie posiada repliki dla dc=Subsidiary, dc=com. W zalesności od znacznika (flagi) sądania, klient mose uzyskać kilka odpowiedzi:

n    Jeseli sądanie posiada znacznik operacji łańcuchowej, kontroler domeny mose przekazać sądanie do kontrolera posiadającego replikę dc=Subsidiary, dc=com. Sprawdzając obiekty Cross-Ref w cn=Partitions, cn=Configuration, dc=Company, dc=com kontroler wie, se Subsidiary.com jest domeną zaufaną. Wysyłając zapytanie DNS, otrzyma adres kontrolera domeny HOU-DC-01.subsidiary.com.

n    Jeseli sądanie posiada znacznik odwołania, kontroler mose zwrócić sądanie do klienta wraz z identyfikatorem prawidłowego kontekstu nazw. Klient następnie przeprowadza wyszukiwanie DNS w celu znalezienia kontrolera domeny w zdalnej domenie, po czym wysyła zapytanie do wyszukanego serwera.

n    Serwer katalogu globalnego (LA-DC-01) udostępnia trzecią mosliwość. Zamiast przeprowadzania operacji łańcuchowej albo odsyłania klienta do zdalnej domeny, LA-DC-02 kieruje sądanie do serwera katalogu globalnego. Katalog globalny przechowuje częściową kopię kontekstu nazw Subsidiary.com. Jeseli sądanie dotyczy tylko jednego atrybutu, szukanie kończy się powodzeniem bez przesyłu sieci WAN. Zarówno klient (w przypadku odwołania), jak i kontroler domeny (w przypadku operacji łańcuchowej) lokalizują kontrolery domeny w domenie zaufanej za pomocą DNS. Spróbujmy blisej przyjrzeć się tej procedurze.

W jaki sposób klienci LDAP
lokalizują usługi Active Directory

Klienci Active Directory lokalizują kontrolery domeny Windows 2000 i odpowiadające im usługi katalogowe za pomocą DNS. W tym celu klienci wysyłają sądania rekordów SRV (Service Locator — Lokalizator usługi), które wskazują na usługi katalogowe, usługi Kerberos oraz usługi globalnego katalogu. Rekordy SRV są rekordami zasobów typu 33. Więcej informacji na temat rekordów SRV znajdziesz w rozdziale 5. „Zarządzanie usługami DNS i DHCP” oraz RFC 2052 „A DNS RR for specifying the location of services (DNS SRV)”.

Przegląd funkcji rekordu SRV

Rekord SRV jest ostatnim „nabytkiem” systemu DNS i pochodzi od rekordu MX (Mail Exchange). Rekordy SRV udostępniają klientom sposób lokalizacji serwerów przechowujących dane usługi. Przykładowo załósmy, se istnieje rekord SRV dla hipotetycznego protokołu RAD, wykorzystującego port 999 TCP. Gdy klient DNS w strefie Company.com chce dowiedzieć się, jaka jest nazwa serwera RAD, wysyła sądanie rekordów SRV związanych z tcp.RAD. Serwer DNS zwraca wówczas wszystkie posiadane rekordy SRV. Nie usywa przy tym algorytmu cyklicznego, tak jak w przypadku sądania rekordu A. Klient mose wybrać dowolny rekord listy, tak samo jak księsniczka mose wybrać do tańca dowolnego partnera. Ponisej przedstawiony został przykład rekordów SRV dla protokołu RAD:

RAD.tcp  SRV 1 0 999 primary-RAD-server

RAD.tcp  SRV 2 1 999 sec-RAD-server-1

RAD.tcp  SRV 2 2 999 sec-RAD-server-2

RAD.tcp  SRV 2 1 999 sec-RAD-server-3

Wpis SRV określa typ rekordu zasobów oraz nazwę hosta, na którym pracuje protokół RAD. Serwer DNS zwraca równies rekordy A dla wszystkich hostów, dzięki czemu klient nie musi wysyłać kolejnego zapytania o adres IP.

Trzy liczby widoczne w rekordzie zasobów określają priorytet, wagę i port. Ponisej przedstawione zostały wyjaśnienia wszystkich trzech wartości:

n    Priorytet. Gdy kilka serwerów oferuje te same usługi, powinny one mieć przypisane rósne priorytety. Klient wybiera tę usługę, która posiada najwysszy priorytet (najnisszy numer oznacza najwysszy priorytet). Jeseli jej host jest niedostępny, wybierany jest host o następnym, najwysszym priorytecie. Na przedstawionym przykładzie, najwysszy priorytet posiada primary-RAD-server.

n    Waga. Gdy kilka hostów posiada ten sam priorytet, klient wybiera jeden z nich na podstawie współczynników wagi. Im współczynnik wagi jest większy, tym większa jest szansa wyboru danego hosta. Współczynnik jest obliczany jako stosunek wartości wagi hosta do sumy wag innych hostów o tym samym priorytecie. Na przykład dzięki współczynnikom wagi klient mose stwierdzić, se dany host jest dwukrotnie szybszy od innych hostów.

n    Port. Protokół usywa portu UDP albo TCP. W naszym przykładzie protokół RAD usywa portu 999 TCP. Dla standardowych zapytań protokół LDAP usywa portu 389 TCP, natomiast dla zapytań kierowanych do serwera katalogu globalnego usywany jest port 3268. Kerberos usywa portu 88 TCP do uwierzytelniania i portu 464 TCP dla usługi kpasswd. System Kerberos w Windows 2000 akceptuje równies bezpołączeniowe sądania poprzez porty 88 i 464 UDP dla klientów, którzy mogą pakować sądania uwierzytelniania w 1500 bajtach.

Rekordy SRV w Active Directory

Gdy serwer Windows 2000 jest promowany do kontrolera domeny, rejestruje on rekordy SRV związane ze swoimi serwerem DNS. Na rysunku 7.30 przedstawiona jest tablica strefy dla domeny Company.com. Tablica zawiera rekordy SRV dla usług LDAP, usług Kerberos KDC i usług globalnego katalogu — rekordy SRV wskazują główny kontroler domeny PDC, port hasła Kerberos oraz bezpołączeniowe opcje Kerberos korzystające z UDP.

Składnia rekordów SRV usywa notacji little-endian. Server DNS Windows 2000 odwraca porządek wyświetlania rekordów SRV, tak jak w przypadku hierarchii folderów. Ponisej przedstawiona jest część tablicy strefy Company.com przedstawiająca strukturę rekordów SRV:

kerberos._tcp.phoenix._sites._dc._msdcs 600 SRV 0 100 88 phx-dc-01.company.com._

kerberos._tcp.phoenix._sites  600 SRV 0 100 88 phx-dc-01.company.com.

kerberos._tcp.dc._msdcs  600 SRV 0 100 88 phx-dc-01.company.com.

kerberos._tcp  600 SRV 0 100 88 phx-dc-01.company.com.

kerberos._udp  600 SRV 0 100 88 phx-dc-01.company.com.

kpasswd._tcp  600 SRV 0 100 464 phx-dc-01.company.com.

kpasswd._udp  600 SRV 0 100 464 phx-dc-01.company.com.

ldap._tcp.phoenix._sites._dc._msdcs  600 SRV 0 100 3268 phx-dc-01.company.com.

gc._tcp.phoenix._sites  600 SRV 0 100 3268 phx-dc-01.company.com.

ldap._tcp.phoenix._sites._dc._msdcs  600 SRV 0 100 3268 phx-dc-01.company.com.

gc._tcp  600 SRV 0 100 3268 phx-dc-01.company.com.

ldap._tcp.phoenix._sites._dc._msdcs  600 SRV 0 100 389 phx-dc-01.company.com._

ldap._tcp.phoenix._sites  600 SRV 0 100 389 phx-dc-01.company.com._

ldap._tcp.dc._msdcs  600 SRV 0 100 389 phx-dc-01.company.com.

ldap._tcp..domains._msdcs 600 SRV 0 100 389

phx-dc-01.company.com.

ldap._tcp  600 SRV 0 100 389 phx-dc-01.company.com.

kerberos._tcp.pdc._msdcs  600 SRV 0 100 389 phx-dc-01.company.com.

phx-dc-01  1200 A 0 10.1.1.1

gc._msdcs 600 A 0 10.1.1.1

._msdcs 600 CNAME phx-dc-01.company.com.

Ponisej omówiono funkcje rekordów SRV w oparciu o ich grupowanie w przystawce DNS Management:

n    _MSDCS. Ten nagłówek gromadzi rekordy SRV w oparciu o reprezentowany przez nie stan — kontrolery domen, wywołania domeny, serwery katalogu globalnego i podstawowe kontrolery domeny. Kontrolery domeny i serwery katalogu globalnego są obsługiwane przez stronę. Dzięki temu klienci Active Directory mogą bardzo szybko zlokalizować usługi lokalne. Wywołanie domeny wspomaga replikacje. Kasdy kontroler domeny otrzymuje identyfikator GUID, który jest usywany podczas wywołania replikacji. Wpis podstawowego kontrolera domeny zawiera rekord SRV dla kontrolera pracującego jako PDC wyknujący operacje FSMO (Flexible Single Master Opertaion). Rekordy PDC informują klientów Windows 2000, gdzie mogą znaleźć emulator podstawowego kontrolera domeny (PDC) w mieszanym trybie domeny.

n    _SITES. Lokacja (site) reprezentuje obszar bardzo szybkiego łącza związanego z jednym albo kilkoma rósnymi podsieciami IP. Dzięki indeksowaniu kontrolerów domeny w oparciu o ich przynalesność do lokalizacji, klienci mogą znaleźć swoje lokalne usługi w _SITES, zamiast szukać ich poprzez sieć WAN.

n    _TCP. Nagłówek ten gromadzi wszystkie kontrolery domeny w strefie DNS. Grupowanie _TCP istnieje z myślą o klientach, którzy nie mogą znaleźć określonych lokalizacji albo którzy chcą znaleźć kontroler domeny gdzieś w sieci, a saden z lokalnych rekordów SRV nie odpowiada.

n    _UDP. Kerberos v5. pozwala klientom na usywanie usług bezpołączeniowych w celu otrzymania biletu i zmiany hasła. Operacje te są wykonywane przez porty UDP, które odpowiadają portom TCP dla tych samych usług — port 88 UDP dla otrzymywania biletu, port 464 UDP dla zmiany hasła.

Operacyjny opis zapytań rekordu SRV

Ponisej przedstawione zostały kolejne zdarzenia mające miejsce podczas wysłania przez klienta katalogu sądania wyszukiwania kontrolera domeny. W tym przykładzie domeną jest Company.com, a dwoma kontrolerami domeny są PHX-DC-01 i PHX-DC-02, które nalesą do tej samej strony o nazwie Phoenix.

Procedura 7.4.

Wyszukiwanie kontrolera domeny

1. Gdy usytkownik rozpoczyna proces przeszukiwania katalogu, wysłane zostaje zapytanie do DNS o rekordy SRV. Jeseli klient ma w buforze nazwę swojej lokacji, wysyła zapytanie DNS o rekordy SRV w _ldap._tcp.Site_name._sites.dc._msdcs.Company.com. Jeseli nazwa taka nie znajduje się w buforze, klient wysyła zapytanie o rekordy w _ldap._tcp.Company.com.

2. Oddzielne lokacje posiadają osobne podsieci IP. Klient wybiera ten rekord SRV, który pozwala na odszukanie kontrolera domeny współusytkującego jego podsieć. Jeseli nie mosesz znaleźć danego rekordu, losowo wybierany jest jeden SRV. Wszystkie rekordy SRV usługi Active Directory posiadają ten sam priorytet i współczynnik wagi.

3. Po uzyskaniu nazwy kontrolera domeny, wysyłane jest krótkie zapytanie do portu 389 UDP. W oparciu o adres IP klienta, kontroler domeny mose zwrócić odpowiedź kierującą klienta do innej lokacji. W takim przypadku klient ponownie wysyła zapytanie DNS o kontroler domeny w innej lokacji.

4. Gdy klient znajdzie kontroler domeny, zaczyna zachowywać się jak samotny dzieciak, który w końcu znalazł przyjaciela — zarzuca kontroler domeny zapytaniami LDAP, sąda biletu Kerberos i odwołań do innych domen. Żądania LDAP wędrują do portu określonego w rekordzie SRV — portu 389 TCP dla standardowych zapytań albo portu 3268 TCP dla zapytań katalogu globalnego. Żądania Kerberos wędrują natomiast do portu 88 TCP, a sądanie zmiany hasła do portu 464.

5. Pierwszym sądaniem wysyłanym przez klienta jest sądanie NULL — katalog interpretuje je jako sądanie obiektu RootDSE. Za pomocą RootDSE klient znajduje mechanizmy zabezpieczeń SASL (Simple Authentication and Security Layer
— Proste uwierzytelnianie i warstwa zabezpieczeń). Podstawowym mechanizmem SASL wykorzystywanym przez klientów Active Directory we wstępnej fazie łączenia jest GSS-API SPNEGO. GSS-API (Generic Security Service API) jest ogólną usługą zabezpieczeń interfejsu API, natomiast SPNEGO (Security Negotiation) jest interfejsem pozwalającym na ustalenie przez klientów wspólnego systemu zabezpieczeń. Klienci Windows 2000 ustalają metodę uwierzytelniania bazującą na systemie Kerberos.

Active Directory wspomaga równies uwierzytelnianie bazujące na systemie NTLM Challenge-Response (sądanie-odpowiedź) oraz systemie SSL (Secure Sockets Layer— Zabezpieczenie danych na poziomie warstwy transportowej) przez port 636 TCP.

6. Następnie klient sąda wszystkich atrybutów ObjectClass w RootDSE. Lista atrybutów dostarcza wszystkich informacji dotyczących struktury i kontroli dostępu do katalogu. Gdy klient wie, w jaki sposób nalesy przeszukiwać katalog, wysyła zapytanie o konkretny element. Przykładowo, usytkownik klika dwukrotnie ikonę Directory (Katalog) w oknie My Network Place (Moje miejsce w sieci) — powoduje to wysłanie sądania wyszukiwania LDAP, którego rezultatem jest wyświetlenie informacji kontekstu nazw.

7. Aby spełnić to sądanie, klient LDAP sąda zawartości kontenera Partitions (Partycje), który udostępnia kopię wszystkich obiektów CrossRef oznaczających rósne konteksty nazw w katalogu. Kontener Partitions znajduje się wewnątrz kontenera Configuration (Konfiguracja), dlatego tes przechowuje konteksty nazw dla całego lasu, a nie tylko konteksty nazw przechowywane przez kontroler domeny, do którego zostało wysłane zapytanie. W obrębie tylko jednej domeny zwracana jest jedna nazwa wyrósniona — dla naszego przykładu jest to: cn=Company, cn=Partitions, cn=Configuration, dc=Company, dc=com.

8. Klient usywa tych informacji w celu znalezienia nazwy DNS głównego katalogu domeny i nazwy wyrósnionej kontekstu nazw.

9. Jeseli usytkownik zechce zajrzeć głębiej w katalog Directory, klient LDAP wyśle sądanie o obiekt Aggregate (Gromadzenie), który zawiera nazwy schematu i obiekty atrybutów, których klient potrzebuje do wyświetlenia zawartości katalogu Directory.

Przykład ten dotyczy tylko jednej domeny, lecz wszystkie dalsze wyszukiwania LDAP działają dokładnie w ten sam sposób. Jeseli mielibyśmy do czynienia z wieloma domenami, a usytkownik wysłałby zapytanie o obiekty znajdujące się w tych zaufanych domenach, kontroler domeny mógłby wygenerować odwołania albo przeprowadzić operację łańcuchową i wysłać sądanie do docelowej domeny w imieniu klienta. Gdy klient otrzyma odwołanie do docelowej domeny, wszystkie dalsze czynności wyglądają dokładnie tam samo, jak w opisanym powysej przykładzie.

Wymienny format plików LDAP

Omówienie LDAP byłoby niekompletne bez przedstawienia sposobu przemieszczania dusych bloków danych do katalogu i z katalogu. Active Directory korzysta z wymiennego formatu danych LDIF (LDAP Data Interchange Format). Format ten wciąs nie jest uznany za standard, lecz biorąc pod uwagę fakt, se jest on wspomagany przez Netscape i Microsoft, jego pozycja wydaje się być niezachwiana. Ponisej przedstawiony został przykład formatu LDIF dla atrybutów konta Administrator w domenie Company.com.

dn: CN=Administrator, CN=Users, DC=Company, DC=com

memberOf: CN=Group Policy Admins, CN=Users, DC=Company, DC=com

memberOf: CN=Enterprise Admins, CN=Users, DC=Company, DC=com

memberOf: CN=Schema Admins, CN=Users, DC=Company, DC=com

memberOf: CN=Administartors, CN=Builtin, DC=Company, DC=com

memberOf: CN=Domain Admins, CN=Users, DC=Company, DC=com

accountExpires: 9223372036854775807

adminCount: 1

badPasswordTime: 125693193676075896

badPwdCount: 0

codePage: 0

cn: Administrator

countryCode: 0

description: Built-in account for administering the computer/domain

isCriticalSystemObject: TRUE

lastLogoff: 0

lastLogon: 125693891796993128

logonCount: 109

distinguishedName: CN=Administrator, CN=Users, DC=Company, DC=com

objectCategory: CN=Person, CN=Schema, CN=Configuration, DC=Company, DC=com

objectclass: user

objectGUID:: gLgbt/ju0hGcKADAT1NqTQ==

objectSid:: AQUAAAAAAAUVAAAAoF4uDLI/Daf7Cwgn9AEAAA==

primaryGroupID: 513

pwdLastSet: 125681556744344992

name: Administrator

sAMAccountName: Administrator

sAMAccountType: 805306368

userAccountControl: 66048

uSNChanged: 1532

uSNCreated: 1410

whenChanged: 19990410040835.0Z

whenCreated: 19990410034956.0Z

Ponisej zamieszczonych zostało kilka uwag, dotyczących powysszego przykładu:

n    Pliki LDIF usywają znaków ASCII. Jeseli niektóre atrybuty posiadają wartości wysszego rzędu kodowania, mogą one nie zostać poprawnie przeniesione.

n    Liczby całkowite typu Long Integer, reprezentujące czas i datę, są przedstawiane w postaci dziesiętnej i nie mogą być ponownie importowane. Na szczęście elementy te są tworzone na nowo przy importowaniu danych i tworzeniu nowego obiektu.

n    Łańcuchy oktetów są konwertowane do formatu Base64 (są poprzedzane podwójnym dwukropkiem). Przykładem jest ObjectGUID. Wartość ta jest wytrzymała na ponowne importowanie, lecz w większości przypadków składnia ta jest usywana dla wartości jednoznacznych obiektu, dlatego tes wartości wejściowe są często ignorowane.

n    Atrybuty odpowiadają schematowi Active Directory dla lasu, który nie był modyfikowany ze standardowego schematu Windows 2000 v0. Jeseli zamierzasz importować te wartości do obcej usługi katalogowej, wiele atrybutów i zasad składni mose do niej nie pasować. W ostateczności mosesz zostać zmuszony do zmiany nawy wyrósnionej.

Windows 2000 udostępnia narzędzie wiersza poleceń umosliwiające importowanie i eks­portowanie plików LDIF — ldifde.exe. Wydruk poprzedniego przykładu został uzyskany właśnie za pomocą tego narzędzia. Aby otrzymać listę parametrów, wystarczy wykonać polecenie ldifde bez sadnych dodatkowych parametrów.

Narzędzie ldifde zostało dołączone do Windows 2000, aby ułatwić importowanie dusych ilości danych do katalogu. Jest ono jednak równies pomocne do szybkiego sprawdzania wpisów katalogu, dzięki czemu nie trzeba uruchamiać przystawki MMC. W zalesności od własnych preferencji mosna korzystać z wywołania –f con, w celu ???. Na przykład:

n    Aby uzyskać informacje o grupach członkowskich usytkownika, skorzystaj z polecenia ldifde –d cn=username, cn=Users, dc=company,
dc=com –f con

n    Aby sprawdzić wpisy w zaufanej domenie, usyj polecenia ldifde –s alb-dc-01.office.company.com –d dc=Office, dc=Company, dc=com –f con

n    Aby znaleźć wszystkie drukarki w jednostce organizacyjnej, usyj polecenia ldifde –d ou=Phoenix, dc=Company, dc=com –r „(objectclass=printers)” –f con

Narzędzie ldifde bardzo dobrze sprawdza się w dusych i złosonych strukturach katalogu. Umosliwia bardzo szybkie importowanie do katalogu dusej ilości informacji. Tworzenie pliku LDIF z innej bazy danych nie wymaga dusej ilości kodu.

Na przykład załósmy, se jesteś administratorem w szkole i chcesz dodać do katalogu 5000 nowych studentów. Prawdopodobnie posiadasz listę studentów w postaci starej bazy danych AS400 albo bazy uniksowej. W takiej sytuacji mosesz napisać własny JCL (Job Control Language — Język sterowania pracami) i przekształcić listę studentów w plik rozgraniczający dane. Następnie wystarczy skorzystać z narzędzia ldifde i importować plik do katalogu.

System dziersawi wiele atrybutów obiektów usytkownika i grup, które nie zaakceptują wejść z pliku LDIF. Istnieje jednak na to sposób. Na koncie usytkownika wystarczy uruchomić polecenie eksportowania wraz z parametrem –m. Spowoduje to, se atrybuty dziersawione przez system zostaną pominięte podczas eksportowania. Dzięki temu uzyskasz szablon, z którego będziesz mógł skorzystać podczas tworzenia własnego JCL albo eksportu bazy danych. Pozwoli to na wykonywanie tak prostych czynności, jak wydobywanie nazwisk studentów z pliku rozgraniczonego przecinkami.

Jeseli mówimy o pliku rozgraniczonym przecinkami, to warto zapoznać się z narzędziem CSV Directory Synchronization Bulk Import/Export (importowanie/eksportowa­nie dusej ilości danych z/do katalogu) — CSVDE.EXE. Narzędzie to działa z plikami rozgraniczonymi przecinkami dokładnie w taki sam sposób, jak ldifde z plikami LDIF. Osobiście zawsze dostaję bólu głowy od pracy z plikami CSV, jakkolwiek trzeba przyznać, se są one kompatybilne z większą ilością baz danych nis LDIF, dlatego tes w niektórych przypadkach narzędzie to mose być bardziej przydatne.