Rozdział 23

Współistnienie i migracja ze środowisk innych producentów

Mimo nadziei Microsoftu na odwrotny stan rzeczy, dostępnych jest wiele popularnych platform serwerowych innych niż Windows. A ponieważ platforma Windows staje się wszechobecna w większych firmach informatycznych, które zwykle korzystają z kilku platform systemów operacyjnych (OS), klienci coraz intensywniej domagają się integracji między Windows i własnymi platformami OS.

Chociaż Microsoft zdaje sobie sprawę z żądań własnych klientów, dotyczących ułatwienia migracji z innych platform serwerowych do Windows, skuteczność działań Microsoftu na polu współistnienia była różna — łagodnie mówiąc. Do niedawna Microsoft zdawał się ignorować potrzebę współistnienia z innymi platformami serwerowymi i koncentrował się całkowicie na dostarczeniu skutecznego zestawu narzędzi do migracji z systemów swojego najbliższego rywala na rynku serwerów – Novell NetWare. Jednakże sądząc ze zbioru funkcji Windows 2000 Server, Microsoft najwyraźniej posłuchał części żądań klientów, dotyczących potrzeby udogodnienia migracji i współistnienia.

Bieżący rozdział zarysowuje obecne wsparcie Microsoftu (i plany na przyszłość) dla migracji i współistnienia z każdym ze znaczących serwerowych systemów operacyjnych, w tym Novell NetWare 3.x, 4.x i 5.x, Unix (ze względów praktycznych wszystkie wersje będą omówione jako jedna grupa, chociaż istnieje całkiem sporo różnic pomiędzy najpopularniejszymi wersjami Uniksa), Apple Macintosh, IBM OS/2, Banyan VINES i systemów głównych. Jak zobaczymy, perspektywy migracji i współistnienia nie są tak złe dla systemu Windows 2000 Server, jak można się spodziewać z wcześniejszych doświadczeń z Windows NT Server.

Jaka jest strategia integracji Microsoftu

Zanim zagłębimy się w szczegółowe omówienie obsługi przez Microsoft integracji z każdym z wiodących serwerowych systemów operacyjnych innych producentów, ten podrozdział zajmuje się ogólnym spojrzeniem Microsoftu na integrację systemu Windows 2000 Server i Active Directory z rywalizującymi systemami serwerowymi i aplikacjami innych producentów. Informacje te pozwolą Czytelnikowi zrozumieć funkcjonalność — i niedostatki — zdolności współpracy systemu Windows 2000 Server i czego powinniśmy spodziewać się w przyszłości. Wysoce poszukiwana funkcja pojedynczego podpisu (SSO – Single Sign-On) jest jedną z pierwszych rzeczy, na których promocję za pomocą Active Directory stawia Microsoft. SSO pozwala użytkownikom sieci przedsiębiorstw korzystać z wszystkich autoryzowanych zasobów sieciowych „bez szwów”, w oparciu o pojedyncze uwierzytelnienie dokonane przy pierwszym dostępie do sieci. Oszczędzając użytkownikom dzisiejszych kłopotów (to znaczy konieczności wielokrotnego logowania do różnych aplikacji) SSO jest potencjalnie w stanie zwiększyć produktywność użytkowników sieci, zmniejszyć koszty eksploatacji i zwiększyć bezpieczeństwo sieci.

Aby funkcjonalność SSO była naprawdę wszechobecna, zasoby sieciowe dostępne przez SSO powinny obejmować od drukarek i innego sprzętu do aplikacji, plików i innych danych, rozrzuconych po serwerach używających różnych systemów operacyjnych w obszarze całego przedsiębiorstwa. Jednakże ten „raj komputerowy” nie nastanie zbyt szybko, jak mogą przypuszczać bardziej doświadczeni użytkownicy.

W dużym stopniu zostało to spowodowane faktem, iż strategia integracji Microsoftu koncentrowała się jak dotąd wyłącznie na dwóch założeniach:

·       Udostępnienie skutecznych narzędzi migracji — reguła sprawiała wrażenie następującej: im większy konkurent, tym Microsoft oferował lepszy zestaw narzędzi do migracji.

