Rozszerzanie schematu usługi Active Directory

Opublikowano: 6 sierpnia 2008

Zawartość strony

	Czym jest schemat?
	Struktura wewnętrzna
	Pozyskiwanie i wykorzystywanie identyfikatorów
	Definiowanie atrybutów połączonych
	Gotowi do rozszerzania schematu
	Dodawanie atrybutów
	Sprawdzanie i analiza systemu
	A co jeśli popełnimy błąd?
	Podsumowanie

Pobierz kod dla tego artykułu: Schema2008_05.exe (151KB)

Od czasu wprowadzenia usługi Active Directory wraz z systemem Windows 2000, firma Microsoft dostarczała swoim klientom podstawową definicję schematu dla implementacji katalogu Active Directory.

Pojawienie się usługi Active Directory® zrewolucjonizowało sposób pisania i implementowania aplikacji w systemie Windows®. Wcześniej aplikacje, takie jak np. Microsoft® Exchange 5.5, były budowane tak, aby zawierać własną strukturę katalogów. Jednak gdy dostępna stała się usługa Active Directory, wiele aplikacji (zarówno autorstwa firmy Microsoft, jak i innych firm) zaczęło wykorzystywać dostarczaną wraz z nią wewnętrzną strukturę, zamiast od podstaw budować własny schemat.

Aplikacje te rozpoczynały od podstawowej architektury dostarczanej przez usługę Active Directory, a następnie rozszerzały ją w zależności od potrzeb. Na przykład system Microsoft Exchange 2000 wykorzystywał usługę Active Directory do implementacji obsługi wiadomości, w efekcie definiując przyszłość architektury systemów obsługi wiadomości firmy Microsoft.

Obecnie większość aplikacji działających w środowisku Active Directory potrzebuje do funkcjonowania wewnętrznego schematu, a wiele definiuje również jego modyfikacje dostosowane do własnych potrzeb. Wiąże się to oczywiście z rozszerzaniem schematu, które stanowi temat niniejszego artykułu. Ponadto ponieważ tak wiele aplikacji bazuje na podstawowych definicjach usługi Active Directory, konieczne jest zapewnienie trwałości podstawowego schematu. Wiele aplikacji pracuje równolegle w tym samym środowisku Active Directory, a zatem zmiany dokonane dla jednej aplikacji nie mogą wpływać na pozostałe.

Czym jest schemat?

Dla wielu osób, które postrzegają schemat usługi Active Directory jako kompletny produkt, wizja samodzielnego modyfikowania schematu może wydawać się dość onieśmielająca. Oczywiście rozszerzanie schematu usługi Active Directory nie jest czymś, co musimy wykonywać na co dzień, ale pewne aplikacje lub sytuacje biznesowe mogą tego wymagać. Dlatego tak ważne jest, aby zrozumieć, czym jest schemat i co zawiera. Usługa Active Directory stanowi bardzo istotny zasób w wielu organizacjach i uszkodzenie jej działania z powodu nieprawidłowej aktualizacji może mieć poważne konsekwencje.

Istnieje wiele organizacji, które nie decydują się na rozszerzanie schematu usługi Active Directory i wolą zastosować usługę Active Directory Lightweight Directory Service (ADLDS) w systemie Windows Server® 2008 (lub Active Directory Application Mode - ADAM w systemie Windows Server 2003) jako alternatywną strategię testowania lub bezpośredniego implementowania dostosowanych definicji schematu.

Schemat stanowi wewnętrzną strukturę, która odpowiada za format usługi katalogowej. Schemat usługi Active Directory definiuje klasy oraz atrybuty obiektów, które są wykorzystywane w ramach usług Active Directory Domain Services (ADDS). Podstawowy schemat zawiera definicje dla wielu znanych klas, takich jak użytkownik (user), komputer (computer) czy jednostka organizacyjna (organizationalUnit) oraz atrybutów, takich jak numer telefonu (telephoneNumber) czy identyfikator zabezpieczeń (objectSID). Obiekty znajdujące się w podstawowej definicji schematu znane są jako obiekty kategorii 1, a obiekty dodane nazywane są obiektami kategorii 2.

