Jak już zostało wspomniane w pierwszych rozdziałach, usługi katalogowe są całkiem nową ideą w porównaniu z bazą użytkowników znaną z systemu Windows NT Server. Bardzo interesujące w Active Directory jest pojawienie się nowego zestawu jak dotąd niespotykanych opcji, dotyczących integracji innych aplikacji i usług używanych w przedsiębiorstwie. Choć prawdopodobnie tylko niewielka część niezależnych producentów oprogramowania (ISV – Independent Software Vendor) skorzysta w najbliższych latach z usług katalogowych, trzeba wziąć pod uwagę możliwości, jakie one przynoszą, aby móc skorzystać z nich mając ku temu sposobność — lub zaakceptować fakt, iż tak naprawdę na tych opcjach nie zyskamy.
Kto wie? Może się okazać, że integracja przyniesie tyle korzyści, iż opłaci się samemu ją zaaranżować za pomocą jakiegoś mechanizmu integracji katalogów. Lub — jeszcze lepiej — możemy znaleźć się w pozycji, pozwalającej na wywarcie łagodnego nacisku na bieżących dostawców aplikacji, aby dodali do swojego planu pozycję „Korzystanie z Active Directory” lub coś w tym rodzaju.
Integracja z Active Directory nie jest jednak decyzją „albo-albo”, jak wkrótce zobaczymy ze szczegółowych opisów integracji katalogów w dalszej części tego rozdziału. Jak wiele innych podobnych zagadnień, możliwości integracji obejmują bardzo szeroki wachlarz rozwiązań, wobec czego może ona posłużyć zarówno do zadań bardzo trywialnych, jak też mających bardzo głęboki wpływ dla administratora i przedsiębiorstwa. Mam nadzieję, iż ten rozdział pomoże uniknąć nieistotnych rozwiązań i nauczyć się, jak zebrać w przyszłości zyski z Active Directory.
Można wymyślić mnóstwo różnorodnych scenariuszy integracji, lecz Microsoft ustalił już dla niezależnych dostawców oprogramowania (ISV) pewne podstawowe kryteria odniesienia, z którymi należy się zapoznać.
Od najniższego poziomu integracji do najwyższego mamy:
· Punkt połączenia usługi (SCP – Service Connection Point)
· Istniejące obiekty katalogowe
· Nazwę główną usługi (SPN – Service Principal Name)
· Pojedynczy podpis (Single sign-on)
· Pełną lub częściową integrację katalogu
Pierwsze dwa poziomy integracji są wymagane dla spełnienia wymogów specyfikacji „Application Specification for Microsoft Windows 2000 Server, Advanced Server & Datacenter Server, version 1.3” (Specyfikacja aplikacji
Tłumaczyć?
dla Microsoft Windows 2000 Server, Advanced Server & Datacenter Server, wersja 1.3) , która pozwala niezależnym producentom na oznaczenie swojego produktu poszukiwanym logo Certified for Windows.
Uwaga
Niezależni producenci potrzebują punktów połączenia usług jedynie jeśli ich „aplikacja zawiera szereg składników uruchomionych w różnych komputerach” oraz istnieją „składniki klienckie” wymagające usług ze strony „składników serwerowych”. Podobnie, wymagania co do użycia istniejących obiektów katalogowych stosują się jedynie do sytuacji, gdy „klient przechowuje autorytatywne informacje w Active Directory a aplikacja używa tego typu informacji”.
Publikowanie usług zawiaduje tworzeniem, składowaniem i utrzymaniem w bazie danych Active Directory informacji o usługach, które można znaleźć w aplikacjach innych dostawców. Informacje publikowane w Active Directory mogą być wykorzystane przez klienty sieciowe i administratorów sieciowych do znajdowania, łączenia się z usługą i zarządzania. Active Directory ponadto pozwala klientom i administratorom widzieć sieć rozproszoną jako kolekcję usług, nie tylko „jedynie” zbiór poszczególnych komputerów (tylko taka opcja jest dostępna w środowiskach bez usług katalogowych)
Aby opublikować usługę w Active Directory, minimalnym wymogiem jest opublikowanie przez tę usługę w Active Directory swoich informacji o powiązaniach. Powiązania usługi to informacje, których klient używa do podłączenia (powiązania) z egzemplarzem danej usługi. Informacje, potrzebne do powiązania usługi obejmują nazwę i położenie usługi. Na przykład, przeglądarka WWW łączy się z serwerem WWW za pomocą nazwy URL (Uniform Resource Locator) w taki sam sposób, w jaki tworzymy powiązanie z usługą plików za pomocą nazwy UNC (Uniform Naming Convention).
Określona usługa może opublikować samą siebie w Active Directory jednokrotnie lub wielokrotnie. Każda kopia usługi uruchomiona w jednym lub wielu komputerach w sieci może utworzyć obiekt punktu połączenia w Active Directory. Punkt połączenia jako taki reprezentuje jeden lub więcej kopii usługi dostępnej w sieci. Na przykład, jeśli usługa taka, jak Serwer certyfikatów Microsoftu dla Windows 2000 Server jest zainstalowana i uruchomiona w dwóch komputerach w sieci, mogą istnieć dwa obiekty punktu połączenia — jeden dla każdej kopii usługi w każdym komputerze.
Podobnie, usługa zainstalowana w wielu kopiach w pojedynczym komputerze może tworzyć odrębne obiekty punktów połączenia dla każdej kopii. Możliwe jest też opublikowanie wielu kopii replikowanej usługi w Active Directory za pomocą pojedynczego punktu połączenia. W tym przypadku punkt połączenia zawiera informacje, umożliwiające klientowi wybór kopii i powiązanie z nią.
Schemat Active Directory definiuje różnorodne klasy obiektów używane do publikowania usługi. Wszystkie obiekty reprezentujące zasoby, które akceptują połączenia, pochodzą od klasy obiektu Connection Point (punkt połączenia). Przykłady takich obiektów to Volume (wolumin), Print Queue (kolejka wydruku), RPC, Windows Sockets i serviceConnection Point (punkt połączenia usługi)
Punkty połączenia usług (Service Connection Point) są wykorzystywane przez usługi, które muszą opublikować się w Active Directory bezpośrednio zamiast korzystać z istniejącego oddzielenia
abstraktu?
(np. Usługa nazewnicza RPC czy RnR). Usługa, która używa punktu połączenia usługi, powinna udostępnić warstwę oddzielającą, aby ukryć szczegóły położenia usługi przed aplikacjami klientów. Oddzielenie to może być zaimplementowane w postaci biblioteki DLL lub składnika aplikacji klienta. Oddzielenie zapytuje Active Directory o obiekt punktu połączenia, reprezentujący usługę żądaną przez aplikację klienta i wykorzystuje informacje o powiązaniu tego obiektu, by połączyć aplikację klienta z usługą.
Aplikacja klienta znajduje obiekty Service Connection Point reprezentujące potrzebne jej usługi, szukając słów kluczowych w katalogu. Atrybut słów kluczowych SCP jest zawarty w GC, wobec czego klienty mogą po prostu przeszukać GC, by znaleźć odpowiednie punkty połączenia usługi w całym lesie. Z tego powodu klienta nie obchodzi, gdzie (w której domenie) Service Connection Point jest opublikowany. Klient wybiera następnie jeden z obiektów i używa jego informacji o powiązaniach aby połączyć się z usługą.
Usługi oparte na modelu COM nie używają do ogłaszania się punktów połączenia usług — są one publikowane w magazynie klas. Magazyn klas Windows 2000 jest katalogową składnicą dla aplikacji, interfejsów i API umożliwiających publikowanie i przydział aplikacji.
Aby wiedzieć, gdzie opublikować usługi w Active Directory, należy znać i stosować poniższe zasady:
· Usługa powinna publikować swoje informacje w kontekście nazewniczym domeny, a nigdy w kontekście konfiguracji. Opublikowanie informacji w kontekście nazewniczym konfiguracji nie zwiększa dostępności usługi czy też łatwości dostępu. Powoduje za to zwiększony ruch sieciowy replikacji. Ponadto, jeśli klient ma dostęp do komputera z uruchomioną usługą, klient ten powinien też mieć dostęp do repliki domeny zawierającej ten komputer. Wobec tego wystarczy, jeśli usługa opublikuje informacje w domenie, zawierającej komputer, w którym jest uruchomiona.
· Usługa powinna tworzyć obiekty związane z nią w tej samej domenie, w której znajduje się jej komputer, oraz w lokalizacjach wygodnych do zarządzania usługą i utrzymaniem tych obiektów. Zalecanym położeniem jest obiekt komputera, w którym usługa jest zainstalowana.
Obiekty związane z usługą mogą istnieć w trzech typach kontenerów kontekstu nazewniczego domeny:
· Komputery
· Jednostki organizacyjne
· Kontener systemowy lub jego potomne
Rysunek 16.1 przedstawia fragment domyślnej hierarchii kontenerów w partycji domeny, który powinien dać pewne pojęcie, gdzie obiekty SCP (punkty połączenia usług) mogą być umieszczone.
Rysunek 16.1
Gdzie umieścić punkty połączenia usługi
Domain
Domena
Computers
Komputery
System
Host1, 2
Host-based service SCPs
Punkty połączenia usług w hostach
Winsock Services
Usługi Winsock
RPC Services
Usługi RPC
Replicated Service Container
Kontener usługi replikowanej
SCPs for replicas
Punkty połączenia usług dla replik
Bardzo dobrze, jeśli aplikacje korzystające z informacji o elementach sieciowych — np. użytkownikach, komputerach czy urządzeniach — są w stanie pobrać te informacje z Active Directory, zamiast tworzyć odrębny katalog, zawierający spore ilości podwojonych informacji. Microsoft zaleca osiągnięcie tego na jeden z dwóch poniższych sposobów:
§ Aplikacje otrzymujące informacje bezpośrednio z Active Directory — do tego celu schemat Active Directory może wymagać rozszerzenia o kilka obiektów i atrybutów potrzebnych aplikacji, lecz nie znajdujących się w domyślnym schemacie. Patrz też podrozdział „Pełna lub częściowa integracja katalogów”.
§ Utrzymanie dodatkowej kopii informacji znajdujących się w Active Directory — w tym przypadku aplikacja musi udostępnić metodę synchronizacji swoich lokalnych danych katalogowych z danymi Active Directory: albo za pomocą mechanizmu synchronizacji wbudowanego w aplikację, albo przez wystawienie interfejsu API (lub czegoś podobnego) umożliwiającego zewnętrznemu meta-katalogowi lub produktowi synchronizującemu katalogi utrzymanie zgodności informacji zapisanych w katalogu aplikacji z informacjami Active Directory.
Windows 2000 — a co za tym idzie, Active Directory — obsługuje tzw. nazwy główne usług (SPN – Service Principal Name), które są składnikiem kluczowym dla wzajemnego uwierzytelniania. SPN jest unikatową nazwą, która identyfikuje egzemplarz usługi. Nazwy SPN są powiązane z wystawcami zabezpieczeń (czyli kontami użytkowników lub komputerów), w których kontekście zabezpieczeń wykonywana jest usługa. Każdy wystawca zabezpieczeń może posiadać wiele nazw głównych usług — można wykorzystać pojedynczego wystawcę zabezpieczeń do obsługi wielu usług, co pozwala ograniczyć uprawnienia przysługujące usługom do niewielkiej liczby kont, aby utrzymać je w ryzach.
Ustanowienie wzajemnego uwierzytelnienia
Główną zasadą wzajemnego uwierzytelniania jest to, że żadna ze stron nie „ufa” drugiej przed udowodnieniem tożsamości. W praktyce oznacza to, iż serwer musi być w stanie ustalić tożsamość klienta bez pytania klienta, zaś ten musi być w stanie ustalić tożsamość serwera bez pytania serwera, aby uniknąć ataków przez podszywanie.
Inaczej mówiąc, wzajemne uwierzytelnianie jest funkcją zabezpieczeń, w której klient musi udowodnić usłudze swoją tożsamość a usługa swoją tożsamość klientowi, zanim połączenie pomiędzy klientem i usługą zostanie użyte do przesyłu jakichkolwiek danych aplikacji. Zdolność klienta do uwierzytelniania usługi z którą się łączy, jest ważna w aplikacjach klient-serwer, które umożliwiają delegowanie kontekstu zabezpieczeń do klienta.
Tożsamość może być udowodniona przez zaufaną trzecią stronę i używać wspólnego klucza tajnego jak w Kerberosie, albo też za pomocą kryptografii, jak w infrastrukturze kluczy publicznych. Każda strona identyfikowana jest przez nazwę główną.
Podstawy zabezpieczeń usług
Usługi mogą działać w jednym z dwóch kontekstów zabezpieczeń:
§ Konto LocalSystem
§ Zwykłe konto Active Directory, zazwyczaj określane terminem konta usługi.
Kontekst zabezpieczeń, w którym usługa jest uruchomiona, wpływa na prawa dostępu usługi do lokalnego komputera i sieci.
LocalSystem jest specjalnym, wstępnie zdefiniowanym kontem lokalnym, dostępnym tylko dla procesów systemowych. Sporą zaletą tego konta jest brak hasła, dzięki czemu nie trzeba przechodzić od czasu do czasu nużącego procesu zmiany haseł, jak w przypadku kont usług (wszyscy Czytelnicy z doświadczeniem z Windows NT Server są do tego bez wątpienia przyzwyczajeni).
W komputerach Windows 2000 Server usługa uruchomiona w kontekście konta LocalSystem używa poświadczeń (credentials) komputera przy dostępie do zasobów w sieci i ma pełny dostęp do zasobów lokalnych. W DC oznacza to pełny dostęp do katalogu, ponieważ DC mieści replikę katalogu a LocalSystem ma do zasobów lokalnych pełny dostęp. Może się więc okazać, iż wykorzystując konto LocalSystem przyznamy usłudze zbyt dużą władzę.
Największa wada korzystania z konta LocalSystem ujawnia się, gdy usługa działa z tego konta w systemie będącym członkiem domeny — wówczas usługa kontaktując się z zasobami domeny (w tym Active Directory) pracuje w kontekście konta komputera, lecz konta komputerów zwykle posiadają bardzo niewiele przywilejów poza lokalnym systemem i nie należą do zbyt wielu grup.
Z drugiej strony, uruchomienie usługa w kontekście konta usługi ma dwie poważne wady:
§ Konto musi zostać utworzone przed uruchomieniem usługi. Jeśli program instalacyjny usługi tworzy konto, musi być on uruchomiony z konta o przywilejach wystarczających, aby tworzyć konta w usłudze katalogowej.
§ Hasła kont usług są składowane w każdym komputerze, w którym usługa jest zainstalowana. Jeśli hasło dla takiego konta ulegnie zmianie, usługa nie może zostać w tym komputerze uruchomiona, dopóki hasło dla tej usługi nie zostanie zmienione na nowe.
Ogólnie mówiąc, jeśli chcemy utworzyć bezpieczną konfigurację, wszystkie usługi w każdym systemie powinny być uruchamiane z odrębnych kont usług — należy szczególnie stosować się do tej reguły dla usług innych dostawców w kontrolerach domen; w przeciwnym razie usługi te otrzymają zbyt wysokie przywileje.
Składnia SPN wygląda tak: <typ usługi>/<nazwa kopii>:<numer portu>/<nazwa usługi>, gdzie poszczególne składniki mają następujące znaczenie:
· Typ usługi — np. „www” dla World Wide Web lub „ldap” dla Lightweight Directory Access Protocol.
· Nazwa kopii — w zależności od typu usługi, może to być nazwa lub adres IP hosta w którym usługa się mieści
· Numer portu — numer portu używanego przez usługę w hoście, jeśli różni się od domyślnego dla danego typu usługi.
· Nazwa usługi — może to być nazwa DNS hosta, repliki usługi lub domeny, albo też nazwa wyróżniająca obiektu Service Connection Point lub obiektu usługi RPC.
Jeśli nazwa usługi i nazwa egzemplarza są takie same — jak dla większości usług bazujących w hostach — wówczas nazwę główną usługi można skrócić do dwóch składników: <typ usługi>/<nazwa egzemplarza>.
Usługa (lub administrator w imieniu usługi) rejestruje podczas jej instalacji SPN (jeden lub więcej) w Active Directory.
Klienty ustalają lokalny kontekst zabezpieczeń, albo przez uruchomienie w uprzednio założonym kontekście — np. w sesji zalogowanego użytkownika — albo przedstawiając bezpośrednio poświadczenia dostawcy zabezpieczeń.
Klient uwierzytelnia się w serwerze, tworząc nazwę SPN w oparciu o informacje, które już zna dla danej usługi i przedstawia ją systemowi zabezpieczeń, żądając od serwera dowodu, iż może uwierzytelnić SPN. Jeśli serwer nie jest w stanie uwierzytelnić SPN, klient odmawia dalszej łączności. Jeśli do uwierzytelniania w serwerze używany jest Kerberos, klient żąda biletu sesji dla przedstawionej nazwy SPN. W przypadku uwierzytelniania opartego na certyfikatach SPN jest potwierdzany na podstawie zawartości pola SubjectName w certyfikacie serwera.
Każdy przyzna, ze warto posiadać aplikacje, wykorzystujące dla uwierzytelniania infrastrukturę zabezpieczeń skonfigurowaną już w domenie Active Directory. Typowym przykładem tej sytuacji jest pozwolenie przez aplikację administratorowi na odwzorowanie kont Active Directory na wystawców zabezpieczeń lub role używane przez aplikację. W takim przypadku administrator będzie w stanie zastosować istniejącą konfigurację Active Directory (co zwykle oznacza grupy) do przydzielenia aplikacji uprawnień niezbędnych odpowiedniemu podzbiorowi użytkowników — oraz zaoszczędzić po drodze na pracy administracyjnej i zapewnić bardziej przejrzystą konfigurację zabezpieczeń. Użytkownicy też ogromnie na tym zyskają, otrzymując funkcjonalność pojedynczego podpisu (single sign-on), która oszczędza im kłopotów z zapamiętywaniem wielu kont użytkowników i haseł.
Ostatni — i najbardziej zaawansowany — poziom integracji katalogów uzyskiwany jest, jeśli spełnione zostaną poniższe twierdzenia:
§ Aplikacja używa Active Directory do przechowywania wszystkich swoich obiektów katalogowych — w konsekwencji wszelkie przyziemne prace administracyjne mogą być wykonywane przez pracę z bazą danych Active Directory. Dla większości aplikacji pociąga to za sobą wykorzystanie istniejących obiektów i atrybutów, oraz dodanie nowych atrybutów i obiektów do kontekstu nazewniczego domeny i (lub) kontekstu nazewniczego konfiguracji. Ponadto zwykle potrzebna będzie przystawka MMC, aby udostępnić administratorowi „rodzimy” widok obiektów i atrybutów należących do danej aplikacji (jak w przypadku Exchange 2000 Server).
§ Aplikacja polega na Active Directory w zakresie usług zabezpieczeń — znaczy to, iż administrator nie zostanie obciążony żadnymi dodatkowymi zadaniami, związanymi z odrębnym katalogiem, co zwykle pociągnęłoby za sobą utworzenie całego nowego zbioru kont użytkowników, grup i tak dalej, potrzebnych do przydzielenia właściwych uprawnień. Zamiast tego administrator będzie w stanie po prostu dodać stosowne uprawnienia istniejącym w Active Directory wystawcom zabezpieczeń. Jak można sobie wyobrazić, różnica jest ogromna, zarówno przy wstępnej konfiguracji, jak przy codziennym zarządzaniu aplikacją.
Microsoft wymaga zarządzania z przystawki MMC zgodnie z dokumentem „Application Specification for Microsoft Windows 2000 Server, Advanced Server & Datacenter Server, version 1.3” (Specyfikacja aplikacji
dla Microsoft Windows 2000 Server, Advanced Server & Datacenter Server, wersja 1.3), który pozwala niezależnym producentom na oznaczenie swojego produktu poszukiwanym logo Certified for Windows. Jednakże nie jest ważne, czy zarządzanie obiektami odbywa się ze standardowych narzędzi MMC, czy własnego narzędzia MMC aplikacji.
Na tym poziomie integracji aplikacja powinna również korzystać z danych lokacji Active Directory, jeśli informacje te jej mogą dotyczyć.
Marketing produktów z serii Microsoftu .NET Enterprise Servers może łatwo zasugerować każdemu, iż wszystkie te aplikacje serwerowe funkcjonują na najwyższym poziomie integracji z Active Directory (to znaczy pełnej lub częściowej integracji katalogów). Niestety obecnie jest inaczej. Prawdę mówiąc, wsparcie Active Directory różni się dość znacząco pomiędzy poszczególnymi produktami Microsoft .NET Enterprise Server:
· Exchange 2000 Server — pełna integracja katalogu. Exchange 2000 Server rezygnuje z własnego katalogu i korzysta zamiast niego z Active Directory. Exchange 2000 posiada wszystkie cechy funkcjonalne omówione w poprzednim podrozdziale. Aby uniknąć przeciążenia lokacji Active Directory, wprowadza własną definicję lokacji (zwanych Routing Groups – grupami trasowania), służących do trasowania komunikatów. Po szczegółowe omówienie serwera Exchange 2000 (oraz jego poprzednika, Exchange Server 5.5) użytego w połączeniu z Active Directory odsyłam do rozdziału 15.
· SQL Server 2000 — udostępnia funkcjonalność pojedynczego podpisu, oraz obsługę SCP i SPN. Funkcjonalność pojedynczego podpisu jest dostępna, jeśli SQL Server działa w trybie uwierzytelniania systemu Windows (Windows Authentication Mode) — w tym przypadku administrator ma prawo tworzyć odwzorowania istniejących wystawców zabezpieczeń Active Directory na role w systemie SQL Server. SCP służy do publikowania kopii SQL Server 2000, w tym informacji o replikacji, publikacjach, bazach danych i serwerach SQL Server Analysis.
· Host Integration Server 2000 — udostępnia funkcjonalność pojedynczego podpisu dla sesji emulacji 3270 i 5250 (APPC i CPI-C), oraz obsługę SCP – SPN.
· Internet Security and Acceleration (ISA) Server 2000 — pełna integracja katalogu. ISA Enterprise Edition pozwala na wykorzystanie Active Directory do skalowalnej i scentralizowanej administracji ISA Access Policies (Zasad dostępu ISA) oraz informacji ISA Server Configuration (Konfiguracji serwera ISA) z Active Directory. Ponadto, uprawnienia mogą być przyznawane użytkownikom i grupom Active Directory. W trakcie pisania tego tekstu ISA 2000 Server był dostępny jedynie w wersji RC1
Co to jest?
· , więc powyższe informacje mogą jeszcze ulec zmianie.
Microsoft SMS
Obecna wersja 2.0 Microsoft Systems Management Server (SMS) zawiera bardzo ograniczone wsparcie Active Directory. SMS 2.0 z Service Pack 2 obsługuje platformę Windows 2000 (klienty i serwery) oraz większość integracji dostępnej w Windows NT 4 Server. Jednakże SMS widzi Active Directory jedynie jako kolejny typ bazy danych SAM, więc nie można tu mówić o jakiejkolwiek integracji z Active Directory.
Lecz Microsoft obiecał, iż następna wersja (obecnie pod nazwą Emerald) będzie zawierać głęboką integrację z Active Directory (być może na najwyższym poziomie integracji katalogów), w tym obsługę funkcji Dodaj/usuń programy.
Microsoft obecnie jest daleko przed peletonem w dziedzinie integracji z Active Directory. Praktycznie wszelkie aplikacje serwerowe, jakie dotąd napotkałem (oprócz kilku narzędzi utworzonych na potrzeby zarządzania i migracji do Active Directory) zawierają jedynie obsługę SCP i ewentualnie SPN. Sądząc z obecnego braku deklaracji zorientowania na Active Directory ze strony niezależnych producentów oprogramowania, można bezpiecznie zakładać, iż obraz ten w najbliższym czasie nie zostanie wywrócony do góry nogami.
Wskazówka
Przegląd aplikacji z certyfikatem dla Windows 2000 można znaleźć pod adresem www.microsoft.com/windows2000/upgrade/compat/certified.asp. Raporty certyfikacji VeriTest można znaleźć pod www.veritest.com/mslogos/windows2000/certification/ServerApps.asp. Proszę zauważyć, iż raporty te są dość podstawowe, więc nie można na ich podstawie ustalić dokładnie poziomu integracji z Active Directory, lecz stanowią do tego niezły punkt wyjścia.
Warto jeszcze zauważyć, iż aplikacje klienckie i serwerowe nie są jedynymi obszarami, w których można dużo zyskać na integracji. Sporo korzyści można jeszcze odnieść przy zarządzaniu siecią.
Na przykład, mogliśmy wprowadzić odrębną bazę danych użytkowników dla instalacji wirtualnych sieci prywatnych (VPN – Virtual Private Network) opartej na sprzęcie sieciowym. To samo praktycznie dotyczy rozwiązań jakości usług (QoS – Quality of Service), wirtualnych sieci lokalnych (VLAN) czy też zaawansowanych rozwiązań zapór sieciowych, których możemy używać lub planować na przyszłość. Należy zwrócić uwagę, iż dostępne opcje zależą od wyboru producenta sprzętu sieciowego:
§ Nortel Networks (dawniejsze Bay Networks) udostępnia obecnie bardzo niewielki poziom integracji z Active Directory — wsparcie ograniczone jest do tego, co oferują wiodące standardy, w tym L2TP, IPSec oraz dwa QoS – RSVP i DiffServ. Do chwili pisania tego tekstu firma Nortel Networks nie ujawniła żadnych zamiarów polepszenia integracji z Active Directory w najbliższej przyszłości, z wyjątkiem następnej wersji Optivity Policy Services (menedżer jakości usług Nortela), która obiecuje pewną integrację z Active Directory. Wygląda jednak na to, iż Nortel zamierza otworzyć swoje produkty używając LDAP, z czego można będzie skorzystać za pomocą MMS (patrz następny podrozdział).
§ Cisco Systems współpracuje ściśle z Microsoftem, od samego początku podróży Microsoftu w kierunku gotowego produktu Windows 2000. I chociaż Cisco nadal pracuje nad implementacją wszystkich obiecanych możliwości integracji, firma ujawniła już wiele interesujących punktów integracji, w tym zarządzanie VLAN, QoS, VPN i zaporami, jak również własnymi rozwiązaniami Cisco DHCP, DNS i PKI. Jednakże praca nad funkcjami integracji z Active Directory nadal trwa, więc rozsądnie będzie zapoznać się z faktycznie dostępnymi opcjami w chwili implementacji systemu.
...
chamil86