Rozdziaú 5

Publikacja us│ug w Active Directory

     Active Directory jako us│uga katalogowa w│╣czona do systemu Windows 2000 Server jest zaprojektowana do przechowywania rozproszonych w sieci informacji o komputerach, u┐ytkownikach, us│ugach i aplikacjach. Us│ugi i aplikacje bazuj╣ce na katalogu publikuj╣ globalne informacje w Active Directory, do kt≤rych zalicza siΩ na przyk│ad dostΩpno£µ i w│a£ciwo£ci us│ugi. Interfejsy u┐ytkownika i zarz╣dzania katalogiem Active Directory umo┐liwiaj╣ administratorom i procesom klienta odnaleƒµ potrzebne us│ugi bazuj╣ce na katalogu.
     Osoba odpowiedzialna za udostΩpnianie zasob≤w w obszarze ca│ej sieci musi znaµ pojΩcia i procedury zwi╣zane z publikowaniem us│ug w Active Directory. Znajomo£µ architektury publikacji us│ug Active Directory i publikacji podstawowych us│ug udostΩpnianych przez Active Directory jest niezbΩdna do zrozumienia technologii zwi╣zanych z tym zagadnieniem, w celu wykorzystania tej wiedzy do zarz╣dzania us│ugami w sieci rozproszonej.
Zawarto£µ rozdzia│u
      WstΩp do publikacji us│ug
      Infrastruktura publikowania us│ug w katalogu
      Odnajdywanie i przegl╣danie informacji o us│udze w Active Directory
      Us│uga nazw RPC systemu Windows 2000 i integracja z Active Directory
      Aspekty zabezpiecze± us│ug
      Dodatkowe ƒr≤d│a informacji

WstΩp do publikacji us│ug

     Us│uga jest procesem serwera wykonuj╣cym okre£lone funkcje systemowe i nierzadko udostΩpniaj╣cym interfejs programowania aplikacji (API), z kt≤rego korzystaj╣ inne procesy. Proces serwera dostarcza co najmniej jeden w╣tek do obs│ugi ┐╣da± proces≤w klienta i implementuje zestaw us│ug, kt≤re udostΩpnia uruchomionym na co najmniej jednym komputerze w sieci rozproszonej klientom. Us│ugi systemu Windows 2000 mog╣, ale nie musz╣ korzystaµ ze zdalnego wywo│ywania procedur (RPC), co oznacza, ┐e ich funkcje API mog╣ byµ wywo│ywane przez komputery zdalne.
     Publikacja us│ug stanowi tworzenie, przechowywanie i utrzymywane informacji w miejscu przechowywania danych Active Directory. Klienci i administratorzy sieci mog╣ u┐yµ tych informacji do odnalezienia, pod│╣czenia i zarz╣dzania us│ug╣. Ponadto Active Directory daje klientom i administratorom mo┐liwo£µ przegl╣dania sieci rozproszonej raczej jako kolekcji us│ug ni┐ zbioru indywidualnych komputer≤w.

Typy informacji o us│udze

     Katalog Active Directory mo┐e przechowywaµ informacje zawieraj╣ce dane, kt≤re opisuj╣ metody tworzenia wyst╣pie± us│ug i powi╣za± klient≤w. Kluczow╣ czΩ£ci╣ tych danych jest informacja o powi╣zaniach, kt≤ra zawiera po│╣czenia lub powi╣zania klienta z dostΩpn╣ w sieci us│ug╣. Informacje o powi╣zaniach obejmuj╣ szeroki zakres mo┐liwych typ≤w danych.
     Us│ugi bazuj╣ce na katalogu mog╣ przechowywaµ w Active Directory jeden z typ≤w informacji przedstawionych w tabeli 5.1.

Tabela 5.1 Typy informacji przechowywanych przez us│ugi bazuj╣ce na katalogu
Informacja o us│udze Opis w Active Directory
powi╣zania klienta Nazwa us│ugi i metoda po│╣czenia zastosowana przez klient≤w w celu uzyskania dostΩpu do us│ugi.
powi╣zania administracyjne Nazwa us│ugi i metoda po│╣czenia z us│ug╣, zastosowana przez programy administracyjne w celu wykonania operacji administracyjnej. Pojedyncze powi╣zanie mo┐e byµ u┐yte zar≤wno przez klienta, jak i funkcje administracyjne.
dane konfiguracji Dane sta│ej konfiguracji us│ugi mog╣ byµ przechowywane w katalogu, w celu wykorzystania mo┐liwo£ci kontroli zabezpiecze± i replikacji danych Active Directory. Na przyk│ad, us│uga bazy danych mo┐e przechowywaµ w Active Directory w│asn╣ konfiguracjΩ domy£ln╣ dla serwer≤w baz danych. Po zainstalowaniu nowego wyst╣pienia us│ugi bazy danych, mo┐na dynamicznie uzyskaµ dostΩp do informacji o konfiguracji w celu uproszczenia procesu instalacji i zapewniania sp≤jno£ci danych konfiguracyjnych.
inne dane us│ugi Rozszerzenia schematu Active Directory i obiekt≤w klas zwi╣zane z us│ug╣, stanowi╣ce u┐yteczne informacje administracyjne i dla klienta.

Obiekty us│ug      Obiekt jest odrΩbnym, okre£lonym nazw╣ zbiorem atrybut≤w reprezentuj╣cym na przyk│ad u┐ytkownika, drukarkΩ czy aplikacjΩ serwera. Obiekty Active Directory reprezentuj╣ elementy stanowi╣ce najczΩ£ciej wykorzystywane us│ugi katalogu znajduj╣ce siΩ w £rodowisku sieciowym. Active Directory ustala parametry nastΩpuj╣cych typ≤w obiekt≤w: u┐ytkownik, grupa, kontener us│ugi katalogowej, zarz╣dzanie wydrukiem, schemat i zarz╣dzanie us│ug╣.
     W przypadku system≤w Windows NT w wersji 4.0 i wcze£niejszych, procesy klienta oraz programy administracyjne wymagaj╣ nazwy lub adresu IP (Internet Protocol) komputera, na kt≤rym udostΩpniona jest us│uga. Nazwa lub adres jest potrzebny do odnalezienia, a nastΩpnie pod│╣czenia do us│ugi. W przeciwie±stwie do tego, Active Directory umo┐liwia procesom klienta i programom administracyjnym nawi╣zaµ po│╣czenie z us│ug╣ u┐ywaj╣c atrybut≤w s│≤w kluczowych, co daje klientom mo┐liwo£µ odszukania host≤w DNS.
     WiΩcej informacji o s│owach kluczowych znajduje siΩ w paragrafie äOdnajdywanie i przegl╣danie informacji o us│udze w Active Directoryö poni┐ej w tym rozdziale. WiΩcej informacji o nazwach host≤w DNS us│ug znajduje siΩ w rozdziale äRozwi╣zywanie nazw Active Directoryö w niniejszym tomie Microsoft Windows 2000 Server Resource Kit.
     Active Directory pozwala, za pomoc╣ atrybut≤w innych ni┐ nazwa czy adres IP komputera, odnaleƒµ i pod│╣czyµ do zainstalowanej na tym komputerze us│ugi bazuj╣cej na katalogu. Korzystaj╣c z innych atrybut≤w, takich jak wy£wietlana nazwa us│ugi jako nazwa przyjazna, Active Directory odnajduje us│ugi takie jak DHCP (Dynamic Host Configuration Protocol). Struktura bazy danych Active Directory i obiekty okre£lonych us│ug s╣ bardziej szczeg≤│owo opisane w paragrafie äInfrastruktura publikowania us│ug w kataloguö poni┐ej w tym rozdziale.