Schemat usługi Active Directory można znaleźć w kontenerze zdefiniowanym przy pomocy ścieżki cn=Schemat, cn=Konfiguracja,dc=X, gdzie X stanowi obszar nazw w lesie usługi Active Directory. Warto zauważyć, że las usługi Active Directory zawiera jedynie pojedynczy schemat, co powoduje, że modyfikacja definicji schematu w lesie wpływa na wszystkie znajdujące się w nim domeny. Rysunek 1 prezentuje liczbę klas i atrybutów dodanych do schematu usługi Active Directory w różnych wersjach systemu Windows Server.

Rysunek 1: Liczba klas i atrybutów.

Aktualizacja schematu dla różnych wersji systemu Windows Server jest dokonywana przy użyciu narzędzia o nazwie Adprep. Wraz z zainstalowaniem aktualizacji w systemie Windows Server 2003 R2 wersja schematu zostaje zmieniona na 31, a w systemie Windows Server 2008 na 44.

Można to zweryfikować, sprawdzając wartość atrybutu objectVersion cn=Schemat,cn=Konfiguracja,dc=X w usłudze Active Directory przy użyciu narzędzia takiego jak ADSIEdit. Warto podkreślić, że pewne aplikacje np. Exchange Server czy System Management Server (SMS), które są zależne od usługi Active Directory, mogą modyfikować schemat w zależności od własnych potrzeb.

 Do początku strony

Struktura wewnętrzna

Usługa Active Directory składa się z dwóch typów obiektów: classSchema (w skrócie klasy) oraz attributeSchema (w skrócie atrybuty). Potrzeba rozszerzania schematu usługi Active Directory pojawia się zazwyczaj, gdy organizacja chce przechowywać pewne dane w specyficznych atrybutach, które nie są dostępne w istniejącym schemacie. Można stworzyć atrybut w schemacie usługi Active Directory, określając obiekt attributeSchema w kontenerze schematu, a następnie definiując niezbędne właściwości dla nowego obiektu.

Lista właściwości dla obiektów attributeSchema wraz z informacją na ich temat jest dostępna pod adresem go.microsoft.com/fwlink/?LinkId=110445. Jak można się przekonać, istnieje wiele właściwości, które można definiować dla obiektów attributeSchema, część z nich jest obowiązkowa.

Poza standardowymi atrybutami, w schemacie znajdują się również atrybuty specjalne, nazywane atrybutami połączonymi, które są implementowane parami poprzez dostarczenie odsyłacza do przodu i odsyłacza wstecznego. Weźmy pod uwagę na przykład członkostwo w grupie w usłudze Active Directory. Atrybut Członek (member) dowolnej grupy (na przykład John Doe należący do grupy o nazwie ContosoEmployees) jest odsyłaczem do przodu, a odpowiadający mu atrybut Członek grupy (memberOf) obiektu członek stanowi odsyłacz wsteczny. Dzięki temu, gdy zadawane jest na przykład zapytanie o atrybut memberOf obiektu John Doe, zwracana jest nazwa wyróżniająca (Distinguished Name – DN) grupy ContosoEmployees.

Odsyłacz do przodu zachowuje się podobnie do pozostałych atrybutów. Wartości mogą być jedno lub wielowartościowe (np. atrybut member może zawierać wiele obiektów - członków grupy) i są przechowywane w katalogu razem z obiektem nadrzędnym.

Natomiast odsyłacze wsteczne są utrzymywane przez system w celu zapewnienia integralności referencyjnej. Gdy pytamy o wartość atrybutu odsyłacza wstecznego, odpowiedź zostanie wyprowadzona na podstawie wszystkich pasujących wartości odsyłacza do przodu. Łącza wsteczne są zawsze wielowartościowe.

Każda klasa obiektu w usługach ADDS jest definiowana przez obiekt classSchema w kontenerze schematu. Lista atrybutów niezbędnych do pomyślnego zdefiniowania obiektu classSchema dostępna jest pod adresem go.microsoft.com/fwlink/?LinkId=110445.

Można określać trzy typy klas: strukturalne, abstrakcyjne oraz pomocnicze. Typy te są definiowane przez wartość atrybutu objectClassCategory. Istnieje także czwarta kategoria, zwana 88, która zawiera klasy zdefiniowane przed wprowadzeniem standardu X.500 (1993). Ten typ klasy charakteryzuje się wartością 0 w atrybucie objectClassCategory, jednak nie należy go już definiować.

 Do początku strony

Pozyskiwanie i wykorzystywanie identyfikatorów