·       Udostępnienie integracji z Active Directory do wiodących systemów operacyjnych konkurentów Microsoftu — z oczywistych powodów Microsoft zawęził silnie pole uwagi do głównych konkurentów w zakresie systemów operacyjnych. Z tego powodu można było uzyskać zadowalający poziom integracji z innymi systemami operacyjnymi jedynie udostępniając informacje z bazy danych Active Directory do tych systemów operacyjnych — nigdy w przeciwnym kierunku. Microsoft zazwyczaj rezerwował możliwość dwukierunkowej replikacji dla niewielu wybranych produktów (zazwyczaj własnych aplikacji serwerowych).

Jeśli więc Czytelnik planuje utrzymanie i aktualizacje swoich najważniejszych informacji sieciowej blisko klientów (czyli sieciowych systemów operacyjnych obsługujących każdy podzbiór klientów), oznacza to konflikt ze strategią Microsoftu. Windows 2000 Server i Active Directory po prostu nie są przystosowane do pomocy w uzyskaniu tego typu równorzędnej integracji. Wobec tego jedynym sposobem na osiągnięcie jakiegokolwiek poziomu takiej integracji było znalezienie narzędzia innej firmy, które mogło zapewnić pożądaną funkcjonalność pomiędzy platformami (co było zwykle bardzo trudne i dość kosztowne, jeśli w ogóle możliwe). Jednakże Microsoft w roku 2000 znacznie złagodził swoje stanowisko. W ramach decyzji, by zacząć zachęcać do integracji z aplikacjami innych producentów, Microsoft z wolna zaczyna przymierzać się do opcji dwukierunkowej integracji z Active Directory.

Wskazówka

Rozdział 16. zajmuje się szczegółowym omówieniem integracji aplikacji z Active Directory.

Trzeba jednak zdawać sobie sprawę z faktu, iż Microsoft wciąż potrzebuje solidnej porcji ocieplenia

lub: rozgrzewki

, zanim osiągnie poziom prawdziwej otwartości w kierunku innych systemów operacyjnych. Warto więc przestudiować komentarze na temat różnych technologii i rozwiązań, zawarte w dalszej części rozdziału.

Trzy podstawy strategii Microsoftu

Microsoftowi zależy na eliminacji pozostałej konkurencji Novella na rynku serwerów klasy PC. Wobec tego, historycznie Microsoft koncentrował swoje wysiłki na uczynieniu migracji z platformy NetWare/NDS Novella propozycją jak najbardziej atrakcyjną. Wygląda na to, iż strategia taka wybitnie się opłaci, ponieważ Novell nie poczynił w ostatnich latach zbytniego postępu w kierunku usług katalogowych. Niskie stopy wzrostu w sektorze oprogramowania tradycyjnie już są bardzo dobrym wskaźnikiem kłopotów produktu, więc możemy oczekiwać, iż w nadchodzących latach Microsoft czeka rosnąca liczba migracji z usługi katalogowej NDS Novella do Active Directory.

Lecz Novell nie jest jedynym graczem przy stole. Zdając sobie z tego sprawę, Microsoft zaczął dodawać możliwości integracji dla innych popularnych sieciowych systemów operacyjnych. Microsoft w coraz większym stopniu uważa integrację za więcej niż działanie obronne — to znaczy, jako wysiłek w kierunku zniechęcenia klientów do wyboru z tego powodu NetWare (mimo iż Novell również włożył sporo pracy w problem współistnienia). Jednakże Novell jest dziś znacznie mniej budzącym strach, ponieważ zbliża się do utraty pozycji wiodącego konkurenta Windows 2000 Server w segmencie PC na rzecz Linuksa. Ponadto Microsoft obecnie celuje systemem Windows 2000 Server w rynek najsilniejszego sprzętu, co oznacza, że opcje migracji i współpracy z Uniksem stają się coraz ważniejsze.

Kolejną bardzo ważną podstawą strategii integracji Microsoftu jest chęć umieszczenia Active Directory w sercu infrastruktury sieciowej — jako meta-katalogu. Microsoft chce przekonać firmy do umieszczenia Active Directory w centrum przedsiębiorstwa (do składowania kont użytkowników i wszelkich innych ważnych informacji związanych z integracją z aplikacjami innych producentów, sprzętem sieciowym i potencjalnie innymi systemami operacyjnymi).

Aby to uczynić, firma musi rozwinąć Active Directory w centralny zasób, udostępniający najważniejsze usługi wszystkim użytkownikom sieci (patrz rysunek 23.1). Microsoft pracuje obecnie usilnie nad produktem o nazwie Microsoft Metadirectory Services (MMS), który pozwoli zaspokoić niemal wszelkie potrzeby integracji z innymi katalogami.

