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



Pobieranie 134.08 Kb.
Strona3/3
Data02.05.2016
Rozmiar134.08 Kb.
1   2   3

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


W najbliższym czasie Microsoft planuje dostarczyć z Active Directory usługę synchronizacji o nazwie MS DirSync, w postaci „łączników synchronizacji”. MS DirSync jest wersją do ogólnego zastosowania udostępnionej przez Active Directory Connector (ADC) funkcjonalności replikacji. ADC umożliwia integrację pomiędzy usługami katalogowymi Exchange Server 4.x i 5.x oraz Active Directory (bardzo dokładny opis ADC można znaleźć w rozdziale 15.).

Pierwszym zadaniem MS DirSync było udostępnienie:



  • Synchronizacji katalogu z Active Directory do katalogu docelowego (zazwyczaj synchronizacji jednokierunkowej z powodów konkurencyjności).

  • Pojedynczego punktu administracji (zaimplementowanego w postaci przystawki MMC) dla codziennych zadań związanych z użytkownikami.

  • Mniejszej zależności od wtórnych narzędzi przy wykonywaniu częstych zadań administracyjnych w drugim katalogu

Pierwsza (i aktualna) wersja MS DirSync (patrz rysunek 23.5) zawiera funkcjonalność synchronizacji opartej na sesjach, obsługującą wielokrotne cele (np. drzewa), definiowanie harmonogramów i odwzorowania wszelkich niezbędnych klas i atrybutów. Ściśle mówiąc, znajdziemy tu funkcjonalność pozwalającą dokonywać odwzorowania przestrzeni nazw, odwzorowania klas i atrybutów oraz odwzorowania praw i uprawnień. Ponadto przy każdym dodaniu, usunięciu lub modyfikacji obiektu w usłudze katalogowej występują zdarzenia zmian. Z bardziej ogólnego punktu widzenia, projekt kontroli DirSync Microsoftu stanowi postęp technik synchronizacji katalogów w następujących dziedzinach:

  • Obsługa przechwytywania zmian na poziomie atrybutów, pozwalająca wykonawcom tworzyć wysokowydajne połączenia między katalogami, wymagające niskiego pasma przepustowości.

  • Natychmiastowa zgodność z konstrukcją większości replikowanych usług katalogowych.

  • Wydajna resynchronizacja po awariach serwera.

  • Optymalne wykorzystanie inwestycji w LDAP.

Rysunek 23.5

Architektura MS DirSync



Session database

Baza danych sesji

Directory Synchronization Server

Serwer synchronizacji katalogu

DirSync Session Manager

Menedżer sesji DirSync

Object Mapper

Maper obiektów

DirSync provider for Active Directory

Dostawca DirSync dla Active Directory

DirSync provider for other directory

Dostawca DirSync dla innych katalogó

another directory

Inny katalog

W marcu 1999 Microsoft posunął się do opublikowania specyfikacji MS DirSync jako zgłoszenia internetowego memorandum IETF poza ścieżką standardów, co było posunięciem pomyślanym by wzbudzić zainteresowanie tym opartym na LDAP sposobem kontroli wśród stron trzecich. jednakże posunięcie Microsoftu nie zaimponowało zbytnio społeczności LDAP, zaś nabycie Zoomit Corporation przez Microsoft kilka miesięcy później spowodowało, iż nawet gorący stronnicy Microsoftu stali się niechętni do tworzenia czegokolwiek w oparciu o MS DirSync.

Jest to chyba mądra decyzja, ponieważ jak dotąd Microsoft nie dostarczył niczego poza ADC i bazującym na MS DirSync łączniku z NDS, mimo deklaracji, iż MS DirSync jest jedną z technologii nie wykorzystanych w pełni w terminie wydania Windows 2000 Server z powodu ograniczeń czasowych — budzących oczekiwania, iż powinniśmy spodziewać się ze strony Microsoftu wielu nowych postępów związanych z MS DirSync wkrótce po wydaniu Windows 2000 Server, zarówno pod względem obsługiwanych platform, jak zakresu synchronizacji. Podobnie błędne okazały się oczekiwania Microsoftu, iż kilka innych firm w roku 2000 opracuje łączniki synchronizacji oparte na DirSync oraz obsługę katalogów nie używających LDAP za pomocą interfejsów typu ADSI.


Obecny stan rzeczy


Chociaż MMS sprawia zdecydowanie wrażenie produktu wybranego przez Microsoft na przyszłość, nie należy jak na razie marnować na niego zbyt wiele czasu, jeśli potrzebny jest podstawowy poziom integracji katalogów z jednym lub dwoma systemami operacyjnymi. MMS dopiero pojawił się w ramach Active Directory; umiejętności wymagane dla tego produktu są bardzo rzadko spotykane (a przez to kosztowne) i prawdopodobieństwo zastania sporych zmian w produkcie po dalszej integracji z Active Directory jest dość wysokie. Ponadto MMS zasadniczo znacznie lepiej nadaje się do integracji katalogów z aplikacjami ni pomiędzy różnymi systemami operacyjnymi. Wobec tego zastosowanie MMS będzie miało naprawdę sens tylko w przypadku natychmiastowej potrzeby bardzo złożonej lub zaawansowanej integracji w bardzo dużym środowisku firmy. Z drugiej strony należy pamiętać, że lepiej zapomnieć o MS DirSync dla wszelkich rozwiązań poza krótkoterminowymi.

Wobec tego, o ile nie jesteśmy w szczęśliwej pozycji pozwalającej wykorzystać istniejące implementacje Kerberosa lub coś w tym stylu, pozostaje wybór pomiędzy przyszłością a przeszłością. Kierunek, w którym pójdziemy, zależy od sporej liczby różnych parametrów — lecz niezbędne będzie zdecydowanie wykorzystanie szarych komórek. W większości przypadków koncentracja na innych narzędziach integracji i migracji dostarczanych przez Microsoft dla różnych popularnych systemów operacyjnych powinno być ćwiczeniem o wiele bardziej praktycznym i interesującym. Wobec tego następne podrozdziały obejmują przegląd różnych narzędzi Microsoftu przeznaczonych do integracji i migracji.

Chociaż zawartych zostało tutaj trochę wiadomości o narzędziach i usługach dostarczanych przez innych producentów (zwykle takich, którzy zawarli strategiczne partnerstwo z Microsoftem), nie jest to absolutnie pełna prezentacja opcji dostępnych na rynku. Zachęcam więc by rozejrzeć się wśród licznych ofert innych producentów, zwłaszcza jeśli potrzeby Czytelnika wykraczają poza to, co zostało tu omówione — szanse znalezienia potrzebnych narzędzi powinny rosnąć z dnia na dzień.

Novell NetWare – współpraca i migracja