Powi╣zania us│ugi

     W celu opublikowania w Active Directory us│ugi bazuj╣cej na katalogu, us│uga ta w ramach minimalnych wymaga± musi przechowywaµ informacje o powi╣zaniach. Powi╣zania us│ugi stanowi╣ informacje o po│╣czeniu lub powi╣zaniu klienta z wyst╣pieniem danej us│ugi. Informacje wymagane do powi╣zania us│ugi obejmuj╣ nazwΩ us│ugi i jej lokalizacjΩ. Na przyk│ad przegl╣darka WWW okre£la powi╣zanie z serwerem WWW za pomoc╣ URL.
     W tabeli 5.2 wyliczono przyk│ady powi╣za± us│ugi.      
Tabela 5.2 Przyk│ady powi╣za± us│ugi
Us│ugaPowi╣zanie
Us│uga plik≤w îcie┐ka udostΩpnienia w Uniwersalnej konwencji nazewniczej (Universal Naming Convention - UNC).
Przyk│ad: \\M≤jSerwer\MojaNazwaUdzia│u
Us│uga WWW URL
Przyk│ad: http://www.reskit.com
Us│uga RPC Powi╣zanie RPC, czyli zakodowana informacja u┐ywana do po│╣cze± z serwerem RPC. Powi╣zania RPC mo┐na konwertowaµ z ci╣g≤w tekstowych za pomoc╣ funkcji API RPC.
Przyk│ad: ncacn_ip_tcp:server.microsoft.com

Wyst╣pienie us│ugi

     Okre£lona us│uga mo┐e siΩ opublikowaµ w Active Directory wiΩcej ni┐ jeden raz. Ka┐de wyst╣pienie us│ugi dzia│aj╣ce na komputerze lub komputerach w sieci mo┐e utworzyµ w Active Directory obiekt punktu po│╣czenia, kt≤ry reprezentuje jedno lub wiΩcej wyst╣pie± us│ugi dostΩpnych w tej sieci.
     Je┐eli na przyk│ad Us│uga certyfikat≤w dla systemu Windows 2000 jest zainstalowana i dzia│a na dw≤ch komputerach w sieci, to mog╣ istnieµ dwa obiekty punktu po│╣czenia û ka┐da dla osobnego wyst╣pienia na jednym z komputer≤w. Podobnie ma siΩ rzecz w przypadku wielu wyst╣pie± us│ugi zainstalowanych na jednym komputerze, gdzie mog╣ byµ utworzone oddzielne obiekty punktu po│╣czenia dla ka┐dego z tych wyst╣pie±. Mo┐liwa jest r≤wnie┐ publikacja w Active Directory wielu wyst╣pie± replikowanej us│ugi przy u┐yciu pojedynczego punktu po│╣czenia. W tym przypadku punkt po│╣czenia zawiera informacje umo┐liwiaj╣ce klientowi okre£liµ powi╣zanie z wybran╣ replik╣.
Uwaga Atrybuty possSuperiors i systemPossSuperiors ka┐dej klasy obiektu w Active Directory zawieraj╣ listy klas, kt≤re mog╣ zawieraµ wyst╣pienia obiektu, tzn. typy kontener≤w, w kt≤rych mo┐na utworzyµ obiekt. Po utworzeniu klasy jej atrybut systemPossSuperiors nie mo┐e byµ modyfikowany, a w przypadku obiekt≤w classSchema, warto£ci mog╣ byµ dodane do atrybutu possSuperiors, ale nie mo┐na ich ju┐ usun╣µ. Mo┐na na przyk│ad utworzyµ wyst╣pienie klasy obiektu serviceConnectionPoints jako obiektu podrzΩdnego w stosunku obiektu komputera, kontenera lub jednostki organizacji. WiΩcej informacji o atrybutach possSuperiors i systemPossSuperiors znajduje siΩ w rozdziale äSchemat Active Directoryö w niniejszym tomie Microsoft Windows 2000 Server Resource Kit.

Infrastruktura publikowania us│ug w katalogu

     Obiekty w Active Directory s╣ uporz╣dkowane w strukturze hierarchicznej, a wstΩpnie skonfigurowana hierarchia, zak│adana wraz z katalogiem Active Directory, zawiera informacje wymagane przy instalacji i uruchomieniu systemu Windows 2000 oraz samej us│ugi katalogowej. Domy£lna struktura obejmuje kontenery specjalnie przeznaczone do publikowania us│ug.
     Na rysunku 5.1 przedstawiono domy£ln╣ strukturΩ hierarchiczn╣ Active Directory.


Rysunek 5.1 Domy£lna struktura hierarchiczna przeznaczona do publikacji us│ug

     Hierarchia domeny przechowuje wszystkie obiekty (na przyk│ad u┐ytkownicy, komputery i drukarki) zwi╣zane z okre£lona domen╣ i jest replikowana do wszystkich kontroler≤w tej domeny. Hierarchia konfiguracji przechowuje wszystkie obiekty zwi╣zane z ca│╣ struktur╣ lasu domen i jest replikowana do ka┐dego kontrolera domeny w tej strukturze lasu. Kontenery Us│ugi (Services) i Lokacje (Sites) s╣ bezpo£rednio podrzΩdne w stosunku do partycji katalogu konfiguracji.

Punkty po│╣cze±

     Obiekt Connection Point (Punkt po│╣czenia) reprezentuje jedno lub wiΩcej wyst╣pie± us│ugi dostΩpnej w sieci. Schemat Active Directory definiuje r≤┐ne klasy obiekt≤w przeznaczonych do publikacji us│ugi. Wszystkie obiekty reprezentuj╣ce zasoby przyjmuj╣ce po│╣czenia wywodz╣ siΩ z klasy obiektu Connection Point.
     Na rysunku 5.2 przedstawiono hierarchiΩ klasy Connection Point.


Rysunek 5.2 Hierarchia klasy Connection Point

     CzΩ£µ przyk│adowych obiekt≤w wywodzi siΩ z klasy Connection Point i przyjmuje nastΩpuj╣ce po│╣czenia:
     Kolejka wydruku i Wolumen Obiekty Print Queue (Kolejka wydruku) i Volume (Wolumen) s╣ standardowymi punktami po│╣czenia u┐ywanymi odpowiednio przez drukarkΩ i us│ugΩ plik≤w.
     Punkty wej£cia RPC System Windows 2000 obs│uguje dwa zestawy sieciowych funkcji API posiadaj╣cych niezale┐ne mechanizmy transportowe: interfejs Microsoft Windows Sockets i interfejs RPC. RPC dostarcza mechanizm do wywo│ywania funkcji w innych procesach, nawet tych dzia│aj╣cych na zdalnych komputerach w sieci, zapewnia model podzia│u na w╣tki, udostΩpnia us│ugΩ mapowania punkt≤w docelowych (gniazdo/potok/port) oraz pod│╣czenia do us│ugi nazw. Us│ugi aktualnie og│aszaj╣ce siΩ z wykorzystaniem funkcji API Us│ugi nazw RPC (RpcNs) s╣ publikowane w Active Directory za pomoc╣ obiektu RPC-Entry i innych klas obiekt≤w RPC.
     Wyst╣pienie us│ugi Us│ugi Windows og│aszaj╣ce siΩ z wykorzystaniem funkcji API rejestracji i rozwi╣zywania (RnR) s╣ publikowane w Active Directory za pomoc╣ obiektu klasy Service-Instance.
     Punkt po│╣czenia z us│ug╣ Do jawnego opublikowania siΩ w Active Directory, us│ugi u┐ywaj╣ raczej Punktu po│╣czenia z us│ug╣ (Service Connection Point), ni┐ istniej╣cych warstw abstrakcji, takich jak Us│uga nazw RPC czy RnR.
     Aby ukryµ przed aplikacj╣ klienta szczeg≤│y lokalizacji us│ugi, us│uga ta korzystaj╣c z obiektu Service-Connection-Point tworzy warstwΩ abstrakcji, kt≤ra mo┐e byµ zaimplementowana jako dynamicznie do│╣czona biblioteka (DLL) lub jako czΩ£µ aplikacji klienta. Zadaniem warstwy abstrakcji jest badanie Active Directory w celu okre£lenia przez aplikacjΩ klienta obiektu punktu po│╣czenia reprezentuj╣cego us│ugΩ oraz uzyskanie informacji tego obiektu o powi╣zaniach, w celu pod│╣czenia aplikacji do us│ugi.
     Aplikacja klienta pyta Active Directory o obiekty punktu po│╣czenia, kt≤re reprezentuj╣ ┐╣dane us│ugi. NastΩpnie klient wybiera jeden z tych obiekt≤w i korzysta z informacji tego obiektu o po│╣czeniach w celu pod│╣czenia tego obiektu do us│ugi. W przypadku interfejs≤w RpcNs i RnR, zapytanie wykonuje warstwa abstrakcyjna, natomiast w przypadku klasy serviceConnectionPoints, zapytanie wykonuje bezpo£rednio klient.