Rysunek 23.1

Strategia Microsoftu dla systemu Windows 2000 Server i Active Directory jest bardzo prosta: uczynić z Active Directory centrum przedsiębiorstwa

Wskazówka

Rozdział 16. zawiera bardziej szczegółowe omówienie MMS.

I nie jest po prostu kolejny produkt Microsoftu. MMS jest przepakowanym jednym z najlepszych meta-katalogów na rynku (Zoomit VIA), zakupionym przez Microsoft. Ponadto MMS ma za jakiś czas stać się integralną częścią Active Directory (co jest jednym z głównych powodów, dla których Microsoft rozprowadza MMS za darmo dla autoryzowanych partnerów). Jednakże podobnie jak każdy inny produkt meta-katalogowy, MMS wymaga do pomyślnego wdrożenia pewnych mocno wyspecjalizowanych umiejętności. Z tego powodu MMS jest obecnie dostępny jedynie dla klientów wybranej grupy autoryzowanych partnerów jako składnik zakupu czasu konsultacji.

Cel nr 1: udostępnienie pojedynczego podpisu

Jak uprzednio wspomniano, pojedynczy podpis (SSO – Single Sign-On) to zdolność użytkowników do jednokrotnego uwierzytelnienia się (dowodzenia swojej tożsamości) dla wszystkich usług dostępnych w sieci.

Każde przedsiębiorstwo korzystające z systemów komputerowych może zyskać na posiadaniu zdolności SSO:

·         Użytkownicy są bardziej produktywni, jeśli usunie się przeszkody pomiędzy nimi i zasobami, z których mają prawo korzystać.

·         Sieci mogą być zarządzane przez mniejszą liczbę administratorów dzięki konsolidacji informacji sieciowych.

·         Bezpieczeństwo sieci jest zwiększone dzięki bezpiecznym protokołom uwierzytelniania i eliminacji najczęściej występującego zagrożenia bezpieczeństwa sieci: zapisywania haseł przez użytkowników.

Chociaż pojedynczy podpis potencjalnie może przynieść duże korzyści wszystkim zaangażowanym stronom, jednak nigdy nie był w pełni zaimplementowany, z wyjątkiem kilku przedsiębiorstw, które skonsolidowały się z pomocą jakiegoś produktu SSO klasy mainframe, jak np. Resource Access Control Facility (RACF) firmy IBM, lub CA – Top Secret firmy Computer Associates.

Pełna zdolność do SSO jest już obsługiwana w jednorodnym środowisku Microsoftu (patrz rysunek 23.2), składającym się wyłącznie z systemów Windows 2000 Server i Professional oraz większości aplikacji BackOffice (inaczej .NET Enterprise Servers). Jednakże nie powinno to zaskakiwać, gdy wiemy o ścisłej integracji dostępnej już we wcześniejszych aplikacjach serwerowych Microsoftu i systemie operacyjnym Windows NT 4 Server.

Rysunek 23.2

Aby uzyskać dostęp do zestawu wszystkich aplikacji serwerowych Microsoftu będzie oczywiście potrzebne tylko jedno logowanie

Znacznie ważniejsze powinny być zamierzenia Microsoftu dotyczące wprowadzenia SSO w sieciach składających się z platform różnych producentów. Elastyczność ta ma być osiągnięta przez obsługę opartych na standardach protokołów uwierzytelniania, oraz za pomocą służących do połączeń między systemami produktów Microsoftu, dostosowanych do opcji i wyzwań większości najpopularniejszych platform systemowych innych producentów.

Mówiąc dokładniej, Windows 2000 Server z Active Directory udostępnia oparty na standardach pojedynczy podpis w sieciach niejednorodnych, dzięki wbudowanej implementacji protokołów Kerberos i SSL. Lecz znowu jest to tylko fragment całego obrazu: jak wspomniano w poprzednim podrozdziale, ostatecznym celem Microsoftu jest uczynienie z Active Directory najlepszego narzędzia wybieranego do roli punktu wymiany w dużych, wieloplatformowych środowiskach. Wobec tego Microsoft dąży do scenariusza w niedalekiej przyszłości, w którym cała linia produktów Microsoftu nie tylko pozwoli klientom typu przedsiębiorstw rozszerzyć korzyści z SSO na całą swoją sieć, lecz również pozwoli ustanowić Active Directory jako jedną z najlepszych platform pośredniczących za pomocą MMS pomiędzy zasadniczo odmiennymi systemami. Ponownie omawiając swoje wsparcie dla obsługi SSO w sieciach mieszanych Microsoft zakłada, iż usługa Active Directory będzie obecna i używana w centrum firmy (patrz rysunek 23.3).