Podstawowy zestaw opcji Windows 2000 Server zawiera te same składniki służące do współpracy jak dla systemu Windows NT 4 Server prosto z pudełka. Do składników tych należą:

  • NWLink — protokół sieciowy zgodny z IPX/SPX, w pełni zgodny z własnym protokołem Novella IPX/SPX, co z kolei pozwala dodać Windows 2000 Server do sieci opartych na NetWare 2.x, 3.x i NDS bez konieczności modyfikacji w innych serwerach lub klientach i umożliwia komunikację klientów Windows 2000 Professional z serwerami NetWare.

  • Client Services for NetWare (CSNW) — zgodny z Novellem klient, pozwalający klientom Windows 2000 Professional korzystać z plików i drukarek w serwerach Novell NetWare 3.x i NDS za pomocą pojedynczego logowania do Windows 2000 Server i NetWare. Jeśli jednak jest to potrzebne, zdecydowanie zalecam uzyskanie lepszego klienta bezpośrednio od Novella. CSNW zawiera jedynie cząstkę funkcjonalności własnych klientów NetWare dla Windows 2000.

  • Gateway Services for NetWare (GSNW) — brama do Novella pozwalająca klientom na dostęp do zasobów NetWare bazujących na IPX/SPX (zarówno bindery jak NDS) z serwera Windows 2000 Server służącego w roli bramy. W ten sposób można ominąć techniczne wymogi instalowania oprogramowania klienckiego NetWare i stosu protokołu IPX/SPX w klientach. Jednakże funkcjonalność bramy stanowi też kompromis z bezpieczeństwem, ponieważ wszystkie klienty ze środowiska Microsoftu są zarządzane jedynie przez zabezpieczenia Windows, więc można skonfigurować jedynie zabezpieczenia na poziomie udziałów — nie na poziomie użytkowników — dla plików i drukarek pochodzących z zasobów NetWare.

  • Active Directory Service Interface (ADSI) — umożliwia łatwe sprzęganie z Novell NDS i bindery (przez emulację NetWare 2.x, 3.x i NDS bindery) pod względem automatyzacji często wykonywanych zadań za pomocą skryptów i innych sposobów programowania.

Dodatkowo Microsoft oferuje inny zestaw narzędzi — nazwany Services for NetWare (SFN) w wersji 5 — przeznaczony do ułatwienia współpracy i migracji z NetWare do Active Directory. SFN pozwala firmom dokonać migracji serwerów NetWare bindery (NetWare 2.x, 3.x i ewentualnie 4.x i 5.x) i (lub) NDS (NetWare 4.x i 5.x) do Active Directory w sposób półautomatyczny, jak również zoptymalizować ich współistnienie.

Wskazówka

Services for NetWare 5.0 nie są darmowe — lecz jest to bardzo tani produkt z licencją kliencką na klienta i serwer.

Services for NetWare zawierają trzy główne narzędzia:



  • Microsoft Directory Synchronization Services (MSDSS) — dwukierunkowo synchronizuje informacje składowane w usłudze Active Directory i informacje składowane w bindery NDS lub NetWare 3.x.

  • File Migration Utility (FMU) — migruje pliki NetWare do Windows 2000, zachowując uprawnienia kontroli dostępu.

  • File and Print Services for NetWare (FPNW) — pozwala serwerowi Windows 2000 emulować serwer plików i drukowania dla użytkowników, klientów i administratorów.

Warto zauważyć, że Services for NetWare zawierają także poniższe narzędzia, które były dostępne w poprzednich wersjach produktu:

  • File and Print Services for NetWare version 4 (FPNW4) — FPNW4 działa dokładnie jak FPNW. Usługa ta po prostu została utworzona dla Windows NT 4 Server zamiast Windows 2000 Server.

  • Directory Service Manager for NetWare (DSMNW) — pozwala zarządzać NetWare 2.x i 3.x bindery z Windows NT 4 Server. DSMNW kopiuje konta użytkowników NetWare do SAM, a następnie propaguje wszelkie zmiany z powrotem do bindery serwera NetWare. Pozwala to, na przykład, scalić zarządzanie serwerami NetWare w jednym miejscu.

Usługa File and Print Services for NetWare pomaga firmie wykorzystać umiejętności pracowników z NetWare, udostępniając interfejs użytkownika NetWare 3.12 w serwerze Windows 2000. Mimo korzystania z serwera Windows 2000 dla usług plików i drukowania, administratorzy będą w stanie korzystać z niego za pomocą dobrze znanego interfejsu użytkownika NetWare. Ponadto zachowane zostaje pojedyncze logowanie klientów bez potrzeby zmian w konfiguracji klientów.

Krótko mówiąc, File and Print Services for NetWare pozwalają na emulację przez Windows 2000 Server serwera plików i drukowania zgodnego z NetWare 3.12. Może to być całkiem przydatne, ponieważ będziemy w stanie zastąpić serwer plików i drukowania NetWare serwerem plików i drukowania Windows 2000 bez powodowania jakichkolwiek zmian dla użytkowników i administratorów — jeśli nie uświadomi się im zmiany, wciąż będą wierzyć, iż używają NetWare.

File Migration Utility działa podobnie. Za pomocą File Migration Utility można zmniejszyć wyzwania związane z migracją plików z platformy NetWare do Windows 2000 Server (a co za tym idzie, poświęcony czas). File Migration Service nie tylko pozwala wyznaczyć grupę plików przeznaczonych do skopiowania do jednego lub wielu „docelowych” serwerów Windows 2000 — zachowuje również historię zmian plików, co pozwoli dokonać migracji w dowolnym tempie — i zapewni zachowanie praw i uprawnień związanych z każdym plikiem w procesie migracji.

Wskazówka

Aby dokonać migracji uprawnień z systemu plików, należy migrować użytkowników przed systemem plików. To znaczy, aby móc migrować pliki razem z prawami dostępu, trzeba użyć Microsoft Directory Synchronization Services w celu migracji katalogu NDS lub obiektów bindery do Active Directory, zaznaczając opcjonalne pole wyboru Migrate Files, ponieważ dzięki temu tworzony jest dziennik migracji, używany przez File Migration Utility. Następnie można wykorzystać File Migration Utility aby przenieść pliki i prawa dostępu do nich do udziały NTFS Windows 2000 (system plików NTFS jest niezbędny, aby nie utracić praw i uprawnień do plików).

File Migration Utility obsługuje zarówno protokół TCP/IP jak IPX/SPX, aby zapewnić gładką migrację plików NetWare i ich uprawnień z najbardziej popularnych wersji NetWare.



