Rozdział 5





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:

Usługa wymaga opublikowania informacji o niej w hierarchii domeny, nigdy w hierarchii konfiguracji.
Usługa wymaga tworzenia obiektów usługi w tej samej domenie, w której na komputerze działa ta usługa, oraz w lokalizacji, która jest odpowiednia do administrowania usługą i do przechowywania tych obiektów. Zalecaną lokalizacją jest obiekt komputera, na którym usługa jest zainstalowana.
     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:

Komputer
Jednostka organizacji
System lub jeden z obiektów podrzędnych

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:

Utworzyć podrzędny obiekt klasy kontener bezpośrednio w kontenerze System i nadać temu kontenerowi nazwę wyraźnie związaną z daną usługą.
Opublikować w kontenerze System obiekty usług. Na przykład Microsoft NetMeeting korzysta z kontenera Spotkania (Meetings), aby opublikować obiekty konferencji. Gdy wiele produktów jednego producenta publikuje obiekty w ten sposób, kontenery każdej z usług wymagają utworzenia kontenera podrzędnego, którego nazwa powinna być wyraźnie związana z określonym producentem. Kontener określonego producenta należy utworzyć jako podrzędny obiekt kontenera System.
     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:

Podczas instalowania usług należy utworzyć obiekty punktów połączeń tak, aby użytkownik z wystarczającymi przywilejami mógł zainstalować opublikowaną usługę używającą takiego punktu połączenia.
Należy ograniczyć przeprowadzanie aktualizacji istniejących obiektów punktów połączeń do czasu, kiedy uruchamiana jest usługa.
     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żą:

Kontener Usługi RPC (RpcServices) jest tworzony podczas instalacji kontrolera domeny. Domyślnie, wszystkie wejścia Usługi nazw RPC utworzone w Usługi RPC (RpcServices) dziedziczą listy ACL tego obiektu kontenera. Dzięki przypisaniu domyślnych list ACL temu kontenerowi, administrator może zapewnić zastosowanie tych list wszystkim wejściom Usługi nazw RPC w obszarze danej domeny.
Konsola snap-in Użytkownicy i  komputery Active Directory pozwala określać listy ACL dla dowolnych obiektów Active Directory.
Procedura lokalizacji RPC personifikuje identyfikator bezpieczeństwa (SID) procesu potomnego w trakcie wywołania usługi katalogowej, w celu przeprowadzenia weryfikacji z listą ACL. Eksport interfejsu następuje lokalnie, ale nie na stałe i jest widoczny tylko w przypadku użycia w sposób zgodny z systemem Windows NT 4.0, jak na przykład metodą rozgłoszenia omówioną w następnej części tego rozdziału.

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:

konto System lokalny (LocalSystem)
konto Domeny Windows 2000 (Windows 2000 Domain), określane jako konto usługi.
     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:

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.
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:

typ usługi. Typ usługi, jak na przykład "www" dla usługi World Wide Web lub "ldap" dla Lightweight Directory Access Protocol.
nazwa wystąpienia. Nazwa wystąpienia usługi. W zależności o typu usługi jest to nazwa lub adres IP hosta, na którym działa usługa.
numer portu. Numer portu używany przez usługę na komputerze hosta w przypadku, gdy jest różny od domyślnego portu danego typu usługi.
nazwa usługi. Nazwa usługi. Nazwą usługi może być nazwą DNS hosta, usługi replikowanej lub domeny. Może to być także nazwa lokalizacyjna obiektu punktu połączenia z usługą lub obiektu usługi RPC.
     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:

nazwa usługi/nazwa wystąpienia:numer portu
     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.

typ usługi/nazwa wystąpienia
Jeżeli numer portu jest domyślnym portem typu usługi określonego przez typ usługi, nie ma potrzeby określać numeru portu, którego postać nie jest zgodna z interfejsem API Generic Security Services (GSS)
     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:

typ usługi. Typ usługi, który jest wyświetlany (na przykład "print").
nazwa lokalizacyjna. Nazwa lokalizacyjna w formacie określonym przez dokument Request for Comments (RFC) 1779 autorstwa instytucji Internet Engineering Task Force. Jest to nazwa wystąpienia usługi typu typ usługi (na przykład "cn=bldg26,dc=ntdom,dc=reskit,dc=com").
nazwa hosta. Nazwa DNS hosta, na którym działa wystąpienie usługi określonej przez nazwę lokalizacyjną.
nazwa domeny. Nazwa domeny zawierającej konto, w kontekście którego uruchomiona jest usługa określona przez nazwę lokalizacyjną (złożona ze składników "dc=" nazwy lokalizacyjnej).
     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.