Uwaga Us│ugi oparte o model COM nie u┐ywaj╣ do og│aszania siΩ obiekt≤w Connection Point, s╣ bowiem publikowane w magazynie klas. Magazyn klas systemu Windows 2000 stanowi repozytorium bazuj╣ce na katalogu dla wszystkich aplikacji, interfejs≤w i funkcji API, kt≤re umo┐liwiaj╣ publikowanie i przypisywanie aplikacji.
     WiΩcej informacji o us│ugach bazuj╣cych na modelu COM i o Windows 2000 Class Store znajduje siΩ w odno£niku MSDN na stronie Web Resources pod adresem: http://windows.microsoft.com/widows2000/reskit/webresources.

Miejsce publikacji

     Aby poznaµ miejsce publikacji us│ug w Active Directory, nale┐y najpierw zapoznaµ siΩ i przestrzegaµ nastΩpuj╣cych wskaz≤wek:      Je┐eli klient posiada dostΩp do komputera z uruchomion╣ us│ug╣, powinien posiadaµ dostΩp do repliki domeny zawieraj╣cej komputer.
Uwaga Klient mo┐e rzadko identyfikowaµ komputer, na kt≤rym dzia│a us│uga. Normalnie znajduje us│ugΩ na podstawie atrybutu s│owa kluczowego, kt≤ry mo┐e zawieraµ identyfikator GUID okre£lony dla producenta i aplikacji. Us│uga publikuj╣ca informacje musi opublikowaµ atrybut s│≤w kluczowych. WiΩcej informacji o atrybucie s│≤w kluczowych znajduje siΩ w odno£niku Microsoft Platform SDK na stronie Web Resources pod adresem http://windows.microsoft.com/widows2000/reskit/webresources.
     Wystarczy zatem, aby us│uga opublikowa│a informacje w domenie zawieraj╣cej komputer, na kt≤rym dzia│a. Publikowanie informacji o us│udze w hierarchii konfiguracji nie powoduje, ┐e jest bardziej dostΩpna lub dostΩp do niej jest │atwiejszy. Powoduje jednak┐e dodatkowy ruch w procesie replikacji, wiΩc aby zwiΩkszyµ wydajno£µ, nie powinno siΩ publikowaµ tych informacji w partycji konfiguracji.
     Klienci badaj╣c katalog odnajduj╣ obiekty us│ug. Klient mo┐e wysy│aµ zapytanie ograniczaj╣ce siΩ do swojej domeny lub korzystaj╣c z Katalogu globalnego mo┐e przeszukaµ ca│╣ strukturΩ lasu. W obu przypadkach okre£lona lokalizacja us│ugi jest r≤┐na od lokalizacji klienta. Dlatego te┐ klient nie ma wp│ywu na lokalizacjΩ, w kt≤rej obiekty us│ug s╣ opublikowane. Zamiast tego, kluczowe znaczenie polega na │atwo£ci, z jak╣ mo┐na administrowaµ us│ug╣.
     W hierarchii domeny Active Directory obiekty zwi╣zane z us│ug╣ wystΩpuj╣ w trzech miejscach, kt≤rymi s╣ nastΩpuj╣ce kontenery:
Uwaga Dowolny obiekt w Active Directory (i wielu innych us│ugach katalogowych) mo┐e byµ obiektem nadrzΩdnym przez zdefiniowanie go jako kontener, co tworzy bardziej naturaln╣ strukturΩ katalogu. Na przyk│ad obiekty zwi╣zane dok│adnie z jednym komputerem powinny znajdowaµ siΩ w katalogu jako obiekty podrzΩdne tego komputera, na kt≤rym administrator spodziewa siΩ je odnaleƒµ.

Obiekt komputera

     Publikuj╣c us│ugi dla komputera nale┐y utworzyµ obiekt zwi╣zany z us│ug╣ jako obiekt podrzΩdny obiektu komputera (Computer), gdzie us│uga ta jest zainstalowana.
     Wiele us│ug aby upro£ciµ instalacjΩ, korzysta z domy£lnej lokalizacji, w kt≤rej tworzy obiekty, ale wiΩkszo£µ us│ug jednocze£nie pozwala przenosiµ te obiekty po utworzeniu. Obiekt komputera, na kt≤rym zainstalowano us│ugΩ, jest odpowiedni╣ i naturaln╣ lokalizacj╣ dla tych obiekt≤w, poniewa┐ przenosz╣c ten obiekt w inne miejsce Active Directory przenosi tam tak┐e obiekty us│ug. Poza tym, gdy obiekt komputera jest usuwany lub przy│╣czany do innej domeny, obiekty us│ug s╣ usuwane. DziΩki temu istnieje mniejsze prawdopodobie±stwo wystΩpowania obiekt≤w osieroconych. Proces uruchomiony na komputerze nale┐╣cym do domeny zawsze mo┐e znaleƒµ obiekt komputera w katalogu.
Uwaga W│asne obiekty Computer w katalogu posiadaj╣ wy│╣cznie komputery nale┐╣ce do domeny.

Hierarchia kontener≤w jednostek organizacji

     Active Directory pozwala tworzyµ hierarchiΩ kontener≤w spe│niaj╣cych potrzeby organizacji. Klas╣ obiektu tworz╣c╣ tego typu hierarchie jest organizationalUnit. Obiekty tej klasy stanowi╣ kontenery og≤lnego przeznaczenia, u┐ywane w celach administracyjnych do grupowania wiΩkszo£ci klas obiekt≤w, w tym r≤wnie┐ obiekt≤w komputer≤w. Mo┐na r≤wnie┐ w celach administracyjnych zgrupowaµ obiekty okre£lonych us│ug. Active Directory umo┐liwia nadawanie uprawnie± do wszystkich obiekt≤w znajduj╣cych siΩ w kontenerze lub poddrzewie za pomoc╣ jednej listy ACL. System Windows 2000 oparty jest o model uprawnie± pozwalaj╣cy zastosowaµ dok│adn╣ kontrolΩ dostΩpu do obiekt≤w katalogu oraz delegowaµ uprawnienia administracyjne na innych u┐ytkownik≤w.
     Wszystkie standardowe klasy obiekt≤w zwi╣zanych z us│ug╣ s╣ obiektami podrzΩdnymi wyst╣pie± klasy organizationalUnit, co oznacza, ┐e us│uga nie wymaga, by obiekt j╣ reprezentuj╣cy znajdowa│ siΩ w sta│ej lokalizacji katalogu.
     Przyk│adowy kod, kt≤ry tworzy obiekt us│ugi, przechowuje atrybut objectGUID i lokalizuje obiekt us│ugi, znajduje siΩ w odno£niku MSDN na stronie Web Resources pod adresem http://windows.microsoft.com/widows2000/reskit/webresources.