Produkt Microsoft Directory Synchronization Services udostępnia następującą funkcjonalność:

  • Jednokierunkowa synchronizacja z Active Directory do Novell NDS lub bindery przez okresowe ściąganie i wypychanie — ta funkcjonalność pozwala zarządzać obiektami w katalogach Novella z Active Directory. Synchronizacja jest przyrostowa i działa na poziomie atrybutów (to znaczy, zmienione obiekty są odczytywane z Active Directory i tylko zmodyfikowane atrybuty są zapisywane w NDS lub bindery). Jednokierunkowa synchronizacja nie wymaga zmian schematu w NDS.

  • Dwukierunkowa synchronizacja Active Directory i NDS przez okresowe ściąganie i wypychanie — ta funkcjonalność pozwala na zarządzanie u wspólnymi danymi, jak np. informacjami o koncie użytkownika, z każdego katalogu. Podczas gdy synchronizacja z Active Directory do NDS działa na poziomie atrybutów, synchronizacja w przeciwnym kierunku zachodzi na poziomie obiektów (to znaczy, wszystkie obiekty zostają odczytane z NDS, obiekty niezmienione zostają odfiltrowane i jedynie obiekty zmodyfikowane zostają zapisane w Active Directory). Opcja synchronizacji dwukierunkowej wymaga rozszerzenia schematu NDS, aby oznaczyć wszystkie interesujące obiekty (konta użytkowników, konta grup i OU) globalnie unikatowymi identyfikatorami (GUID).

  • Synchronizacja do NDS może być ograniczona do określonych domen lub OU Active Directory — synchronizacja do bindery może objąć na przykład tylko pojedynczy poziom OU.

  • Synchronizacja obejmuje konta użytkowników, konta grup, listy dystrybucyjne i OU z obsługą wszystkich obiektów dodanych, usuniętych, przemianowanych, przeniesionych i zmodyfikowanych — chociaż obsługiwane są najważniejsze obiekty katalogowe, wciąż brakuje sporej liczby typów obiektów, które mogą być niezbędne dla uzyskania zadowalającego poziomu współpracy — w tym kont komputerów, obiektów drukarek i aplikacji. Ponadto tylko najbardziej typowe atrybuty (nie obejmujące uprawnień) przenoszone są pomiędzy platformami.

  • Pojedynczy podpis — pozwala zaimplementować pojedynczy podpis pomiędzy Novell NetWare i Active Directory. Jednakże nie za darmo. Ponieważ hasła składowane są w katalogach systemów operacyjnych Windows i Novell w różnych formatach (i zaszyfrowane innymi metodami), MSDSS nie jest w stanie pobrać zaszyfrowanych haseł zapisanych w katalogu NDS lub bindery w chwili implementacji. Wobec tego MSDSS musi utworzyć nowe hasła (które mogą być zgodne z różnymi schematami generowania haseł) dla każdego użytkownika migrowanego do Active Directory, lub którego konto ma być synchronizowane pomiędzy Active Directory i NetWare. Po pierwszej zmianie hasła MSDSS może być poinstruowany by utrzymywał synchronizację haseł pomiędzy dwoma platformami, zapewniając tak pożądaną funkcjonalność pojedynczego podpisu. Jednakże pojedynczy podpis jest dostępny tylko jeśli użytkownicy zmieniają swoje hasła z klientów łączących się z Active Directory (to znaczy, hasła można tylko przekazać do Novella, nigdy w przeciwnym kierunku).

  • Synchronizacje według harmonogramu oraz ręczne — dzięki temu MSDSS nadaje się równie dobrze do scenariuszy migracji jak współistnienia.

MSDSS obsługuje wszystkie wersja NDS Novella (dokładnie mówiąc, NDS for Novell NetWare 4.0, 4.1, 4.11, 4.2, 5.0, 5.1 i 5.0 z NDS 8) oraz NetWare 3.x bindery (dla Novell NetWare 3.1x i 3.2). MSDSS nie wprowadza żadnych składników, które trzeba instalować w serwerach NetWare i jest w stanie obsłużyć wiele drzew NDS i bindery.

Wskazówka

MSDSS bazuje na technologii MS DirSync omówionej wcześniej w tym rozdziale. Produkt ten używa własnego klienta Novella — czyli Novell Client Access, inaczej Novell Client lub Client32 — i obsługuje wszystkie protokoły obsługiwane przez tego klienta, w tym IPX/SPX i TCP/IP.

Chociaż więc migracja obejmuje konta użytkowników, konta grup, pliki i uprawnienia z praktyczne dowolnego serwera NetWare do Active Directory, trzeba poradzić sobie samemu z:



  • Skryptami logowania i szablonami NDS (chociaż można migrować skrypty logowania bindery za pomocą File and Print Services for NetWare Microsoftu).

  • Zasadami ZENworks.

  • Aplikacjami (NLM serwera i NAL klienta).

  • Rozszerzeniami schematu.

  • Przestrzenią nazw systemu Macintosh.

  • Kontami komputerów, drukarkami i innymi urządzeniami sprzętowymi.

  • Dziedziczeniem uprawnień do obiektów w NDS — to znaczy, jeśli OU używane są w roli wystawców zabezpieczeń lub używana jest równoważność zabezpieczeń — w scenariuszu współistnienia.

Jak to działa?

Synchronizacja zachodząca pomiędzy Novell NetWare i Active Directory jest ustawiana przez definiowanie sesji synchronizacji. Sesja synchronizacji wymagana jest dla każdego skojarzenia pomiędzy OU Active Directory i kontenerem (poddrzewem) NetWare. Każdy serwer z Microsoft Directory Synchronization Services obsługuje do 50 sesji.

Migracja MSDSS tworzy strukturę obiektów Active Directory, odzwierciedlającą strukturę NDS lub bindery. Tutaj obiekty użytkowników, grup i list dystrybucyjnych NetWare są odwzorowywane odpowiednio na użytkowników, grupy i grupy Active Directory, natomiast kontenery Novella są odwzorowywane na OU Active Directory.

Ponieważ jednak Active Directory nie obsługuje kontenerów porównywalnych do organizacji w NDS — i ponieważ Active Directory nie pozwala korzystać z OU jako wystawców zabezpieczeń (to znaczy, nie pozwala przyznawać praw i uprawnień za pomocą OU), MSDSS w trybie migracji tworzy lokalne grupy zabezpieczeń domeny odpowiadające każdej OU i organizacji NDS. Następnie MSDSS odwzorowuje zawartość każdej OU lub organizacji Novella na odpowiadającą lokalną grupę zabezpieczeń domeny Active Directory.



Mam nadzieję, że ten podrozdział dał dobry wgląd w opcje współpracy i migracji dostępne w produktach Microsoftu. Podsumowanie dostępnych usług migracyjnych można znaleźć w tabeli 23.1. Oczywiście wszystkie składniki nie wymienione w tej tabeli muszą być przenoszone ręcznie lub za pomocą narzędzi innych producentów.

Tabela 23.1

Podsumowanie usług migracyjnych udostępnionych przez zestaw narzędzi Microsoftu

Składnik NetWare

Obsługiwane wersje NetWare

Narzędzie

Pliki

NetWare 3.x, 4.x i 5.x

File and Print Services for NetWare

Informacje katalogowe

NetWare 3.x, 4.x, 5.x i NDS 8

Microsoft Directory Synchronization Services

Serwery plików i drukowania

NetWare 3.12, 4.2 i 5.x

File and Print Services for NetWare. Wersja NetWare jest obsługiwana w pełni, natomiast NetWare 4.2 i 5.x częściowo (tylko bindery).

Aplikacje i NLM

Żadna

Niedostępne