Rysunek 23.3

Microsoft w ten sposób wyobraża sobie udostępnienie pojedynczego podpisu (Single Sign-On) we współpracy z innymi systemami operacyjnymi

SSO za pomocą Kerberosa

Protokół Kerberos opiera się na idei biletów — pakietów zaszyfrowanych danych, wydawanych przez zaufany autorytet o nazwie Centrum dystrybucji kluczy (KDC – Key Distribution Center). Bilet poręcza za tożsamość użytkownika i przenosi inne informacje (jak np. dane zabezpieczeń). KDC dostarcza bilety wszystkim użytkownikom w swoim obszarze pełnomocnictw (obszar — realm — jest poprawnym terminem Kerberosa). W systemie Windows 2000 Server każdy DC Active Directory jest KDC i każda domena stanowi jeden obszar.

Działanie protokołu Kerberos jest proste, jak widać z rysunku 23.4. Podczas logowania użytkownik uwierzytelnia się w KDC, które dostarcza użytkownikowi początkowy bilet (tzw. bilet przyznający bilety, TGT – Ticket Granting Ticket). Gdy użytkownik chce skontaktować się z zasobem sieciowym, jego sesja użytkownika przedstawia TGT w DC i żąda biletu dla określonego zasobu (ST – Service Ticket). Użytkownik prezentuje ST zasobowi

Brzydko brzmi.

, który wówczas zezwala użytkownikowi na dostęp.

Zastosowana przez Microsoft implementacja protokołu Kerberos w Windows 2000 jest w pełni zgodna ze specyfikacją Internet Engineering Task Force (IETF) dla Kerberosa v5 (RFC 1510). To z kolei pozwala domenom Active Directory współpracować bezpośrednio ze zgodnymi ze standardami implementacjami Kerberosa innych firm (jak np. TrustBroker firmy CyberSafe), pozwalając przez to na SSO pomiędzy Windows 2000 Server i sieciach wielu producentów, używających systemów operacyjnych MacOS, AIX, Digital Unix, HP-UX, IRIX, NetWare, Solaris, SunOS, Tandem i MVS/ESA (Multiple Virtual Storage/Enterprise System Architecture), pod warunkiem że również implementują obsługę Kerberosa w wersji 5.

Rysunek 23.4

Podstawowe działanie protokołu Kerberos – uwierzytelnianie użytkowników

Wskazówka

Dla współpracy Kerberosa dostępne są jedynie typy szyfrowania DES-CBC-MD5 i DES-CBC-CRC, zaś najbardziej powszechnym błędem w tej współpracy jest asymetria zegarów (uwierzytelnianie między obszarami Kerberosa może powieść się jedynie przy dokładnej synchronizacji zegarów systemowych — dopuszczalna jest różnica dwóch minut). Więcej informacji o funkcjonowaniu Kerberosa Czytelnik może znaleźć w rozdziale 14.

Ustanowienie relacji zaufania między Windows 2000 Server i innymi platformami za pomocą Kerberosa jest całkiem proste. Administrator tworzy relację zaufania pomiędzy KDC w różnych obszarach i dla odnośników pomiędzy obszarami udostępnione zostają bilety. Administrator Windows 2000 Server tworzy konto użytkownika, na które odwzorowani będą użytkownicy z drugiego systemu. Po dokonaniu tego prawa i przywileje zewnętrznych użytkowników są zarządzane przez konta użytkowników Active Directory, za pomocą tych samych narzędzi administracyjnych, które stosowane są dla macierzystych użytkowników Active Directory.

Odnośniki pomiędzy obszarami w środowisku niejednorodnym są podobne jak w jednorodnych sieciach Windows 2000 Server (zwane również zaufaniami – trusts). Gdy użytkownik w drugim systemie potrzebuje dostępu do zasobu sieciowego w domenie Windows 2000 Server, jego sesja użytkownika żąda biletu do zasobu. KDC, widząc że zasób mieści się w domenie Active Directory, odsyła użytkownika do DC Active Directory i poręcza za tożsamość użytkownika. DC Active Directory następnie przypisuje tożsamość użytkownika do odpowiadającego mu konta i wydaje użytkownikowi bilet, który ten następnie przedstawia w zasobie. Dla użytkowników Windows 2000 Server, którzy chcą skorzystać z zasobu w innym systemie, proces zachodzi w odwrotnej kolejności, aczkolwiek procedury administracyjne używane w drugim systemie mogą być różne.