Identyfikatory każdego z obiektów classSchema oraz attributeSchema w katalogu są definiowane przy użyciu obowiązkowego identyfikatora obiektu (OID), który jest określony przez governsID dla obiektów classSchema oraz przez attributeID dla obiektów attributeSchema. Są to unikatowe wartości numeryczne dostarczane przez ustalone urzędy wystawiające w celu identyfikowania obiektów. Numerowanie jest nadzorowane przez definicję protokołu LDAP (RFC 2251). Niektóre identyfikatory OID w schemacie usługi Active Directory są wystawiane przez organizację International Organization for Standardization (ISO), a inne przez firmę Microsoft. Identyfikator OID musi być unikatowy dla każdego z obiektów w katalogu.

Identyfikator OID stanowi łańcuch liczb, np. 1.2.840.113556.1.y.z, które zostały objaśnione na Rysunku 2. Na przykład identyfikator OID dla obiektu użytkownika classSchema to 1.2.840.113556.1.5.9.

Rysunek 2: Identyfikator dla obiektu użytkownika.

Gdy organizacja ma zamiar rozszerzyć schemat, zapewnia unikatowość identyfikatora OID, pozyskując własny główny numer OID. Numer ten jest następnie rozbudowywany w celu zapewniania unikatowych identyfikatorów dla nowych klas obiektów oraz atrybutów tworzonych przez tę organizację. Główny identyfikator OID można pozyskać bezpośrednio z organizacji ISO National Registration Authority (NRA), którą w Stanach Zjednoczonych jest American National Standards Institute (ANSI).

Szczegóły dotyczące procedury i opłat związanych z pozyskiwaniem głównego identyfikatora OID znaleźć można w witrynie ansi.org. W przypadku innych regionów należy skontaktować się z odpowiednią organizacją członkowską ISO. Lista członków ISO znajduje się pod adresem iso.org/iso/about/iso_members.htm.

Kiedyś organizacje mogły pozyskiwać identyfikator OID od firmy Microsoft, wysyłając wiadomość e-mail na adres schemreg@microsoft.com. Jednak obecnie skutkuje to otrzymaniem automatycznej odpowiedzi z prośbą o pobranie i uruchomienie skryptu VBScript dostępnego pod adresem go.microsoft.com/fwlink/?LinkId=110453.

W przypadku identyfikatorów OID wystawianych przez firmę Microsoft, liczba jest przypisywana w ramach przestrzeni numerów firmy Microsoft OID: 1.2.840.113556.1.8000.x, gdzie x to unikatowy numer przypisany do organizacji. Organizacje mogą dodatkowo rozdzielać te identyfikatory OID w celu identyfikowania obiektów. A zatem organizacja może wykorzystywać numery 1.2.840.113556.1.8000.x.1.y dla nowych obiektów classSchema oraz 1.2.840.113556.1.8000.x.2.z dla obiektów attributeSchema (gdzie x reprezentuje unikatowy numer organizacji, a y oraz z to numery przypisywane odpowiednio określonym obiektom classSchema oraz attributeSchema). Zaleca się również, aby w nazwach obiektów wykorzystywać charakterystyczny dla organizacji przedrostek w celu ich wyróżnienia.

 Do początku strony

Definiowanie atrybutów połączonych

Ważne jest, aby atrybut attributeSyntax odsyłacza do przodu miał wartość 2.5.5.1, 2.5.5.7 lub 2.5.5.14. Wartości te odpowiadają składniom obejmującym nazwę wyróżniającą, jak np. składnia obiektu (DS-DN).

Atrybut attributeSyntax odsyłacza wstecznego musi mieć wartość 2.5.5.1, czyli składni obiektu (DS-DN). Tradycyjnie atrybuty odsyłacza wstecznego są dodawane do wartości mayContain klasy abstrakcyjnej najwyższego poziomu. To umożliwia odczytywanie atrybutu odsyłacza wstecznego z obiektów dowolnej klasy, ponieważ atrybuty odsyłacza wstecznego nie są w rzeczywistości składowane z obiektem. Zamiast tego są one wyprowadzane na podstawie wartości odsyłaczy do przodu.