Warto w podsumowaniu zauważyć, iż szybka, pełna, jednorazowa migracja często jest lepszym wyborem od wszelkich innych dla małej lub średniej organizacji. która nie zainstalowała jeszcze żadnych aplikacji zależnych od usługi NDS z powodów ograniczeń zdolności NDS do współpracy. W złożonym lub dużym środowisku NDS trzeba będzie przypuszczalnie dokonać stopniowej migracji, co może okazać się dość trudne.

Znacznie większą swobodę wyboru mamy w traktowaniu organizacji używającej Novell NetWare 3.1x (lub nowszych wersji działających jedynie w trybie bindery); w tym przypadku ustawienia współpracy i migracji powinny być stosunkowo proste.


Unix: współpraca i migracja


Do niedawna obsługa współpracy z Uniksem ze strony Microsoftu była praktycznie zerowa. Jednakże pojawienie się produktu Windows Services for Unix ogromnie poprawiło tę sytuację.

Podstawowe zdolności współpracy zawarte w Windows Services for Unix v2 to:



  • Klient i serwer NFS — obsługa Network File System (NFS) v2 i 3. standardowego protokołu udostępniania plików w środowiskach uniksowych. Serwer NFS obsługuje PCNFSD (zgodną z PC wersję demona NFS), jak również rodzime uwierzytelnianie NFS. Dzięki temu klienty i serwery NFS obsługują uwierzytelnianie przez połączenie i uwierzytelnianie PCNFSD lub Network Information Service (NIS).

  • NFS gateway — udostępnia uniksowe eksporty NFS jako udziały plików NFS, co pozwala na dostęp wszelkich klientów Windows bez przeszkód do eksportów NFS.

  • Klient i serwer usługi Telnet — obsługa nowych typów terminali Telnet w porównaniu z emulatorem terminala wbudowanym w Windows NT i Windows 2000: VT100, ANSI i opracowany przez Microsoft VTNT. VTNT ma zostać opublikowany jako dokument RFC wspierany przez Microsoft i, nawiasem mówiąc, obsługuje także uwierzytelnianie NTLM.

  • Active State ActivePerl 5.6 — pozwala automatyzować zadania administracyjne przez uruchamianie nowych lub istniejących skryptów w języku Perl na platformach Windows NT i Windows 2000.

  • Uniksowe polecenia skryptowe — powłoka KORN Shell i 60 innych uniksowych programów binarnych, takich jak cat, grep, ls, touch czy tee.

  • Odwzorowanie nazw użytkowników — można tę opcję określić jako SSO dla NFS i NIS, ponieważ pozwala kojarzyć użytkowników i grupy z domeny Windows z uniksową domeną NIS lub serwerem PCNFS. Opcja odwzorowania użytkowników jest zwykle potrzebna, aby zaimplementować odpowiedni poziom zabezpieczeń dla udostępniania plików NFS między platformami. W przeciwnym razie użytkownicy muszą wprowadzać odrębne poświadczenia w celu dostępu do udziałów w innej platformie, lub trzeba obniżyć poziom zabezpieczeń.

  • Integracja domen NIS z Active Directory — opcja Server for NIS pozwala DC grać rolę podstawowego serwera NIS, pozwalając administratorom zarządzać domeną NIS z Active Directory. Za pomocą tej funkcji tworzy się wspólną przestrzeń nazw, co pozwala zarządzać uniksowymi grupami i użytkownikami w ten sam sposób (i za pomocą tego samego zestawu narzędzi) jak użytkownikami i grupami Windows. Ponadto uzyskujemy po drodze jednokierunkową synchronizację haseł (z Windows do Uniksa). Server for NIS implementuje protokół NIS 2.0 i obsługuje zarówno podporządkowane (subordinate) serwery NIS systemu Unix, jak klienty NIS bazujące na Uniksie. Przenosząc domeny NIS do Active Directory można wykorzystać kreatora NIS to Active Directory Migration Wizard; kreator ten pozwala przenosić źródłowe pliki z Uniksa (jak np. pliki haseł czy hostów) z istniejących domen NIS do Active Directory.

  • Dwukierunkowa synchronizacja haseł — opcja Password Synchronization daje możliwość synchronizacji zmian haseł w obu kierunkach (jak również jednokierunkową synchronizację haseł z Windows do Uniksa). Opcja Password Synchronization obsługuje synchronizację domen Windows NT i Active Directory oraz autonomicznych komputerów uniksowych, takich które używają /etc/passwd, jak również komputerów uniksowych używających NIS lub NIS+. Dla haseł w domenie, Password Synchronization należy zainstalować w DC Windows NT lub Windows 2000. Synchronizacja haseł stosuje się jedynie do użytkowników o takich samych nazwach w systemie Unix i Windows; ponadto obsługiwane platformy Unix to Solaris 2.6 i wyższe, HP-UP 10.3 i wyższe, IBM AIX 4.2 i wyższe (tylko jednokierunkowa synchronizacja z Windows do AIX), Digital Tru64 oraz Red Hat Linux 5.2 i nowsze.

Windows Services for Unix zasadniczo udostępniają niezły poziom funkcjonalności SSO, pełnowymiarowego klienta NFS pozwalającego Windows NT i Windows 2000 montować i korzystać z plików w systemie Unix i innych grających rolę serwerów NFS, oraz pełnowymiarową implementację NFS Server, która pozwala Uniksowi i innym klientom NFS montować i korzystać z plików mieszczących się w udziałach plikowych Windows NT Server i Windows 2000 Server.

Poza powyższymi opcjami integracji z Uniksem należy zauważyć, iż Windows 2000 Server jest z natury dość uniksowy, ponieważ między innymi opiera się na TCP/IP, DNS, DHCP (BOOTP) i Kerberosie. Z tych funkcji Kerberos przypuszczalnie stanowi najważniejszą zmianę dla wielu środowisk uniksowych.

Wskazówka

Rozdział 14. zawiera szczegółowe wprowadzenie do protokołu Kerberos.

Protokół Kerberos v5 jest już obecnie zaimplementowany w szeregu różnych systemów (w tym niemal we wszystkich odmianach Uniksa). Wobec tego, jak wspomniano w podrozdziale poświęconym SSO, wybór Kerberosa (opartego na protokole Kerberos v5 używającym formatu żetonu RFC 1510 i RFC 1964) przez Microsoft zdecydowanie udostępni wysoce poszukiwane możliwości współpracy między platformami pod względem uwierzytelniania, integralności (podpis i weryfikacja) i poufności (pieczętowanie i odpieczętowanie) komunikatów ze sporą liczbą platform systemu Unix.

Kerberos we współpracy stanowi wspólny protokół który, przynajmniej teoretycznie, pozwala zaimplementować pojedynczą (ewentualnie replikowaną) bazę danych kont dla uwierzytelniania użytkowników w różnych platformach systemów operacyjnych i umożliwić dostęp przez SSO do wszystkich usług w niejednorodnym środowisku. Zdolność do współpracy Kerberosa opiera się na następujących właściwościach:



  • Użycie wspólnego protokołu uwierzytelniania w połączeniu sieciowym do identyfikacji użytkowników końcowych i zasobów przez ich nazwy główne (principal name).

  • Zdolność do definiowania relacji zaufania pomiędzy obszarami Kerberosa i do generowania żądań odnośników biletów pomiędzy obszarami.

  • Implementacje obsługujące „Interoperability Requirements” (wymogi zdolności do współpracy) zdefiniowane w RFC 1510, dotyczące algorytmów szyfrowania i sum kontrolnych, wzajemnego uwierzytelniania i innych opcji biletów.

  • Obsługa formatów żetonu zabezpieczeń Kerberosa v5 służących do ustalania kontekstu i wymiany per-message zgodnie z definicją grupy roboczej Common Authentication Technology IETF w RFC 1964.