Kontenery U┐ytkownicy (Users) i Komputery (Computers)

     Podczas uaktualniania systemu Windows NT do Windows 2000, proces aktualizacji umieszcza konta u┐ytkownik≤w, grup i komputer≤w w kontenerach przeznaczonych do przechowywania u┐ytkownik≤w i komputer≤w. Kontener U┐ytkownicy (Users) przechowuje obiekty u┐ytkownik≤w i grup, natomiast obiekty komputer≤w umieszczane s╣ w kontenerze Komputery (Computers). System Windows NT oraz funkcje API (na przyk│ad interfejsu sieciowego Net API) tworz╣c konta u┐ytkownik≤w, grup i komputer≤w korzystaj╣ z narzΩdzi, kt≤re automatycznie tworz╣ odpowiednie obiekty w tych kontenerach.
     Nie wolno przenosiµ obiekt≤w us│ug bezpo£rednio do tych kontener≤w ani tworzyµ nowych kontener≤w w tych kontenerach. Us│ugi mog╣ publikowaµ obiekty podrzΩdne obiektu komputera, bez wzglΩdu na to, czy obiekt komputera jest przechowywany w kontenerze Komputery (Computers). Nale┐y tworzyµ punkty po│╣czenia pod obiektem komputera, na kt≤rym zainstalowana jest us│uga.

Kontener System

     Kontener System przechowuje informacje operacyjne zorganizowane przez domenΩ. Informacje te obejmuj╣ domy£lny zbi≤r zasad bezpiecze±stwa, dane mechanizmu £ledzenia plik≤w, konferencje sieciowe, a tak┐e kontenery dla punkt≤w po│╣cze± RPC i Windows Sockets (Winsock). Kontener System domy£lnie jest ukryty i stanowi odpowiednie miejsce przechowywania obiekt≤w, kt≤rymi zainteresowany jest administrator, a nie u┐ytkownicy.
     Us│ugi og│aszaj╣ce siΩ za pomoc╣ funkcji API Winsock Rnr i RpcNs automatycznie tworz╣ odpowiednie obiekty w kontenerach Us│ugi Winsock (WinsockServices) i Us│ugi RPC (RpcServices). Nie wolno bezpo£rednio tworzyµ lub przenosiµ obiekt≤w w tych kontenerach.
     Us│ugi tworz╣ce w kontenerze System obiekty us│ug musz╣ wykonaµ nastΩpuj╣ce operacje:      Gdy dana us│uga, taka jak NetMeeting, jest mocno zwi╣zana z pojedynczym komputerem, us│ugi nale┐y opublikowaµ w kontenerze poni┐ej kontenera System w hierarchii obiekt≤w.

Publikowanie us│ug w Active Directory

     Publikuj╣c us│ugi nale┐y przestrzegaµ nastΩpuj╣cych zasad:      Bez wzglΩdu na wyb≤r metody publikacji, nale┐y w procedurze instalacji oraz w momencie uruchomienia poznaµ i uwzglΩdniµ ograniczenia dostΩpu do katalogu. Funkcje API RpcNs i RnR tworz╣ odpowiednio kontenery Us│ugi RPC (RpcServices) i Us│ugi Winsock (WinsockServices), kt≤re znajduj╣ siΩ w ka┐dej domenie. Obiekty Service-Connection-Point musz╣ byµ utworzone jako obiekty podrzΩdne obiektu komputera, na kt≤rym us│uga jest zainstalowana.
     Utworzenie obiektu dowolnego rodzaju wymaga od procesu tworz╣cego posiadania uprawnie± umo┐liwiaj╣cych tworzenie obiektu podrzΩdnego dla klasy i kontenera, w kt≤rych obiekt bΩdzie umieszczony. UsuniΩcie obiektu wymaga od procesu usuwaj╣cego posiadanie uprawnie± umo┐liwiaj╣cych usuwanie obiektu podrzΩdnego dla klasy i kontenera, w kt≤rych obiekt jest usuwany, lub w og≤le wymaga uprawnie± umo┐liwiaj╣cych usuniΩcie obiektu. Aktualizacja punktu po│╣czenia wymaga od procesu wykonuj╣cego t╣ operacjΩ uprawnie± umo┐liwiaj╣cych modyfikowanie w│a£ciwo£ci aktualizowanego obiektu.
     Konto us│ugi lub komputera, kt≤re podczas instalacji us│ugi tworzy obiekty, mo┐e nie posiadaµ wymienionych uprawnie±, ale instalacjΩ mo┐e przeprowadzaµ administrator lub ka┐dy, kto posiada odpowiednie uprawnienia. Instaluj╣c opublikowan╣ us│ugΩ, nale┐y ustawiµ zabezpieczenie na jakikolwiek punkt po│╣czenia, aby dopu£ciµ do aktualizacji tego obiektu przez us│ugΩ w trakcie jej uruchomiania. Pozwala to us│udze dzia│aµ w kontek£cie minimalnego uprzywilejowania i jednocze£nie nadal m≤c obs│ugiwaµ w│asne punkty po│╣cze±.
     WiΩcej informacji o publikowaniu us│ug znajduje siΩ w odno£niku MSDN na stronie Web Resources pod adresem http://windows.microsoft.com/widows2000/reskit/webresources.
     Klasa Punktu po│╣czenia z us│ug╣ (Service Connection Point - SCP) jest podstawow╣ klas╣ obiektu do publikowania i lokalizacji us│ug. Jej przeznaczeniem jest wykorzystanie do publikowania powi╣za± klienta. Zdefiniowane w│a£ciwo£ci tej klasy s╣ wystarczaj╣ce dla us│ugi do opublikowania informacji, kt≤rych klient wymaga do powi╣zania z wyst╣pieniem tej us│ugi. Klienci us│ugi musz╣ posiadaµ wstΩpne informacje o sposobie interpretacji i wykorzystania atrybut≤w powi╣zania, bowiem Active Directory nie definiuje ich u┐ycia. Us│ugi wymagaj╣ce opublikowania dodatkowych informacji o sobie, mog╣ rozszerzyµ klasΩ Service-Connection-Point tworz╣c klasΩ pochodn╣ oraz nadaj╣c tej klasie inn╣ i rozpoznawaln╣ nazwΩ. WiΩcej informacji o rozszerzaniu schematu znajduje siΩ w rozdziale äSchemat Active Directoryö w niniejszym tomie Windows 2000 Server Resource Kit.
     Program instalacyjny (lub opcja instalacyjna procedury wykonywalnej us│ugi) instaluje us│ugΩ i tworzy punkt po│╣czenia z us│ug╣ oraz (je£li to konieczne) tworzy konto us│ugi. Us│uga w trakcie uruchomienia sprawdza, czy punkt po│╣czenia zawiera poprawn╣ informacjΩ o powi╣zaniu.
     W sieci mo┐e istnieµ wiele wyst╣pie± danej us│ugi, a ka┐de wyst╣pienie mo┐e posiadaµ r≤┐ne mo┐liwo£ci. Na przyk│ad r≤┐ne serwery bazy danych mog╣ zawieraµ ca│kowicie r≤┐ne dane, a mimo to wszystkie s╣ us│ug╣ tego samego typu lub tej samej klasy.
     Ponadto us│ugi mog╣ byµ replikowane, a replikowane us│ugi posiadaj╣ kilka wyst╣pie± o identycznych mo┐liwo£ciach. Klient mo┐e po│╣czyµ siΩ z dowoln╣ kopi╣ replikowanej us│ugi i otrzymaµ identyczne us│ugi. Active Directory jest przyk│adem replikowanej us│ugi, dla kt≤rej wszystkie kontrolery danej domeny przechowuj╣ identyczne dane i udostΩpniaj╣ identyczne us│ugi. Tworz╣c punkt po│╣czenia z us│ug╣ nale┐y rozwa┐yµ metodΩ jej lokalizacji przez klient≤w. Posiadaj╣c wiele wyst╣pie± tej us│ugi, nale┐y braµ pod uwagΩ to, jak klienci rozr≤┐ni╣ spo£r≤d wszystkich to wyst╣pienie, kt≤re posiada ┐╣dane mo┐liwo£ci.