W systemie Windows Server 2003 wprowadzono funkcję, którą organizacje mogły wykorzystać do łączenia dwóch obiektów w schemacie, a mianowicie automatyczne generowanie identyfikatorów linkID. Dzięki tej funkcji system automatycznie generuje identyfikator linkID dla nowego atrybutu połączonego, gdy jego atrybut linkID jest ustawiony na 1.2.840.113556.1.2.50. Odpowiadający mu odsyłacz wsteczny jest tworzony poprzez ustawienie w linkID wartości attributeId lub ldapDisplayName odsyłacza do przodu. Bufor schematu musi zostać ponownie załadowany po stworzeniu odsyłacza do przodu i przed stworzeniem odsyłacza wstecznego. W przeciwnym wypadku atrybuty attributeId lub ldapDisplayName odsyłacza do przodu nie zostaną odnalezione, gdy tworzony będzie odsyłacz wsteczny. Bufor schematu jest ładowany ponownie na żądanie, kilka minut po dokonaniu zmiany schematu lub po ponownym uruchomieniu kontrolera domeny.

Gdy usługa Active Directory działa w systemie Windows 2000, identyfikatory linkID trzeba otrzymać od firmy Microsoft, wysyłając e-mail pod adres schemreg@microsoft.com. W automatycznej odpowiedzi pojawi się następująca linia: "E-mails sent to schemreg@microsoft.com will be processed only if they are related to linkID registrations for legacy environments." Dlatego w wiadomości e-mail należy dostarczyć następujące informacje: nazwę firmy, nazwę kontaktu, adres e-mail, numer telefonu, zarejestrowany przedrostek (o ile dotyczy), zarejestrowany OID (o ile dotyczy).

 Do początku strony

Gotowi do rozszerzania schematu

Powiedzmy, że zdecydowaliśmy się na rozszerzenie schematu usługi Active Directory. W efekcie przeprowadzonych analiz zrezygnowaliśmy z zastosowania alternatywnego katalogu zaimplementowanego przy użyciu usługi ADLDS (lub ADAM w Windows Server 2003), ponieważ nie spełnia ona naszych wymagań. W kolejnym kroku zidentyfikowaliśmy nowe obiekty attributeSchema, które chcemy dodać do schematu oraz jednocześnie zdefiniowaliśmy wszystkie wymagane wartości (m.in. cn, ldapDisplayName), które charakteryzują te nowe obiekty. W ramach definiowania wartości atrybutów dla obiektu zdobyliśmy również identyfikator OID, otrzymując go firmy Microsoft lub pozyskując z innego źródła. Dostatecznie udokumentowaliśmy powyższe ustalenia jako wymagania biznesowe oraz specyfikacje techniczne. Ponadto zaimplementowaliśmy środowisko laboratoryjne, które odwzorowuje usługę Active Directory i jest gotowe do testów.

Wiele organizacji tworzy nawet komisje, które zajmują się zatwierdzaniem lub odrzucaniem tego typu zmian i nadzorowaniem procesu ich wprowadzania. Takie modyfikacje i analizy stały się nieodzowne, od kiedy usługa Active Directory zaczęła być w wielu organizacjach wykorzystywana jako rzetelne źródło informacji. Dlatego tak istotne jest podtrzymywanie jej działania po dokonaniu zmian.

Gdy organizacja zdecyduje się na zmiany, trzeba zdefiniować plany testów i implementacji dla projektu. Można rozszerzyć schemat, dodając nowe obiekty przy użyciu przystawki dla schematu usługi Active Directory w konsoli Microsoft Management Console (MMC) lub przy użyciu programowych lub częściowo programowych metod rozszerzania schematu (np. wykorzystując narzędzie LDIFDE do zaimportowania plików w formacie .ldif, CSVDE do zaimportowania plików w formacie .csv bądź stosując Active Directory Service Interfaces, ADSI lub skrypty).

Niezależnie od wybranej metody, to zadanie musi zostać zrealizowane na serwerze, który pełni rolę FSMO Wzorzec schematu w lesie usługi Active Directory (lub jest połączony z serwerem pełniącym tę rolę). Ponadto aby można było dokonać modyfikacji, konto wykorzystywane do aktualizacji schematu musi posiadać odpowiednie uprawnienia administratorskie, a zatem należy dodać to konto do grupy Administratorzy Schematu. Na zakończenie trzeba umożliwić aktualizacje schematu dla lasu (domyślnie są one wyłączone).