Wskazówka

Pomimo obstrzału, pod jaki Microsoft dostał się w prasie i pomiędzy purystami za wykorzystanie RFC 1964 do dodania informacji SID do Kerberosa, udowodniono zdolność Active Directory do współpracy ze sporą liczbą implementacji Kerberosa wiodących stron trzecich. Najważniejszą z nich jest przypuszczalnie TrustBroker firmy CyberSafe, która pozwoli na SSO pomiędzy Windows 2000 i sieciami używającymi systemów operacyjnych Mac, AIX, Digital Unix, HP-UX, IRIX, NetWare, Solaris, SunOS, Tandem i MVS/ESA.

Krążyło wiele pogłosek, iż implementacja Kerberosa w Windows 2000 zawiera mnóstwo niezgodności z czystym standardem Kerberosa. Jednakże pogłoski te ogromnie wyolbrzymiały fakty. Prawda, implementacja ta nie jest zgodna z DCE — to znaczy, z DCE Privilege Attribute Certificates (PAC) — ani z SESAME. Jednakże implementacja Kerberosa w Windows 2000 Server stosuje się do RFC 1964 – formatu żetonów Generic Security Services (GSS) Kerb5 Mechanism.

Problem ze współpracą koncentruje się na wykorzystaniu przez Windows 2000 opcji rozszerzeń protokołu Kerberos (zdefiniowanych w RFC 1964) do obsługi danych uwierzytelniania (co w przypadku Active Directory przede wszystkim oznacza SID-y użytkownika i grup). Problemy ze współpracą biorą się z faktu wykorzystania już opcji rozszerzeń w innych architekturach, w tym Distributed Computing Environment i SESAME.

Ten problem (za który należy winić raczej standardy a nie Microsoft) doprowadził do mnóstwa niejasności i krytykowania Microsoftu. Jednakże Czytelnik zapewne przyjmie z ulgą wiadomość, iż faktyczne problemy ze współpracą są dość ograniczone, ponieważ dane uwierzytelnienia Active Directory przenoszone w bilecie sesji Kerberosa są ignorowane przez większość implementacji uniksowych protokołu Kerberos.

Wskazówka

Aby poprawić współpracę pomiędzy implementacją Kerberosa w Windows 2000 Server i innymi implementacjami, Microsoft udostępnił publicznie swoje wykorzystanie pola danych uwierzytelnienia w bilecie sesji Kerberosa (obecnie można je znaleźć pod www.microsoft.com/technet/security/kerberos/default.asp).

Znacznie ważniejszym problemem jest fakt iż, z powodu podjętych przez Microsoft decyzji dotyczących implementacji (część z nich przypuszczalnie opiera się bardziej na strategii niż technologii), nie każdy typ interakcji pomiędzy obszarami Kerberosa jest obsługiwany. Co nie powinno zaskakiwać, wyborem dającym najwięcej możliwości współpracy jest umieszczenie KDC w systemie Windows 2000 Server (patrz rysunek 23.6); wówczas współpracować mogą:



  • Klienty uniksowe z serwerami uniksowymi.

  • Klienty uniksowe z serwerami korzystającymi z Active Directory.

  • Klienty korzystające z Active Directory z serwerami uniksowymi.

Rysunek 23.6

Preferowane jest wykorzystanie systemu Windows 2000 Server jako KDC



Application Protocol

Protokół aplikacji

Kerberos SSP

Protokół dostawcy zabezpieczeń Kerberos

Ticket

Bilet

GSS Kerberos mechanism

Mechanizm GSS Kerberosa

GSS-Kerb5 Token Formats (RFC 1964)

Formaty tokenu GSS-Kerb5 (RFC 1964)

Unix Server

Serwer uniksowy

Jeśli poszukujemy współpracy z istniejącymi serwerami Kerberosa bazującymi na systemie Unix (które, tak przy okazji, muszą opierać się na wersji MIT Kerberosa aby móc w ogóle działać), widoki są mniej obiecujące. Jeśli chcemy oprzeć infrastrukturę wyłącznie na KDC bazujących na implementacji MIT Kerberosa, konfiguracja Windows 2000 Professional jest ograniczona do współpracy z KDC (to znaczy, wykluczając po drodze zwyczajową ścisłą integrację z DC Active Directory). Ponadto jedynie aplikacje Windows 2000 akceptujące uwierzytelnienie oparte na nazwie (w przeciwieństwie do kontroli dostępu w stylu Windows 2000 Server) będą w stanie wykorzystać rozwiązanie bazujące na implementacji MIT Kerberosa.

Ponieważ uwierzytelnienie oparte na nazwie zazwyczaj nie wystarcza, najlepszą (i popieraną przez Microsoft) opcją jest utworzenie wieloplatformowego środowiska Kerberos, w którym Windows 2000 Server współpracuje z implementacją MIT Kerberosa za pomocą relacji zaufania między obszarami (patrz rysunek 23.7). W tym przypadku uniksowy KDC może grać rolę domeny kont, natomiast usługi oparte na Windows 2000 mieszczą się w domenie zasobów Windows 2000 (dzięki temu KDC Windows 2000 jest serwerem autoryzującym dla usług bazujących na Windows 2000). Inaczej mówiąc, klienty które otrzymały bilet TGT od KDC w systemach innych niż Windows 2000 będą w stanie skorzystać z mechanizmów odwołań Kerberosa, by zażądać biletu sesji od KDC w domenie Active Directory. Bilet odwołania jest tworzony przez międzyobszarowe relacje zaufania pomiędzy KDC.

Rysunek 23.7

Jeśli w konfiguracji Kerberosa musi znaleźć się jeden lub więcej KDC działających pod innymi systemami operacyjnymi niż Windows 2000 Server, należy zawsze umieścić serwery Windows 2000 w środowisku Windows 2000



Unix realm

Środowisko uniksowe

Windows 2000 realm

Środowisko Windows 2000

Ticket

Bilet

TGT Ticket

Bilet TGT

Unix Workstation

Uniksowa stacja robocza

Windows 2000 Auth. Data

Dane uwierzytelnienia Windows 2000

Name mapping to...

Odwzorowanie nazw na konta Windows 2000