Atrybuty serviceConnectionPoint

     Zdefiniowane dla klasy serviceConnectionPoint atrybuty s╣ wystarczaj╣ce do opublikowania przez us│ugΩ informacji, kt≤rych klient wymaga do powi╣zania z wyst╣pieniem tej us│ugi.
     Obiekt klasy serviceConnectionPoint posiada wielowarto£ciowy atrybut s│≤w kluczowych, kt≤ry zawiera │a±cuchy warto£ci û s│owa kluczowe û pozwalaj╣ce aplikacjom klienta odnaleƒµ obiekty punkt≤w po│╣cze± z okre£lonym typem us│ugi. Atrybut ten jest indeksowany i replikowany do serwera Katalogu globalnego. Us│uga publikuj╣ca punkty po│╣cze± wymaga dodania ka┐dego s│owa kluczowego jako indywidualnej czΩ£ci atrybutu wielowarto£ciowego.
     WiΩcej informacji o s│owach kluczowych i publikowaniu punktu po│╣cze± z us│ug╣ znajduje siΩ w odno£niku MSDN na stronie Web Resources pod adresem http://windows.microsoft.com/widows2000/reskit/webresources.

Publikowanie z wykorzystaniem Us│ugi nazw RPC (RpcNs)

     Us│ugi RPC, og│aszaj╣c siΩ w przestrzeni nazewniczej, korzystaj╣ z interfejsu API RpcNs. Funkcje tego interfejsu w systemie Windows 2000 publikuj╣ wej£cia RPC w katalogu Active Directory. Us│ugi tworz╣ powi╣zania RPC i publikuj╣ je w przestrzeni nazewniczej Active Directory okre£laj╣c jako wej£cia serwera RPC z atrybutami, kt≤re obejmuj╣ znany klientom unikalny identyfikator interfejsu oraz identyfikator GUID. DziΩki temu klienci mog╣ przeszukiwaµ serwery RPC, kt≤re oferuj╣ ┐╣dany interfejs, importuj╣ powi╣zanie i │╣cz╣ z serwerem.
     WiΩcej informacji o Us│udze nazw RPC w Active Directory znajduje siΩ w paragrafie äUs│uga nazw RPC systemu Windows 2000 i integracja z Active Directoryö poni┐ej w tym rozdziale.

Publikowanie z wykorzystaniem interfejsu Windows Sockets RnR

     Us│ugi Windows Sockets mog╣ wykorzystaµ funkcje API RnR do publikowania i lokalizowania us│ug. Publikacja RnR sk│ada siΩ z dw≤ch krok≤w. W pierwszym z nich instalowana jest klasa us│ugi, kt≤ra przypisuje identyfikator GUID nazwie us│ugi. Klasa tej us│ugi posiada informacje o konfiguracji us│ugi. Us│ugi mo┐na wiΩc og│aszaµ siΩ jako wyst╣pienia klasy. Po opublikowaniu us│ugi, klienci korzystaj╣c z funkcji API RnR badaj╣ Active Directory w celu uzyskania informacji o wyst╣pieniach danej klasy, a nastΩpnie wybieraj╣ wyst╣pienie, z kt≤rym utworzone bΩdzie powi╣zanie. KlasΩ, kt≤ra nie jest ju┐ wiΩcej potrzebna, mo┐na usun╣µ.

Odnajdywanie i przegl╣danie informacji o us│udze w Active Directory

     Kontener Us│ugi (Services) jest bezpo£rednim obiektem podrzΩdnym kontenera Konfiguracja (Configuration). W przypadku, gdy obiekty zwi╣zane z us│ugami s╣ bezpo£rednimi wyst╣pieniami klasy serviceConnectionPoint, nale┐y lokalizowaµ opublikowane us│ugi przy u┐yciu ADSI wyszukuj╣c dowolny obiekt, kt≤rego atrybut objectCategory i objectClass wskazuje klasΩ serviceConnectionPoint. Atrybuty s│≤w kluczowych zawieraj╣ identyfikatory GUID w│a£ciwe producentowi i aplikacji. Okre£laj╣c kategoriΩ obiektu nale┐y raczej u┐yµ w zapytaniu atrybutu objectCategory ni┐ objectClass.
     W przypadku, gdy obiekty zwi╣zane z us│ugami s╣ wyst╣pieniami klasy wywodz╣cej siΩ z serviceConnectionPoint, wykorzystuj╣c ADSI nale┐y wyszukaµ ka┐dy obiekt, kt≤rego atrybut objectCategory wskazuje klasΩ serviceConnectionPoint lub atrybut objectClass wskazuje klasΩ punktu po│╣czenia z jedn╣ z tych us│ug.
Uwaga Przeszukiwanie wed│ug kategorii obiektu jest metod╣ zalecan╣, poniewa┐ kategorie s╣ indeksowane, co przyspiesza proces wyszukiwania w stosunku do tego, kt≤re wykorzystuje warto£ci nieindeksowane. Warto£ci atrybutu objectClass nie s╣ indeksowane.
     Do okre£lenia powi╣zania, klienci potrzebuj╣ wykorzystaµ informacje przechowywane w atrybucie serviceBindingInformation oraz potencjalnie przechowywane w atrybutach serviceDNSName i serviceDNSNameType.

Us│uga nazw RPC systemu Windows 2000 i integracja z Active Directory

     W celu odnalezienia serwer≤w RPC eksportuj╣cych procedury, procesy klienta wywo│uj╣ funkcje interfejsu API Us│ugi nazw RPC. Serwer RPC dokonuj╣c eksportowania w│asnego interfejsu r≤wnie┐ korzysta z funkcji API RpcNs. Aby po│╣czyµ siΩ z serwerem RPC, klient potrzebuje powi╣zania o ┐╣danym interfejsie i wersji oraz posiadaj╣cego w│a£ciw╣ kolejno£µ protoko│u. Uzyskuje to powi╣zanie wywo│uj╣c funkcjΩ API RpcNs. Us│uga nazw RPC udostΩpnia powi╣zanie wymagane przez klient≤w RPC do stosowania RPC i komunikowania z serwerami RPC.
     Mimo, ┐e same funkcje API RpcNs nie stosuj╣ list kontroli dostΩpu ACL, Active Directory obs│uguje listy ACL i mo┐e je przypisaµ wej£ciom Us│ugi nazw. Implementacja Us│ugi nazw RPC w systemie Windows 2000 korzysta z egzekwowania list ACL przez Active Directory i chroni przed wyst╣pieniem nieupowa┐nionego eksportu interfejsu. Zapewnia r≤wnie┐ klientom mo┐liwo£µ importu opartego o listy ACL.
     Mechanizmy przypisywania list ACL korzystaj╣ z danych typu out-of-band. Dane out-of-band s╣ danymi przesy│anymi poza normalnym przekazywaniem danych miΩdzy procesami. Na przyk│ad gniazda strumieni s╣ bardzo przydatne przy przesy│aniu strumienia bajt≤w z jednego procesu do drugiego. Dane przekazywane t╣ metod╣ s╣ nazywane danymi inline (przetwarzanymi na bie┐╣co). Jednak aplikacje po obu stronach czasem wymagaj╣ komunikacji miΩdzy sob╣ bez przerywania normalnego przekazywania danych inline. Ten rodzaj komunikacji mo┐na uzyskaµ za pomoc╣ danych out-of-band, kt≤re s╣ przesy│ane z wy┐szym priorytetem na to samo gniazdo u┐ywane do transferu danych inline. Zalet╣ tego typu rozwi╣zania jest bezpo£rednie przekazanie danych do odbiorcy bez konieczno£ci oczekiwania na zako±czenie odbieranego strumienia danych. Do niekt≤rych metod konfigurowania list ACL w celu u│atwienia transmisji danych out-of-band przez procesy nale┐╣:
Uwaga Niepowodzenie weryfikacji ACL wyszukiwa± Serwera nazw RPC jest interpretowane jakby wej£cie w og≤le nie istnia│o.

Proces us│ugi nazw RPC systemu Windows 2000

     Wszystkie wej£cia wystΩpuj╣ jako obiekty Active Directory. W ka┐dej domenie Windows 2000 wystΩpuje kontener, kt≤ry jest obiektem g│≤wnym Us│ugi nazw RPC. Nazwa lokalizacyjna tego obiektu jest nastΩpuj╣ca:
     CN=RpcServices,CN=System,CN=Configuration,DC=nazwa domeny
     Na rysunku 5.3 przedstawiono rolΩ, jak╣ pe│ni Us│uga nazw systemu Windows 2000 dla serwera, klienta i Active Directory.


Rysunek 5.3 Us│uga nazw RPC systemu Windows 2000

Opcja rozg│oszenia

     Procedura lokalizacji RPC systemu Windows 2000 sprawdza wej£cie w Active Directory, je£li nie znajduje siΩ w buforze pamiΩci podrΩcznej.
     W przypadku, gdy wyszukiwanie nie powiedzie siΩ, Procedura lokalizacji RPC pos│uguje siΩ metod╣ rozg│oszenia stosowan╣ w systemie Windows NT 4.0, powiadamiaj╣c wszystkie wΩz│y w sieci o swoim istnieniu. Rozg│aszanie jest wa┐ne r≤wnie┐ dla zapewnienia wsp≤│dzia│ania system≤w Windows 2000 z Windows NT 4.0, poniewa┐ komputery z systemem Windows NT 4.0 nie wsp≤│pracuj╣ z Active Directory i dlatego mo┐na je zlokalizowaµ metod╣ rozg│oszenia. Je┐eli na serwerze eksportuj╣cym dzia│a system Windows 2000, a kontroler domeny z kt≤rym siΩ komunikuje jest oparty na systemie Windows NT 4.0, to eksport interfejsu nie bazuje na Active Directory.
     Metoda rozg│oszenia jest zatem konieczna. Natomiast w £rodowisku trybu rodzimego systemu Windows 2000, w kt≤rym dzia│aj╣ tylko kontrolery oparte o ten system, wysy│anie rozg│osze± przy ka┐dej nieudanej pr≤bie nie jest zalecane i nale┐y wy│╣czyµ t╣ metodΩ.
     Ustawienie warto£ci BitFlags r≤wnej 1 w atrybucie NameServiceFlags kontenera Us│ugi RPC (RpcServices) pozwala Procedurze lokalizacji RPC dzia│aµ w domenie zgodnie z systemem Windows NT 4.0. Metoda rozg│oszenia domy£lnie jest w│╣czona.
Uwaga Komputery dzia│aj╣ce w oparciu o system Windows 2000 nie inicjuj╣ wyszukiwania rozg│aszaj╣cego, je£li Procedura lokalizacji Active Directory jest uaktywniona a metoda rozg│oszenia jest wy│╣czona.

Konfiguracja po stronie klienta

     W przypadku komputer≤w z systemem Windows NT w wersji 3.51 lub p≤ƒniejszej, wyszukiwania Us│ugi nazw RPC musz╣ byµ skonfigurowane. W systemie Windows 2000 nale┐y u┐yµ konsoli snap-in U┐ytkownicy i komputery Active Directory, aby skonfigurowaµ wyszukiwania Us│ugi nazw RPC. Dla uzyskania wstecznej zgodno£ci z systemem Windows NT 4.0 u┐ywane s╣ rozg│oszenia interfejsu NetBIOS.

W│╣czenie wyszukiwa± Us│ugi nazw RPC w konsoli snap-in U┐ytkownicy i komputery Active Directory

     W konsoli snap-in U┐ytkownicy i komputery Active Directory z menu Widok (View) nale┐y wybraµ Opcje zaawansowane (Advanced Features). W kontenerze System znajduje siΩ kontener Us│ugi RPC (RpcServices), kt≤ry nale┐y wybraµ prawym przyciskiem, a nastΩpnie klikn╣µ W│a£ciwo£ci (Properties). Zostanie wy£wietlone okno w│a£ciwo£ci Us│ugi RPC (RpcServices), w kt≤rym znajduje siΩ pole wyboru W│╣cz wyszukiwania Us│ugi nazw RPC dla system≤w pre-Windows 2000 (Enable RPC Name Service lookups for pre-Windows 2000). Opcja wyszukiwa± us│ugi nazw RPC dla komputer≤w dzia│aj╣cych w oparciu o system Windows NT 4.0 lub wcze£niejsze domy£lnie jest w│╣czona.

Stosowanie Procedury lokalizacji RPC i NetBIOS

     NetBIOS s│u┐y w procedurze lokalizacji RPC do komunikacji przy pomocy wiadomo£ci pocztowych. Procedura lokalizacji RPC stosuje wiadomo£ci pocztowe do wysy│ania rozg│osze± i odbierania odpowiedzi z domeny. W│asno£µ ta zapewnia zgodno£µ z systemem Windows NT 4.0. Interfejs NetBIOS w systemie Windows 2000 jest obs│ugiwany domy£lnie przez protok≤│ TCP/IP. Mo┐na wy│╣czyµ NetBIOS na poszczeg≤lnych komputerach lub podczas konfiguracji us│ugi DHCP.
     WiΩcej informacji o wy│╣czaniu interfejsu NetBIOS przez TCP/IP znajduje siΩ w ksi╣┐ce Microsoft Windows 2000 Server Resource Kit System sieciowy TCP/IP.