O ile zmiana nie jest bardzo prosta, należy dokonać jej w sposób zautomatyzowany, co pomaga zachować zalecany podział faz testowania oraz wdrażania oraz wyeliminować pewnego typu błędy, które mogą wynikać z własnoręcznej realizacji zadania. Przypuśćmy, że zdecydujemy się na zaimplementowanie zmiany przy użyciu narzędzia LDIFDE. Aby zastosować aktualizację podczas rozszerzania schematu, dodajemy nowe atrybuty oraz klasy, dodajemy nowe atrybuty do klas, a następnie wywołujemy ponowne załadowanie bufora. Prześledźmy kilka scenariuszy.

 Do początku strony

Dodawanie atrybutów

Dla przykładu przypuśćmy, że organizacja o nazwie Contoso chce dodać do swojej usługi Active Directory atrybut, który identyfikuje rozmiar buta każdego z pracowników. Las usługi Active Directory posiada dwie domeny: contoso.com oraz employees.contoso.com. Wymaganie jest takie, że wszystkie obiekty stworzone przy użyciu definicji klasy użytkownika powinny posiadać także ten nowy atrybut.

Musimy pamiętać, że modyfikacja schematu wpłynie na obie domeny, ponieważ znajdują się one w tym samym lesie. Przypuśćmy, że od firmy Microsoft otrzymaliśmy numer OID 1.2.840.113556.8000.9999 i że podzieliliśmy go dodatkowo na 1.2.840.113556.8000.9999.1 dla obiektów classSchema oraz 1.2.840.113556.8000.9999.2 dla obiektów attributeSchema. Teraz zajmiemy się zdefiniowaniem wszystkich wartości atrybutów dla tego nowego obiektu, jak pokazano na Rysunku 3.

Rysunek 3: Definiowanie atrybutu contosoEmpShoe.

Choć atrybut contosoEmpShoe musi być dostępny dla wszystkich obiektów tworzonych jako obiekty klasy użytkownika, nie zaleca się modyfikowanie domyślnej definicji klasy użytkownika (User). Zamiast tego powinniśmy zdefiniować klasę pomocniczą o nazwie contosoUser, która w atrybucie mayContain zawiera wartość contosoEmpShoe (jak pokazano na Rysunku 4), a następnie do klasy User dodać atrybuty zdefiniowane dla klasy pomocniczej contosoUser.

Rysunek 4: Definiowanie klasy contosoUser.

Po przeprowadzeniu analizy i zdefiniowaniu wartości, nadszedł czas na stworzenie pliku .ldif, którego zawartość wyglądać będzie jak kod z Rysunku 5 . Możemy skopiować zawartość Rysunku 5 do Notatnika i zapisać plik jako contosoUser.ldif (możemy również znaleźć kopię w kodzie pobranym ze strony technetmagazine.com).

#Definicja atrybutu contosoEmpShoe



dn: CN=contosoEmpShoe,CN=Schema,CN=Configuration,DC=X

changetype: ntdsschemaadd

objectClass: top

objectClass: attributeSchema

cn: contosoEmpShoe

attributeID: 1.2.840.113556.1.8000.9999.2.1

attributeSyntax: 2.5.5.12

isSingleValued: TRUE

adminDisplayName: contosoEmpShoe

adminDescription: contosoEmpShoe

oMSyntax: 64

searchFlags: 1

lDAPDisplayName: contosoEmpShoe

systemOnly: FALSE



dn:

changetype: modify

add: schemaUpdateNow

schemaUpdateNow: 1

-



# Klasy



dn: CN=contosoUser,CN=Schema,CN=Configuration,DC=X

changetype: ntdsschemaadd

objectClass: top

objectClass: classSchema

cn: contosoUser

governsID: 1.2.840.113556.1.8000.9999.1.1

mayContain: contosoEmpShoe

rDNAttID: cn

adminDisplayName: contosoUser

adminDescription: contosoUser

objectClassCategory: 3

lDAPDisplayName: contosoUser

name: contosoUser

systemOnly: FALSE



dn:

changetype: modify

add: schemaUpdateNow

schemaUpdateNow: 1

-



dn: CN=User,CN=Schema,CN=Configuration,DC=X

changetype: ntdsschemamodify

add: auxiliaryClass

auxiliaryClass: contosoUser

-



dn:

changetype: modify

add: schemaUpdateNow

schemaUpdateNow: 1

Rysunek 5: Plik .ldif służący do rozszerzania schematu.