Wobec tego w sytuacji między obszarami otrzymujemy w istocie ten sam zestaw opcji jak w projekcie korzystającym wyłącznie z Windows 2000 Server. Jednakże wymaga to dodatkowego wkładu pracy w zarządzanie, ponieważ trzeba zaimplementować odwzorowania nazw pomiędzy wystawcami zabezpieczeń w obszarze uniksowym i lustrzane lub pośredniczące konta użytkowników i ich przynależność do grup w Active Directory — w najgorszym przypadku trzeba będzie odwzorować każde konto w obszarze uniksowym na odpowiadające konto Active Directory, co jakby wyrównuje wiele przyczyn implementowania Kerberosa.

Unifikacja dostępu do plików za pomocą DFS

Zanim zabierzemy się za męczącą migrację posiadanych systemów plików do NTFS, powinniśmy zrobić sobie przysługę i rozważyć o wiele prostsze rozwiązanie – Rozproszony system plików (DFS), który stanowi składnik Windows 2000 Server.

DFS ułatwia znajdowanie i zarządzanie danych w sieci, jednocząc pliki w różnych komputerach w pojedynczą przestrzeń nazw. W ten sposób administratorzy systemów informacyjnych mogą utworzyć pojedynczy, hierarchiczny widok wielu serwerów plików i udziałów serwerów plików w sieci.

W wyniku oznacza to, że NTFS (Windows 2000 Server), system plików NetWare (Novell NetWare), NFS (Unix) i inne systemy można zjednoczyć we wspólną strukturę nazewniczą. Zarówno wewnętrzne jak zewnętrzne systemy plików, łącznie z plikami w Internecie, mogą być odwzorowanie na strukturę DFS tak długo, dopóki przekierowanie Windows 2000 (w postaci albo przekierowania klienta, albo jakiegoś typu serwerowej technologii bramy, jak Services for Unix) istnieje dla danego systemu plików.

Funkcjonalność DFS daje znaczące korzyści dla użytkowników pracujących w niejednorodnej sieci: zamiast widzieć fizyczną sieć składającą się z wielu serwerów plików z różnymi strukturami katalogów, użytkownicy widzą kilka najważniejszych logicznych katalogów, z których muszą korzystać. I w najlepszym przypadku wykorzystanie DFS może odłożyć trudy migracji.


Powód, dla którego nie można użyć KDC implementacji MIT Kerberosa w najprostszej konfiguracji jako serwera uwierzytelniającego dla usług Windows 2000 Server jest całkiem prosty: model zabezpieczeń Windows 2000 zależy od więcej niż listy SID-ów dla danych autoryzacji w biletach Kerberosa. Na przykład, aby zarządzać zabezpieczeniami plików NTFS, edytor ACL wymaga usługi domeny, która używa RPC przez kanał zabezpieczony Netlogon do DC, aby wyszukiwać nazwy na podstawie SID.

W istocie, ponieważ Windows 2000 wykorzystuje podsystem zabezpieczeń z NT, trzeba wzbogacić implementację MIT Kerberosa o następującą funkcjonalność (oprócz obsługi SID w biletach sesji), zanim będziemy w stanie zastąpić KDC z Windows 2000 Server:



  • Kanał zabezpieczony Netlogon

  • Uwierzytelniony RPC

  • Nazwy NetBIOS

  • LDAP

Migracja i współpraca z innymi wiodącymi systemami operacyjnymi


Jak zobaczymy w tym podrozdziale, zaangażowanie Microsoftu w mniej znaczące — a w niektórych przypadkach przestarzałe — systemy operacyjne pozostawia nieco do życzenia.

Apple Macintosh


Współpraca z Apple Macintosh ze środowisk Windows 2000 jest stosunkowo standardowa. Obsługując w sposób rodzimy podstawowe standardy Macintosha, Windows 2000 Server pozwala klientom w systemie Macintosh używać Windows 2000 Server jakby był serwerem Macintosh. Podobnie jak w Windows NT 4 Server, opcja ta jest udostępniona przez następujące wbudowane składniki Windows 2000 Server:

  • File Services for Macintosh — pozwala klientom Apple Macintosh używać systemu Windows 2000 Server jako udziału plików.

  • Print Services for Macintosh — pozwala użytkownikom Macintosha korzystać z udostępnionych drukarek Windows 2000 Server.

Obie z tych usług zgodnych z AppleShare zakładają z gry, iż protokół sieciowy Microsoftu zgodny z AppleTalk jest już zainstalowany i działa w danych serwerach Windows 2000. Poza tym nie pozostaje zbyt wiele do powiedzenia na temat współpracy i migracji w związku z systemem Macintosh.

IBM OS/2 Warp


Opis współpracy i migracji dla starych środowisk OS/2 Warp Server (dawniej OS/2 LAN Server) i OS/2 Warp Client (dawniej OS/2) jest jeszcze krótszy niż opis dla Macintosha: Współpraca i migracja nie istnieją.

Mimo iż IBM zasadniczo zatrzymał rozwój swojego systemu operacyjnego z dnia na dzień (i odmówił porzucenia swoich klientów, twierdząc iż OS/2 jest w trakcie wskrzeszania jako sieciowej platformy komputerowej), Microsoft nie ułatwia trudów migracji związanych z przenoszeniem istniejących instalacjiOS/2 do Windows 2000. Opracowane przez IBM klienty OS/2 Warp Server dla Windows NT 4 (IBM Networks Coordinated LogonClient for Windows NT i IBM Networks Primary Logon Client for Windows NT) oraz Windows 95 (IBM Networks Client for Windows 95) są jedynymi dostępnymi produktami pomagającymi w migracji OS/2 do Windows. Inaczej mówiąc, wybór jest mocno ograniczony.


Wciąż można się połączyć

Zatwardziali zwolennicy OS/2 mogą zwrócić uwagę, iż można połączyć się z systemem Windows 2000 Server z klienta OS/2 (i serwera OS/2) za pomocą protokołów NetBEUI i NetBIOS przez TCP/IP, podobnie jak było ze środowiskami Windows NT 4 Server, dzięki temu, iż platformy OS/2 i Windows NT opierały się początkowo na tym samym kodzie sieciowym.

Jednak z powodu rozejścia się ścieżek tych dwóch systemów operacyjnych, jesteśmy zasadniczo ograniczeni do tego samego poziomu współpracy jak dla podstawowej wersji Windows NT 4 Workstation — wobec tego przy podłączeniu komputerów OS/2 do Windows 2000 Server dostajemy niewiele więcej ponad podstawową łączność. Wobec tego, chociaż podpięcie kilku komputerów OS/2 do domeny Active Directory może być zdatnym do użytku rozwiązaniem przejściowym, nie skorzystamy wiele na podpięciu serwera OS/2. Czytelnicy desperacko zmuszeni do podłączenia OS/2 do środowiska Windows 2000 powinni zajrzeć pod adres www.haynes97.freeserve.co.uk. gdzie można znaleźć trochę rozsądnych informacji o tym, jak dokonać tej sztuki w Windows NT.


Banyan Systems Vines