Praca w niejednorodnym środowisku powoduje nieuniknioną utratę prostoty zarządzania, ponieważ pewne czynności administracyjne, które zachodziły w Windows 2000 Server w sposób niewidoczny, muszą być wykonane ręcznie przy łączeniu z sieciami niejednorodnymi. Na przykład, w przeciwieństwie do Windows 2000 Server, przy nawiązaniu zaufania w środowisku niejednorodnym administrator musi ręcznie synchronizować klucze pomiędzy DC Active Directory i KDC drugiego systemu. Podobnie, administrator traci korzyści z posiadania pojedynczego zestawu narzędzi administracyjnych i pojedynczego magazynu danych związanych z SSO. Zamiast tego, w najlepszym przypadku pojedynczy zestaw narzędzi i pojedynczy magazyn informacji związanych z SSO istnieje dla każdej platformy. Jednakże zdolność do bezpośredniego udostępniania zasobów stanowi oczywiście zysk dla klientów firmy i często jest warta dodatkowych nakładów pracy administracyjnej.

SSO za pomocą kluczy publicznych

Obecnie nie wszyscy użytkownicy komputerów przedsiębiorstwa korzystają z wewnętrznych połączeń w celu dostępu do sieci. Dzisiejsze środowiska komputerowe firm muszą w coraz większym stopniu obsługiwać użytkowników, którzy łączą się z siecią przedsiębiorstwa przez sieć publiczną (najczęściej Internet). Odpowiedzią SSO Microsoftu na te potrzeby jest protokół zabezpieczeń SSL (Secure Sockets Layer).

SSL jest w stanie używać cyfrowych certyfikatów jako podstawy uwierzytelniania. Zdecydowanie zalecam użycie tej opcji, ponieważ cyfrowy certyfikat jest obecnie jedynym stosunkowo bezpiecznym i opierającym się na standardach dostępnym dowodem tożsamości. Certyfikat cyfrowy to zabezpieczony przed manipulacjami pakiet danych wydany przez Urząd certyfikacji (CA – Certificate Authority). CA udostępnia klucz publiczny i poręcza za fakt, iż wymieniona osoba lub serwer jest właścicielem klucza publicznego. W trybie używanym przez SSO klient i serwer WWW wymieniają certyfikaty, a następnie używają zawartych w nich kluczy publicznych do wymiany informacji, jak np. kluczy szyfrujących sesji. Pozwala to uwierzytelnić obu użytkowników, ponieważ jeśli którykolwiek z nich nie jest faktyczną tożsamością wymienioną w przedstawionym przez siebie certyfikacie, wówczas nie będzie w stanie odszyfrować danych wysłanych przez drugą stronę.

Wszystkie składniki potrzebne aby udostępnić SSO za pomocą SSL są zawarte w systemie Windows 2000 Server i w pełni zintegrowane z architekturą zabezpieczeń Windows 2000 Server. Do zarządzania cyfrowymi certyfikatami służy infrastruktura kluczy publicznych Windows 2000 Server (PKI – Public Key Infrastructure), która zawiera dwa składniki:

·         Usługi certyfikatów — pozwalają administratorom wydawać i wycofywać certyfikaty.

·         Active Directory — udostępnia położenie CA i informacje o zasadach, oraz umożliwia publikację informacji o wycofanych certyfikatach.

Bazujący na SSL pojedynczy podpis Microsoftu jest w pełni znormalizowany, więc powinien współpracować z innymi produktami zgodnymi ze standardem. Obsługuje on SSL v3, najpowszechniej używaną wersję protokołu SSL, która została zgłoszona do IETF pod nazwą protokołu Transport Level Security (TLS). Microsoft Internet Explorer, Netscape Communicator i większość pozostałych przeglądarek WWW obsługuje ten standard i aktywnie wspiera przyjęcie TLS przez IETF.

PKI systemu Windows 2000 Server obsługuje certyfikaty cyfrowe używające standardu ISO X.509 v3, który jest niemal powszechnym standardem certyfikatów cyfrowych. Pozwala, na przykład, systemowi Windows 2000 Server korzystać z certyfikatów cyfrowych wydanych przez VeriSign, Thawte, BelSign i większość dobrze znanych CA.