Po wygenerowaniu pliku .ldif powinniśmy dokładnie przetestować implementację w środowisku laboratoryjnym, sprawdzić replikację typu „end-to-end” domeny i lasu oraz włączyć aktualizację schematu w lesie. Na tym etapie powinniśmy być zalogowani przy użyciu konta, które posiada uprawnienia Administratora schematu. Być może będziemy chcieli wyłączyć wychodzącą replikację na serwerze wzorca schematu (gdzie dokonywana jest modyfikacja), a następnie uruchomić następujące polecenie w celu zaimportowania pliku .ldif:

ldifde –i –f <Path>\contosoUser.ldif –b

<nazwauzytkownika> <domena> <haslo> -k –j. –c

"CN=schema,CN=Configuration,DC=X"

#schemaNamingContext

Po wprowadzeniu zmian należy włączyć wychodząca replikację na serwerze wzorca schematu i sprawdzić, czy nastąpiła replikacja dla wszystkich kontrolerów domeny.

Teraz możemy już odetchnąć z ulgą - skończyliśmy! Zdefiniowaliśmy w schemacie nowy atrybut, który będzie powiązany z obiektami tworzonymi przy użyciu klasy użytkownika (czyli kontami użytkowników).

Aby sprawdzić modyfikację, możemy otworzyć przystawkę Użytkownicy i Komputery usługi Active Directory (Users and Computers), połączyć się z domeną employees.contoso.com, przejść do jednostki organizacyjnej Użytkownicy (Users) i stworzyć nowe konto użytkownika o nazwie ContosoTestUser. Następnie możemy otworzyć konsolę adsiedit.msc i połączyć się z partycją domeny dc=employees,dc=contoso,dc=com, rozwinąć jednostkę organizacyjną Użytkownicy (Users), prawym przyciskiem myszy kliknąć ContosoTestUser, otworzyć stronę Właściwości (Properties) i odnaleźć atrybut contosoEmpShoe. Możemy edytować ten atrybut, wpisując jego wartość. Możemy również użyć narzędzia Ldp.exe do sprawdzania i modyfikowania atrybutów.

A teraz zajmijmy się przykładem, w którym definiowane i łączone są dwa atrybuty. Wyobraźmy sobie scenariusz, w którym firma Contoso przykłada ogromną wagę do rozmiaru buta swoich pracowników i chce jakoś śledzić roczną wydajność osób, które zajmują się sprawdzaniem rozmiarów buta pracowników w firmie. Choć może to brzmieć dość zabawnie, załóżmy że firma Contoso chce sprawdzać nie tylko, kto był odpowiedzialny za mierzenie rozmiarów buta pracowników, ale również czyje rozmiary pobrał i ile - wszystko to poprzez zbadanie jednego atrybutu. Część czytelników zapewne stwierdzi, że dane te byłoby lepiej przechowywać w tabelach bazodanowych, ale przy pomocy tego przykładu chcemy po prostu wyjaśnić działanie odsyłacza do przodu oraz odsyłacza wstecznego.

Oczywiście na początku należałoby przeprowadzić podobną analizę jak w poprzednim przykładzie. Jednak tym razem przejdziemy od razu do wygenerowania plików .ldif: linkids1.ldif oraz linkids2.ldif, jak pokazano na Rysunku 6 . Następnie uruchomimy poniższe polecenie w celu zaimportowania plików .ldif:

#linkids1.ldif

#Definicja atrybutu dla odsyłacza do przodu



dn: CN=ContosoShoeSizeTaker,CN=Schema,CN=Configuration,DC=X

changetype: ntdsschemaadd

objectClass: top

objectClass: attributeSchema

cn: ContosoShoeSizeTaker

attributeID: 1.2.840.113556.1.8000.9999.2.2

LinkID: 1.2.840.113556.1.2.50

attributeSyntax: 2.5.5.1

isSingleValued: TRUE

adminDisplayName: ContosoShoeSizeTaker

adminDescription: ContosoShoeSizeTaker

oMSyntax: 64

searchFlags: 1

lDAPDisplayName: ContosoShoeSizeTaker

systemOnly: FALSE



dn:

changetype: modify

add: schemaUpdateNow

schemaUpdateNow: 1

-



#Reload schema



#linkids2.ldif



#Definicja atrybutu dla odsyłacza wstecznego



dn: CN=ContosoShoeSizesTakenByMe,CN=Schema,CN=Configuration,DC=X

changetype: ntdsschemaadd