Banyan VINES był pierwszym poważnym graczem na rynku usług katalogowych dla PC ze swoją usługą katalogową StreetTalk. Jednakże ta korzystna pozycja startowa z pierwszego miejsca nie pomogła firmie zbytnio wykorzystać zdrowego tempa rozwoju na polu usług katalogowych w drugiej połowie lat 90-tych. Zdając sobie z tego sprawę, firma Banyan Systems (obecnie ePresence) musiała poddać się siłom wolnego rynku pod koniec 1999. Wszelkie wsparcie dla usług StreetTalk i VINES zostało zakończone 1 maja 200, wobec czego w większości lokalizacji klientów StreetTalk i VINES są obecnie wycofywane z użycia.

ePresence zaleca migrację do Active Directory i aktywnie zachęca do tego przez ofertę usług pod nazwą BridgeNET 2000. BridgeNET obejmuje porady konsultanckie związane z migracją, zarządzanie kontami i usługi pomocnicze. O ile wiem, nie istnieją żadne narzędzia współpracy i migracji dla Windows 2000 Server i Active Directory, z wyjątkiem klienta sieciowego Windows 2000 dla VINES (Enterprise Client for Windows 2000). Wobec tego przejście do Active Directory najprawdopodobniej może być kłopotliwe. Klienci firmy Banyan mogą ponadto zwrócić uwagę, iż ePresence oferuje współistnienie i migrację BeyondMail i Intelligent Messaging z Microsoft Exchange Server i klientem Outlook.


Współpraca z systemami głównymi


Jak wspomniano we wcześniejszym podrozdziale o SSO, produkt Host Integration Server (dawniej SNA Server) jest głównym narzędziem Microsoftu umożliwiającym współpracę pomiędzy środowiskami Windows 2000 i systemami głównymi, które firma uważa za ważne. Host Integration Server 2000 przede wszystkim koncentruje się na systemach IBM (to znaczy, komputerach typu MVS/ESA, jak również AS/400 i AS/36) i nic nie zapowiada zmian w najbliższej przyszłości. Jeśli więc potrzebujemy rozwiązania dla integracji do Windows 2000 z innych środowisk systemów głównych, możemy równie dobrze zacząć rozglądać się za opcjami oferowanymi przez innych producentów.

SNA Server 4 oferuje dwukierunkową synchronizację i harmonizację haseł (co oznacza, iż zmiany haseł nie mogą nastąpić, dopóki nie zostanie potwierdzona zgodność nowego hasła z regułami haseł na obu platformach) pomiędzy Windows 2000 Server lub Windows NT 4 Server a hostami SNA jako opcję dostępną przy współpracy z zestawem narzędzi SecurPass. Obsługiwane produkty zabezpieczeń dla komputerów mainframe to ACF/2, RACF i CA-Top Secret. Do synchronizacji haseł z AS/400, Open Universal Software sprzedaje dostawcę zabezpieczeń niezbędnego do obsługi OS/400 V2R3 i wcześniejszych.

W Host Integration Server 2000 domyślnie oferowana jest jednokierunkowa synchronizacja haseł z Active Directory (oraz SAM) do komputerów mainframe z RACF, ACF/2 i Top Secret. Nie trzeba więc już składnika innego producenta po stronie komputera głównego, by zainicjować zmianę hasła z Windows NT lub Windows 2000.

Host Integration Server 2000 używa standardowego składnika Password Expiration Management (PEM) w komputerze głównym do dokonywania w nim zmian, przez co pozwala Windows 2000 grać rolę centralnej (głównej) bazy danych zabezpieczeń. Składnik PEM stanowi część Advanced Program-to-Program Communication/Customer Information Control System (APPC/CICS) w komputerze głównym, więc nie trzeba wprowadzać żadnych zmian w obecnym środowisku zabezpieczeń komputera głównego, by aktywować opcję jednokierunkowej synchronizacji haseł.

Ostrzeżenie

Dodatkowy produkt (rozszerzenie) jest nadal potrzebne dla dwukierunkowej synchronizacji haseł z komputerem mainframe. Produkty takie oferują Proginet i NEON Systems.

Warto też zauważyć, iż utrzymanie ID użytkownika i hasła dla funkcji pojedynczego podpisu nie odbywa się za pomocą własnej płaskiej bazy danych (jak w przypadku SNA Server). Za miast tego Host Integration Server 2000 używa Microsoft Data Engine (MSDE).

Oprócz funkcjonalności SSO w środowisku Host Integration Server 2000 można znaleźć następujące funkcje współpracy związane z głównymi usługami sieciowego systemu operacyjnego:



  • Shared Folders Gateway — pozwala użytkownikom korzystać z plików w udostępnionych folderach AS/400 tak, jakby mieściły się na lokalnym dysku Windows NT Server lub Windows 2000 Server. Takie same uprawnienia zabezpieczeń i prawa dostępu, jakie można zastosować do dowolnego innego pliku w NTFS, można zastosować do udostępnionych folderów. Ponadto uzyskujemy dostęp do systemu plików AS/400 za pomocą OLE DB.

  • Host Print Service — pozwala na drukowanie zadań wydruku komputerów mainframe i AS/400 na drukarkach przyłączonych do sieci lokalnej. Obsługa drukowania w komputerach mainframe obejmuje strumienie danych LU1 i LU3, z obsługą przechodzenia dla Intelligent Printer Data Stream (IPDS). Obsługa przechodzenia IPDS pozwala organizacjom wysyłać zadania wydruku komputerów mainframe do drukarek sieciowych bez zmian w aplikacjach głównych. Obsługę Full Advanced Function Presentation (AFP) można uzyskać za pomocą produktów rozszerzeń innych producentów dla Host Print Service. Obsługa drukowania w AS/400 zawiera standardowe drukowanie wierszowe SNA Character String (SCS), jak również obsługę przechodzenia dla emulacji drukarki graficznej 3812 za pomocą rodzimej funkcji AS/400 Host Print Transform.

  • FTP-AFTP Gateway Service i AFTP Service — umożliwia wszelkim klientom FTP dostęp do plików macierzystych w dowolnym komputerze mainframe lub systemie AS/400 z uruchomionym APPC File Transfer Protocol (AFTP).

  • VSAM File Transfer Service — umożliwia użytkownikowi przenoszenie plików VSAM do Windows NT lub Windows 2000 za pomocą prostego interfejsu wiersza poleceń.

  • TN5250 Service — pozwala klientowi odciążyć AS/400 od udostępniania tej funkcjonalności.

  • TN3270 Service — pozwala na dostęp hostów z dowolnego klienta TN3270, TN3270E lub TN3287.

  • Rodzimy dostęp 3270 i 5250 — pozwala na dostęp do komputera głównego z rodzima funkcjonalnością 3270 i 5250 (przez co niekoniecznie trzeba radzić sobie z podzbiorami TN3270 i TN5250).

  • Wiele sesji na pulpicie klienta — pozwala użytkownikom uruchomić na pulpicie do 16 kopii klienta 3270. W teorii użytkownik powinien być w stanie użyć tylu sesji, na ile pozwalają lokalne zasoby komputera, lecz 16 jest liczbą przetestowaną i potwierdzoną.

  • Wiele funkcji zwiększających bezpieczeństwo — pozwalają odciąć użytkowników nie uwierzytelnionych w domenie, kontrolować przydział Logical Unit (LU) do użytkowników i grup, przydzielać LU do określonych pulpitów (poprzez adres IP lub nazwę stacji roboczej), udostępniać automatyczne logowanie do aplikacji głównych za pomocą SSO i dokonywać szyfrowania wszystkich danych wchodzących lub pochodzących z komputera głównego pomiędzy pulpitem i systemem Host Integration Server 2000.