Administratorzy dysponują znaczącą elastycznością w konfigurowaniu użycia danych zabezpieczeń PKI w sieci na potrzeby własnych firm. Na przykład, poniższe decyzje to zaledwie kilka z możliwych:

·         Ustalić poprzez Internetowe usługi informacyjne (IIS), do czego dany certyfikat może być wykorzystany. Na przykład, certyfikaty mogą służyć jedynie do uwierzytelniania w serwerze WWW, lub służyć jako podstawa pełnego logowania w sieci.

·         Skojarzyć poszczególne certyfikaty z poszczególnymi kontami użytkowników lub ustalić, iż wszystkie certyfikaty pochodzące z określonego CA przypisane są do pojedynczego konta użytkownika Active Directory.

·         Pozwolić na użycie w firmie certyfikatów wydawanych przez zewnętrzny CA lub przez CA oparty na Windows 2000 w firmie.

Kontrolą dostępu można zarządzać łatwo i wydajnie ponieważ, mimo iż certyfikaty cyfrowe służą do początkowego uwierzytelnienia użytkownika, punktem kontrolnym dostępu do zasobów sieciowych pozostaje konto użytkownika. Po uwierzytelnieniu użytkownika Active Directory przypisuje certyfikat do odpowiedniego konta użytkownika i używa zwykłych poświadczeń zabezpieczeń użytkownika by ustalić, czy użytkownik ten ma prawo dostępu do określonych zasobów sieciowych. Eliminuje to potrzebę synchronizacji wielu kopii przywilejów użytkownika.

Bezpieczeństwo sesji jest całkiem wysokie, ponieważ szyfrowanie jest częścią implementacji protokołu SSL. Pozwala to określić w przedsiębiorstwie preferowany poziom szyfrowania dla dostępu do sieci przez WWW i ustalać ten poziom na początku sesji. Implementacja SSL w Windows 2000 Server istnieje w dwóch wersjach z powodu praw eksportowych USA: wersji na Amerykę Północną (128-bitowa) i wersji międzynarodowej (56-bitowej) do użytku poza Ameryką Północną. Wersja północnoamerykańska udostępnia 40-bitowe i 128-bitowe wersje kryptoalgorytmów RC2 i RC4; 512-, 768- i 1024-bitowe wersje RSA oraz 56-bitowe szyfrowanie DES (Data Encryption Standard). Wersja międzynarodowa udostępnia 40-bitowe RC2 i RC4 oraz 512-bitowe szyfrowanie RSA. Z powodu złagodzenia praw eksportowych USA, pozwalających obecnie wszystkim za wyjątkiem kilku krajów objętych embargiem na dostęp do szyfrowania na poziomie komercyjnym, większość firm może obecnie przejść do wersji północnoamerykańskiej przez uzyskanie (lub pobranie z WWW) Windows 2000 High Encryption Pack od Microsoftu.

SSO za pomocą Host Integration Server

Jeśli nie dysponujemy żadnym sposobem dosięgnięcia zamierzonych klientów za pomocą protokołów SSL lub Kerberos, w ostateczności możemy posłużyć się Microsoft Host Integration Server 2000 (dawniej znanym pod nazwą SNA Server). Podobnie jak jego poprzednik, Host Integration Server 2000 pracuje w połączeniu z niektórymi z wiodących protokołów zabezpieczeń hostów, zaimplementowanych przez RACF, ACF2 i CA-Top Secret, aby udostępnić SSO pomiędzy sieciami bazującymi na Windows NT Server i Windows 2000 Server a środowiskami komputerów głównych MVS/ESA.

W przypadku SNA Server, pojedynczy podpis w systemie zabezpieczeń MVS był uzyskiwany przez zainstalowanie własnego rozwiązania SecurPass firmy Proginet w odpowiednich komputerach głównych, ponieważ SNA Server był dostarczany razem z SecurPass firmy Proginet i te dwa produkty współpracowały ze sobą w duecie. Dla synchronizacji haseł z AS/400 trzeba było zwrócić się do firmy Open Universal Software, która sprzedaje dostawcę zabezpieczeń niezbędnego do obsługi OS/400 V2R3 i starszych.