Aspekty zabezpiecze± us│ug

     Us│ugi mo┐na uruchomiµ w jednym z dw≤ch kontekst≤w bezpiecze±stwa:      Kontekst bezpiecze±stwa, w kt≤rym dzia│a us│uga, wp│ywa na posiadanie przez tΩ us│ugΩ prawa dostΩpu na komputerze lub w sieci.
     Us│uga mo┐e dzia│aµ w kontek£cie konta System lokalny lub w kontek£cie konta danej us│ugi. Konto System lokalny jest specjalnym i predefiniowanym kontem lokalnym dostΩpnym tylko dla proces≤w systemowych i nie posiadaj╣cym has│a.
     Na komputerach z systemem Windows NT 4.0 i wcze£niejszych, us│uga uruchomiona w kontek£cie konta System lokalny dziedziczy kontekst bezpiecze±stwa Kontrolera us│ug (Service Control Manager). Us│udze nie przypisuje siΩ jakiegokolwiek konta zalogowanego u┐ytkownika i nie wymaga potwierdzenia to┐samo£ci (podania nazwy domeny, nazwy u┐ytkownika i has│a). Us│uga ma ograniczony dostΩp do zasob≤w sieciowych, takich jak udzia│y czy potoki, poniewa┐ nie posiada odpowiedniej to┐samo£ci i musi u┐ywaµ po│╣cze± typu null session.
     Na komputerach z systemem Windows 2000, us│uga uruchomiona w kontek£cie konta System lokalny korzysta z to┐samo£ci komputera w trakcie dostΩpu do zasob≤w w sieci i posiada nieograniczony dostΩp do zasob≤w lokalnych. Us│uga uruchomiona w kontek£cie konta System lokalny na kontrolerach domeny posiada nieograniczony dostΩp do katalogu, poniewa┐ kontroler domeny przechowuje replikΩ katalogu, a konto System lokalny posiada pe│ny dostΩp do zasob≤w lokalnych.
     Og≤lnie m≤wi╣c, us│uga wymaga uruchomienia w kontek£cie osobnego konta us│ugi w dowolnym systemie, bez wzglΩdu na rolΩ pe│niona przez system, a tak┐e na kontrolerze domeny.
     Nie wolno na kontrolerze domeny uruchamiaµ us│ugi w kontek£cie konta System lokalny. W ten spos≤b us│uga posiada│aby zbyt szeroki dostΩp do Active Directory, poniewa┐ konto System lokalny ma pe│n╣ kontrolΩ nad Active Directory. WiΩkszo£µ u┐ytkownik≤w £wiadomych zagro┐e± nie zaakceptuje aplikacji, kt≤ra wymaga dzia│ania w tym kontek£cie bezpiecze±stwa, poniewa┐ potencjalnie mo┐e to spowodowaµ powa┐ne uszkodzenie danych katalogu.

Konto System lokalny a konto us│ugi

     Dla us│ug korzystaj╣cych z dostΩpu do Active Directory, dzia│anie w kontek£cie konta System lokalny jest ograniczone. Gdy us│uga jest uruchomiona w kontek£cie konta System lokalny na komputerze nale┐╣cym do domeny, takim jak serwer cz│onkowski Windows 2000 Server czy stacja Windows 2000 Professional, us│uga ta korzysta z kontekstu konta komputera podczas dostΩpu do zasob≤w domeny, takich jak Active Directory. Konta komputer≤w posiadaj╣ bardzo niewielkie przywileje i nie nale┐╣ do grup. Dodanie konta maszyny do grupy nie jest zalecane, poniewa┐ konta podlegaj╣ usuniΩciu i ponownemu utworzeniu, gdy komputer opuszcza, a nastΩpnie przy│╣cza siΩ do domeny. Domy£lna konfiguracja listy ACL dla Active Directory nadaje minimalny dostΩp kontu komputera. Us│ugi dzia│aj╣ce w kontek£cie konta System lokalny posiadaj╣ zatem minimalny dostΩp do Active Directory.
     Instalowanie us│ugi i nadanie jej konta oraz has│a w domenie pozwala jej uzyskaµ dostΩp zgodny uprawnieniami tego konta. Konto domeny mo┐e nale┐eµ do wielu grup bezpiecze±stwa i nie podlega usuniΩciu i ponownemu utworzeniu, gdy komputer opuszcza, a nastΩpnie przy│╣cza siΩ do domeny. Przynale┐no£µ do grupy s│u┐y u│atwieniu w uzyskiwaniu dostΩpu przez posiadaj╣ce w│asne konto us│ugi do ┐╣danych obszar≤w Active Directory. Jednak┐e dzia│anie us│ugi w kontek£cie konta us│ugi posiada r≤wnie┐ nastΩpuj╣ce wady:
  1. Konto musi byµ utworzone zanim us│uga bΩdzie mog│a byµ uruchomiona w kontek£cie tego konta. Je┐eli us│uga instalacyjna tworzy konto, to musi byµ uruchomiona w kontek£cie konta posiadaj╣cego przywileje, umo┐liwiaj╣ce tworzenie kont w us│udze katalogowej.
  2. Has│a kont us│ug s╣ przechowywane na ka┐dym komputerze, na kt≤rym zainstalowana jest dana us│uga. W przypadku zmiany has│a konta us│ugi na komputerze, us│uga nie mo┐e byµ uruchamiana na tych komputerach, na kt≤rych nowe has│o tej us│ugi nie jest jeszcze zmienione.
Uwaga Je┐eli us│uga dzia│a w kontek£cie konta System lokalny, nale┐y wykonaµ test dzia│ania us│ugi na serwerze cz│onkowskim, aby sprawdziµ czy us│uga posiada wystarczaj╣ce prawa czytania/zapisu w katalogu Active Directory. Komputer dzia│aj╣cy w oparciu o system Windows 2000 nie powinien byµ jedynym, na kt≤rym nale┐y przeprowadziµ taki test. Nale┐y pamiΩtaµ, ┐e us│uga uruchomiona w kontek£cie konta System lokalny na kontrolerze domeny Windows 2000 posiada pe│ny dostΩp do Active Directory, podczas gdy w przypadku serwera cz│onkowskiego dzia│aj╣cego w kontek£cie konta komputera uprawnienia s╣ znacznie mniejsze, ni┐ ma to miejsce na kontrolerze domeny.

Wzajemne uwierzytelnienie

     Wzajemne uwierzytelnienie jest cech╣ bezpiecze±stwa, w kt≤rej proces klienta musi udowodniµ serwerowi w│asn╣ to┐samo£µ, a serwer udowadnia w│asn╣ klientowi,
     zanim jakiekolwiek dane zostan╣ przes│ane po│╣czeniem klient-serwer. Obs│uga wzajemnego uwierzytelnienia jest zapewniona dziΩki interfejsowi dostawcy zabezpiecze± (security support provider interface - SSPI) i jest udostΩpniona bezpo£rednio przez funkcje API SSPI oraz us│ugi znajduj╣ce siΩ pod warstw╣ SSPI obejmuj╣c╣ wywo│ania RPC i model COM+.
     Nie wszystkie pakiety zabezpiecze± dostΩpne przez SSPI oraz us│ugi dzia│aj╣ce w systemie Windows 2000 obs│uguj╣ wzajemne uwierzytelnianie. Aby zaistnia│o wzajemne uwierzytelnienie, aplikacja musi ┐╣daµ wzajemnego uwierzytelnienia i obs│ugiwanych pakiet≤w zabezpiecze±.
     Wzajemne uwierzytelnienie wymaga od klienta i serwera obustronnego udowodnienia posiadania odpowiednich to┐samo£ci, zanim wykonana bΩdzie jakakolwiek funkcja aplikacji. To┐samo£µ mo┐na udowodniµ, wykorzystuj╣c zaufane mechanizmy po£rednicz╣ce i klucze shared-secret, stosowane na przyk│ad w protokole Kerberos 5, lub wykorzystuj╣c mechanizmy szyfrowania danych stosowane w infrastrukturze klucza publicznego. Ka┐dy po£rednik jest identyfikowany za pomoc╣ nazwy g│≤wnej.