Oprócz tego Microsoft dodał sporą liczbę możliwości integracji (na przykład, otrzymaliśmy przezroczysty dostęp do danych relacyjnych DB2 i danych plików składających się z zapisów tego samego typu (flat-file) w komputerach mainframe, AS/400 i uniksowych, jak również integrację pomiędzy Microsoft Transaction Server i COM+ z środowiskami transakcyjnymi IBM-a CICS i IMS, obejmującą dwufazowe powierzenia pomiędzy platformami), pozwalających usługom .NET Microsoftu na bardziej ścisłą integrację z komputerami głównymi niż do tej pory. Wygląda na to, że fachowcy od systemów głównych Microsoftu pracują nad dość ambitnym celem przekształcenia Host Integration Server w składnik pośredni pozwalający Windows 2000 Server i głównym usługom .NET grać rolę swego rodzaju wirtualnego komputera głównego dla wybranej grupy aplikacji (typowo dla kolejkowania wiadomości, usług transakcyjnych i aplikacji DBMS), którego nie będzie można odróżnić od rzeczywistej maszyny.

Migracja i współistnienie dzisiaj


Gdzie jest ta obejmująca wszystko usługa katalogowa przedsiębiorstwa, którą sprzedawcy obiecują od kilku lat? Proszę nie szukać zbyt intensywnie, bo i tak jej nie znajdziemy. Dzisiejsze firmy przypominają raczej archipelag — grupę wysp zajmowanych przez wiele różnych systemów operacyjnych i aplikacji — a nie zjednoczoną sieć.

Jest to przypuszczalnie jeden z głównych powodów, dla których Microsoft koncentruje się dziś bardziej niż kiedykolwiek na udostępnieniu narzędzi migracji i współdziałania dla kluczowych platform systemów operacyjnych innych firm, oraz na współpracy z głównymi producentami aplikacji, aby umożliwić ich aplikacjom wykorzystanie możliwości Active Directory. Jednakże jak dotąd, większość narzędzi Microsoftu odzwierciedlało obecną dominującą pozycję firmy na rynku serwerowych systemów operacyjnych. Na przykład, historycznie rzecz biorąc lista narzędzi Microsoftu przeznaczonych do współpracy i migracji obejmowała znacznie lepszą obsługę platformy systemów operacyjnych Novella niż jakiejkolwiek innej platformy. Lecz obecnie Microsoft najwyraźniej koncentruje się na utworzeniu takiego samego zestawu narzędzi do migracji i współpracy dla Uniksa — drugiego dzisiaj co do wielkości konkurenta Microsoftu w zakresie serwerowych systemów operacyjnych.

Jednakże świeżo odkryta orientacja na SSO oznacza, iż Microsoft prawdopodobnie w końcu poszerzy zakres swojej oferty współpracy, przechodząc z historycznie wąskiej, konkurencyjnej koncentracji na systemach operacyjnych do sytuacji, w której usługa Active Directory będzie coraz lepiej ulokowana w bitwie usług meta-katalogowych. Jednakże Microsoft musi jeszcze wiele osiągnąć, zanim będzie w stanie przekonać klientów iż Active Directory jest meta-katalogiem, ponieważ prawdziwy meta-katalog powinien obsługiwać wiązanie ze sobą dużej liczby katalogów innych producentów (jak np. katalogów związanych z bazami danych i aplikacjami poczty elektronicznej) w pojedynczy, logiczny katalog. I to jest przyziemna lecz prawdziwa odpowiedź na pytanie, dlaczego Microsoft zakupił Zoomit Corporation w połowie roku 1999, oraz dlaczego tak usilnie stara się ściśle zintegrować meta-katalog MMS z Active Directory. Fakt, iż MMS będzie docelowo używać Active Directory jako głównego „pojazdu dostawczego” (w przeciwieństwie do pozostaną kolejnym katalogiem pomocniczym) zwiększa szanse na uznanie w przyszłości Active Directory za prawdziwy meta-katalog.

Warto jednak zwrócić uwagę iż Microsoft, mimo niewątpliwego docenienia zapotrzebowania na meta-katalog, dąży usilnie do partnerstwa z najważniejszymi niezależnymi producentami oprogramowania (ISV). Microsoft przyciągnął znaczące wsparcie z różnych źródeł, w zakresie od Cisco do dostawców Enterprise Resource Planning (ERP) — w tym SAP i Navision — dla tematyki integracji usług katalogowych. Lecz klienci nadal czekają na przekształcenie gładko brzmiących wiadomości marketingowych w rzeczywiste rozwiązania.

Jeśli więc Czytelnik nadal ma wątpliwości, czy Active Directory w końcu zostanie wysoce zachwalanym meta-katalogiem dla przedsiębiorstw, zdolnym do integracji z większością systemów operacyjnych i aplikacji innych producentów, radzę zwracać uwagę na rozwój rzeczywistych ofert integracji Active Directory ze strony społeczności ISV. Jeśli zobaczymy spory odsetek popularnych aplikacji na granicy integracji z Active Directory, lub mających ściśle zdefiniowane cele osiągnięcia tego w ciągu kilku lat, będzie to oznaczać, iż Microsoft rzeczywiście jest na drodze do pomyślnego przekształcenia Active Directory w meta-katalog.

Lecz zanim takie trendy staną się widoczne, radzę skupić uwagę na krótko- i średnioterminowych korzyściach z przejścia do Active Directory. Biorąc pod uwagę ścisłą integrację tej usługi z własną linią aplikacji Microsoftu .NET Enterprise Servers (dawniej znanych jako aplikacje BackOffice), szeroki zakres współdziałania zaplanowany dla Windows 2000 Server i stały wzrost zaangażowania ISV, można z pewnością znaleźć kilka prawdziwych korzyści z przejścia na Active Directory. Już uzyskanie SSO powinno stanowić dużą korzyść w wielu organizacjach.



Na koniec, zanim dojdziemy do przekonania iż meta-katalog jest remedium na wszystkie niedole przedsiębiorstwa, proszę zapamiętać, iż meta-katalogi zwykle nie przynoszą poprawy dla niszowych systemów operacyjnych (przestarzałych lub nie), aplikacji przestarzałych i napisanych na zamówienie, o ile nie posiadamy mnóstwa pieniędzy na zrobienie tego osobiście. Wobec tego zalecam zdecydowanie działać ostrożnie i upewnić się, iż wykorzystaliśmy wszystkie rzeczywiste (i wymierne) korzyści przed spróbowaniem własnego szczęścia w tak czasochłonnym i kosztownym przedsięwzięciu, jakim jest integracja katalogów.


1   2   3


©absta.pl 2019
wyślij wiadomość

    Strona główna