SecurPass udostępnia usługi synchronizacji haseł, które zapewniają identyczność poświadczeń zabezpieczeń użytkownika w obu systemach (czyli synchronizację dwukierunkową haseł). SecurPass wykonuje również uzgadnianie haseł (password harmonization) — przy zmianie hasła użytkownika w jednym systemie, sprawdzane jest z regułami haseł w obu systemach przed akceptacją. Zapewnia to wybór do roli ogólnych zasad haseł zasad silniejszych z pary Windows NT i IBM, oraz zabezpiecza przed zagrożeniem jednego systemu przez słabe hasła z drugiego.

Taka synchronizacja haseł pozwala SNA Server dokonywać wypełniania haseł — to znaczy, gdy dostawca zabezpieczeń systemu mainframe żąda uwierzytelnienia, SNA Server dostarcza hasło użytkownika Windows NT (które jest dzięki synchronizacji identyczne z hasłem użytkownika w systemie mainframe) przez automatyczne logowanie 3270 lub 5250

Nie wiem, czym się to je.

.

W systemie Host Integration Server 2000 Microsoft zdecydował się zaimplementować własne SSO (przez co program SecurPass stał się zbędny) dla systemów zabezpieczeń komputerów głównych RACF, ACF/2 i Top Secret. Jednakże Host Integration Server 2000 pozwala jedynie na prostą jednokierunkową synchronizację haseł z Active Directory do środowiska komputera głównego. Aby uzyskać dwukierunkową synchronizację haseł trzeba poszukać rozwiązań innych producentów — niestety, o ile wiem obecnie nie są dostępne żadne tego typu produkty.

Cel nr 2: ściślejsza integracja

Chociaż SSO udostępnia pewne znaczące polepszenie sytuacji, jest to tylko mały (i stosunkowo prosty) składnik przekształcania Active Directory w dojrzały meta-katalog (czyli katalog, który funkcjonuje jako punkt integracji wszystkich katalogów przedsiębiorstwa)

Naprawdę trudną częścią transformacji Active Directory w meta-katalog jest udostępnienie jakiegoś sposobu odwzorowania głównych obiektów — poza kontami użytkowników obsługiwanymi przez SSO — pomiędzy Active Directory i wieloma różnymi dostępnymi katalogami (zarówno systemów operacyjnych jak aplikacji). Takie zdolności do synchronizacji katalogów są ważne dla Microsoftu, ponieważ pozwoliłyby firmom skoncentrować się na Active Directory w roli centrum dowodzenia dla składowania i zarządzania informacji, a następnie automatycznie propagować podzbiory informacji na zewnątrz do innych katalogów.

Wysoce zachwalane zdolności synchronizacji Active Directory będą dostępne w kilku formach. Z perspektywy standardów Microsoft współpracuje z innymi producentami aby zapewnić obecność obsługi synchronizacji w specyfikacji LDAP — i Microsoft poprzysiągł przejść szybko na synchronizację LDAP po jej udostępnieniu. Warto jednak zauważyć, iż nazwa Microsoft jest podejrzanie nieobecna w większości dokumentów szkiców IETF w obszarze poprawy możliwości współpracy protokołu LDAP. Wobec tego nie jestem już tak przekonany, czy Microsoft spełni te obietnice — czy też firma do tego stopnia odwróciła uwagę w stronę MMS, że traktuje LDAP jako jedynie jeden z wielu różnych katalogów. Jak już wspomniano, Microsoft jest przygotowany do przeniesienia produktu MMS do głównego nurtu w roku 2001 lub 2002, pakując MMS „do pudełka” — przypuszczalnie z kolejną główną edycją Windows 2000 Server o nazwie kodowej Blackcomb. Lecz do tego czasu przypuszczalnie MMS nie będzie zbyt intensywnie promowany, o ile Microsoft nie poczuje na to nacisku, ponieważ potrzeba sporo pracy zanim można będzie określić MMS integralną częścią Active Directory — to znaczy, o ile Czytelnik nie należy do Fortune 1000

Warto by skomentować

i nie ma pilnych potrzeb ścisłej integracji z kilkoma różnymi aplikacjami.

Lecz LDAP nie zniknie zbyt szybko. Wręcz przeciwnie: MMS mocno opiera się na protokole LDAP i Microsoft najwyraźniej polubił możliwość chwalenia się zgodnością ze standardami przemysłowymi. Wobec tego implementacja jakiegokolwiek typu rozwiązań współpracy i usług katalogowych opartych na LDAP w dowolnej infrastrukturze Active Directory powinno być bezpieczne.

MS DirSync

...