Nazwy g│≤wne

     Centralnym elementem wzajemnego uwierzytelnienia jest zasada, ┐e ┐aden po£rednik nie mo┐e ufaµ innemu przed udowodnieniem to┐samo£ci, co praktycznie oznacza, ┐e serwer musi ustaliµ to┐samo£µ klienta bez pytania o to klienta, a klient musi ustaliµ to┐samo£µ serwera bez pytania serwera. Unika siΩ w ten spos≤b kompromisu prostej personifikacji.

Wzajemne uwierzytelnienie a protok≤│ Kerberos

     Klienci ustalaj╣ lokalny kontekst bezpiecze±stwa przez uruchomienie w poprzednio ustalonym kontek£cie û na przyk│ad w sesji zalogowanego u┐ytkownika û lub przez jawne potwierdzenie to┐samo£ci dostawcom zabezpiecze±. Serwer odmawia nawi╣zania po│╣czenia z dowolnym klientem, kt≤ry nie jest uwierzytelniony. Klient uwierzytelnia serwer tworz╣c nazwΩ g│≤wn╣ us│ugi (service principal name - SPN) w oparciu o informacje, jakie ju┐ uzyska│ o serwerze lub jakie uzyskuje z innego zaufanego ƒr≤d│a (ale nie serwera, kt≤ry nie jest zaufany, dop≤ki nie zostanie uwierzytelniony). Klient przekazuje podsystemowi bezpiecze±stwa nazwΩ SPN i domaga siΩ uwierzytelnienia przez serwer przy u┐yciu przedstawionej nazwy. Klient odrzuca te wiadomo£ci z serwera, kt≤re nie mog╣ uwierzytelniµ nazwy SPN.
Uwaga W przypadku, gdy konto us│ugi znajduje siΩ w innej ni┐ klienta strukturze lasu, wzajemne uwierzytelnienie zako±czy siΩ niepowodzeniem, poniewa┐ protok≤│ Kerberos nie mo┐e odnaleƒµ konta us│ugi.
     Zar≤wno klient, jak i us│uga musz╣ byµ uruchomieni w systemie Windows 2000, poniewa┐ w przeciwnym wypadku nie powiedzie siΩ wzajemne uwierzytelnienie z wykorzystaniem protoko│u Kerberos. Protok≤│ Kerberos nie jest obs│ugiwany przez wcze£niejsze wersje systemu Windows.
     Nazwa g│≤wna us│ugi zawiera nazwΩ DNS hosta, na kt≤rym uruchomiona jest us│uga. Nale┐y zatem u┐ywaµ nazw DNS, gdy┐ nazwy typu NetBIOS nie s╣ obs│ugiwane.

Nazwy g│≤wne us│ug

     Nazwy g│≤wne us│ug s╣ kojarzone z elementami bezpiecze±stwa (u┐ytkownik lub grupa), w kt≤rych kontek£cie wykonywana jest us│uga. Nazwy SPN s╣ u┐ywane do obs│ugi wzajemnego uwierzytelnienia miΩdzy aplikacj╣ klienta a us│ug╣. Nazwa SPN jest utworzona na podstawie informacji, jakie klient posiada o us│udze. Mo┐e byµ r≤wnie┐ uzyskana od zaufanego po£rednika, takiego jak Active Directory. Nazwa g│≤wna us│ugi jest zwi╣zana z kontem, a konto mo┐e posiadaµ wiele nazw g│≤wnych us│ugi.
     WiΩcej informacji o rejestrowaniu nazwy g│≤wnej us│ugi w Active Directory w trakcie instalacji us│ugi znajduje siΩ w odno£niku MSDN na stronie Web Resources pod adresem: http://windows.microsoft.com/widows2000/reskit/webresources.

Sk│adnia nazw g│≤wnych us│ugi

     Us│uga stosuje poni┐sze elementy do tworzenia nazwy g│≤wnej us│ugi.
     Podstawowa sk│adnia nazwy g│≤wnej us│ugi:
     typ us│ugi/nazwa wyst╣pienia:numer portu/nazwa us│ugi
     gdzie poszczeg≤lne czΩ£ci sk│adni maj╣ nastΩpuj╣ce znaczenie:      Je┐eli nazwa us│ugi i nazwa wyst╣pienia s╣ identyczne, co zdarza siΩ w przypadku wiΩkszo£ci us│ug dzia│aj╣cych na komputerze hosta, to nazwa g│≤wna us│ugi mo┐e byµ skr≤cona do dw≤ch sk│adnik≤w:      Je┐eli numer portu jest r≤┐ny od domy£lnego portu danego typu us│ugi okre£lonego przez typ us│ugi, nale┐y okre£liµ numer portu.      WiΩcej informacji o interfejsach GSS i SSPI znajduje siΩ w rozdziale äUwierzytelnianieö w niniejszym tomie Microsoft Windows 2000 Server Resource Kit.

Tworzenie nazwy g│≤wnej us│ugi

     Nazwa g│≤wna dla us│ugi jest tworzona przez klienta i mo┐e byµ jedn╣ z nastΩpuj╣cych nazw: nazwa DNS domeny, nazwa DNS hosta lub nazwa lokalizacyjna obiektu punktu po│╣czenia z us│ug╣. Nazwa SPN jest taka sama, bez wzglΩdu na metodΩ uwierzytelniania. Stosuj╣c protok≤│ Kerberos do uwierzytelniania na serwerze, klient ┐╣da biletu sesji dla nazwy g│≤wnej us│ugi. W przypadku uwierzytelnienia opartego o certyfikat, nazwa SPN jest weryfikowana pod k╣tem posiadania pola äSubjectNameö certyfikatu serwera.

Nazwa w us│ugi bazuj╣cej na komputerze hosta DNS

     Us│uga dzia│aj╣ca na komputerze hosta jest us│ug╣ identyfikowan╣ za pomoc╣ nazwy hosta, na kt≤rym uruchomiona jest ta us│uga. W takich przypadkach nazwa g│≤wna us│ugi jest nastΩpuj╣ca:
     typ us│ugi/nazwa hosta:numer portu
     Je┐eli us│uga u┐ywa domy£lnego portu danego typu us│ugi okre£lonego przez typ us│ugi, to nazwa SPN mo┐e byµ skr≤cona do nastΩpuj╣cych sk│adnik≤w:
     typ us│ugi/nazwa hosta

Nazwa us│ugi w us│udze katalogowej

     Nazwa g│≤wna us│ugi okre£lona w us│udze katalogowej posiada nastΩpuj╣c╣ sk│adniΩ:
     typ us│ugi/nazwa hosta:numer portu/nazwa lokalizacyjna
     gdzie poszczeg≤lne czΩ£ci sk│adni maj╣ nastΩpuj╣ce znaczenie:      Na przyk│ad, nazwa g│≤wna us│ugi wydruku, dzia│aj╣cej na niestandardowym porcie 1234 na komputerze äprt1.ntdom.reskit.comö i udostΩpnionej dla znajduj╣cej siΩ w budynku nr 26 i nale┐╣cej do domeny Reskit grupy NTDOM o nazwie lokalizacyjnej äcn=bldg26,dc=ntdom,dc=reskit,dc=comö jest nastΩpuj╣ca:
     print/prt1.ntdom.reskit.com:1234/cn=bldg26,dc=ntdom,dc=reskit,dc=com
     WiΩcej informacji o nazwach g│≤wnych us│ug znajduje siΩ w odno£niku MSDN na stronie Web Resources pod adresem http://windows.microsoft.com/widows2000/reskit/webresources.

Dodatkowe ƒr≤d│a informacji

     WiΩcej informacji o projektowaniu us│ug dla procesu publikacji w Active Directory znajduje siΩ w odno£niku Microsoft Platform SDK na stronie Web Resources pod adresem http://windows.microsoft.com/widows2000/reskit/webresources.