objectClass: top

objectClass: attributeSchema

cn: ContosoShoeSizesTakenByMe

attributeID: 1.2.840.113556.1.8000.9999.2.3

LinkID: 1.2.840.113556.8000.9999.2.2

attributeSyntax: 2.5.5.1

isSingleValued: FALSE

adminDisplayName: ContosoShoeSizesTakenByMe

adminDescription: ContosoShoeSizesTakenByMe

oMSyntax: 64

searchFlags: 1

lDAPDisplayName: ContosoShoeSizesTakenByMe

systemOnly: FALSE



dn:

changetype: modify

add: schemaUpdateNow

schemaUpdateNow: 1

-



#Dodanie atrybutów ContosoShoeSizeTaker oraz ContosoShoeSizesTakenByMe

#do atrybutu MayContain w klasie contosoUser 



dn: CN= contosoUser,CN=Schema,CN=Configuration,DC=X

changetype: ntdsschemamodify

add: mayContain

mayContain: ContosoShoeSizeTaker

mayContain: ContosoShoeSizesTakenByMe



dn:

changetype: modify

add: schemaUpdateNow

schemaUpdateNow: 1

-



#Dodanie atrybutu odsyłacza wstecznego w atrybucie MayContain najwyższego poziomu



dn: CN=Top,CN=Schema,CN=Configuration,DC=X

changetype: ntdsschemamodify

add: mayContain

mayContain: ContosoShoeSizesTakenByMe



dn:

changetype: modify

add: schemaUpdateNow

schemaUpdateNow: 1

ldifde –i –f <Path>\linkedids<>.ldif –b

<nazwauzytkownika> <domena> <haslo> -k –j. –c

"CN=schema,CN=Configuration,DC=X"

#schemaNamingContext

Rysunek 6: Pliki .ldif odsyłacza do przodu i odsyłacza wstecznego.

Teraz utworzony obiekt użytkownika zawierać będzie również atrybuty ContosoShoeSizeTaker oraz ContosoShoeSizesTakenByMe. Podczas tworzenia obiektu użytkownika na przykład o imieniu John, atrybut ContosoShoeSizeTaker będzie wypełniany przy użyciu nazwy wyróżniającej osoby, która dokonała pomiaru rozmiaru buta, czyli np. osoby o imieniu Frank. A zatem gdy przejdziemy do właściwości obiektu użytkownika Frank i zbadamy atrybut ContosoShoeSizesTakenByMe, zobaczymy wynik zawierający nazwę wyróżniającą Johna oraz wielu innych osób mierzonych przez Franka. Na zakończenie tego scenariusza zarząd może nagrodzić Franka bazując na liczbie nazw wyróżniających, jakie znajdują się w atrybucie ContosoShoeSizesTakenByMe jego konta użytkownika.

 Do początku strony

Sprawdzanie i analiza systemu

Krytyczne aktualizacje, takie jak modyfikacja schematu, nie mogą być dokonywane bez przeanalizowania ich pod kątem wymagań architekturalnych. Usługa Active Directory wykorzystuje kontrole spójności oraz zabezpieczeń do sprawdzenia, czy modyfikacje nie spowodują niespójności lub innych problemów, za każdym razem gdy przeprowadzane są operacje dodawania lub modyfikacji schematu usługi Active Directory.

Po pierwsze wartość atrybutu governsID dla każdej klasy musi być unikatowa w ramach schematu. W przypadku definiowania obiektu schemaClass muszą istnieć wszystkie atrybuty definiowane na listach systemMayContain, mayContain, systemMustContain oraz mustContain. Ponadto muszą istnieć wszystkie klasy zdefiniowane na listach subClassOf, systemAuxiliaryClass, auxiliaryClass, systemPossSuperiors oraz possSuperiors.

Ponadto kategorią objectClassCategory wszystkich klas zdefiniowanych na listach systemAuxiliaryClass oraz auxiliaryClass musi być klasa 88 lub klasa pomocnicza (Auxiliary). Natomiast kategorią objectClassCategory wszystkich klas zdefiniowanych na listach systemPossSuperiors oraz possSuperiors musi być klasa 88 lub klasa strukturalną (Structural).

Definiując różne klasy, warto pamiętać, że klasy abstrakcyjne mogą dziedziczyć jedynie z klas abstrakcyjnych, klasy pomocnicze nie mogą dziedziczyć z klas strukturalnych, a klasy strukturalne nie mogą dziedziczyć z klas pomocniczych. Ponadto atrybut określony w atrybucie rDNAttID musi posiadać składnię łańcucha znaków Unicode i musi być jednowartościowy.

Są to reguły dotyczące obiektów classSchema. A co z regułami dla obiektów attributeSchema? Jak w przypadku wartości governsID dla klas, wartość atrybutu attributeID musi być unikatowa. Ponadto wartość mAPIID, o ile istnieje, również musi być unikatowa. Co więcej, jeśli istnieją atrybuty zakresu niższego rangeLower oraz zakresu wyższego rangeUpper, rangeLower musi mieć mniejszą wartość niż rangeUpper. Wartości attributeSyntax oraz oMSyntax muszą do siebie pasować. Jeśli atrybut zawiera składnię obiektu (oMSyntax =127), musi posiadać odpowiednią wartość oMObjectClass. Atrybut linkID, o ile istnieje, musi być unikatowy. Poza tym odsyłacz wsteczny musi posiadać odpowiadający mu odsyłacz do przodu.

 Do początku strony

A co jeśli popełnimy błąd?

Po rozszerzeniu schematu nowych obiektów (klas oraz atrybutów) nie można już usunąć. Jednak można dezaktywować klasę lub atrybut, ustawiając w atrybucie isDefunct obiektu schematu wartość TRUE. Nie można dezaktywować obiektów schematu, które są częścią domyślnego schematu dostarczanego wraz z usługą Active Directory (obiektów kategorii 1). Można jedynie dezaktywować obiekty, które zostały dodane do domyślnego schematu. To oznacza, że możemy wyłączać jedynie obiekty kategorii 2 i to tylko wtedy, gdy usługa Active Directory stwierdzi, że klasa nie jest wykorzystywana na liście subClassOf, auxiliaryClass lub possSuperiors żadnej z istniejących, niezlikwidowanych klas.

Podczas każdej próby skonfigurowania atrybutu jako zlikwidowanego, usługa Active Directory sprawdza, czy atrybut nie jest wykorzystywany na listach mustContain lub mayContain istniejącej, niezlikwidowanej klasy. Wyłączone obiekty można przywrócić do życia, ustawiając w atrybucie isDefunct wartość FALSE. Jeśli usługa Active Directory działa w systemie Windows Server 2003, wartości ldapDisplayName, schemaIdGuid, OID oraz mapiID wyłaczonego obiektu można wykorzystywać ponownie.

 Do początku strony

Podsumowanie

Dodawanie lub modyfikowanie definicji klas bądź atrybutów w schemacie wiąże się z dodawaniem lub modyfikowaniem odpowiedniego obiektu classSchema lub attributeSchema. Proces ten przypomina dodawanie lub modyfikowanie dowolnego obiektu w katalogu Active Directory, z tą różnicą, że przeprowadzane są dodatkowe kontrole sprawdzające, czy modyfikacje nie spowodują w przyszłości niespójności lub problemów w schemacie.

Choć modyfikowanie schematu usługi Active Directory jest proste, do właściwego zaimplementowania zmian potrzebna jest znajomość budowy schematu i sposobu jego funkcjonowania. Każda zmiana produkcyjnego schematu usługi Active Directory wymaga dużo planowania i musi być realizowana z rozwagą. Konieczne jest zdefiniowanie wymagań biznesowych oraz specyfikacji technicznych dla nowych obiektów oraz przeprowadzenie wnikliwych testów w warunkach laboratoryjnych. Ponieważ zmiany mogą mieć poważne konsekwencje, zaleca się rozszerzanie schematu usługi Active Directory tylko wtedy, gdy jest to absolutnie niezbędne.

O autorze

Vikas Malhotra jest konsultantem w Microsoft Consulting Services w Nowym Jorku. Podczas dwunastu lat spędzonych w tej branży miał okazję pracować w wielu organizacjach IT w dużych i średnich firmach, realizując wymagania dotyczące architektury infrastrukturalnej, takie jak katalogi, obsługa poczty, bezpieczeństwo i sieć przesyłu danych. Posiada tytuły naukowe Bachelor of Engineering in Electronics and Telecommunications oraz Master of Science in Telecom (Tech) Management. Można skontaktować się z nim, korzystając z adresu vikasmal@microsoft.com.

Do początku strony