BETA
Aby się zalogować, najpiew wybierz portal.
Aby się zarejestrować, najpiew wybierz portal.
Podaj słowa kluczowe
Słowa kluczowe muszą mieć co najmniej 3 sąsiadujące znaki alfanumeryczne
Pole zawiera niedozwolone znaki

Baza wiedzy











Synchronizacja haseł przy pomocy Identity Integration Feature Pack

05-12-2008 17:43 | Jacek Kochan
IIFP/MIIS nie jest szczególnie popularnym narzedziem. Aby zachęcić do zapoznania się z nim, proponuję wypróbowanie rozwiązania, w jaki sposób wykorzystać go do synchronizacji haseł kont między domenami.

Pewne scenariusze łączenia domen Active Directory mogą zakładać, że nie jest możliwe tworzenie zaufania pomiędzy nimi. Może zaistnieć jednak potrzeba, by użytkownicy z domeny klienta mogli korzystać z zasobów dostawcy usług, logując się przy pomocy identycznych bądź podobnych poświadczeń, jak w swojej domenie macierzystej. Aby uzyskać tę funkcjonalność, możemy posłużyć się darmowym narzędziem -- Identity Integration Feature Pack. Jest to okrojona wersja MIIS 2003 -- poprzednika Microsoft Identity Lifecycle Manager 2007.

IIFP do swojej instalacji wymaga systemu Windows Server 2003 Enerprise Edition oraz serwera SQL Server, co najmniej w wersji 2000 SP 4. Niestety, nie możemy go zainstalować na MSDE czy też SQL Express. Następnym wymogiem jest poziom funkcjonalności domen Windows Server 2003.
Ustalmy scenariusz, że użytkownicy z domeny klient.local będą korzystać z usług firmy provider.local. Użytkownik będzie mógł w swojej domenie zmieniać hasło, które następnie będzie synchronizowane z domeną dostawcy usług. Użytkownicy z domeny klient.local muszą mieć również utworzone konta w domenie provider.local.

W tym artykule opiszę, w jaki sposób synchronizować hasła pomiędzy domenami dla kont, które mają identyczny atrybut sAMAccountName, czyli nazwę konta. Zatem konta muszą zostać utworzone wcześniej, z tą samą nazwą w domenie klienta oraz dostawcy usług. IIFP bez rozszerzenia jego funkcjonalności odpowiednią aplikacją (biblioteka DLL) nie potrafi sam utworzyć kont w drugiej domenie na podstawie danych z pierwszej domeny. Można za jego pomocą tworzyć jedynie kontakty w celu synchronizacji książek adresowych GAL serwera Exchange.

Przygotowanie

Po stronie klienta potrzebujemy:

  • Domenę Active Directory Windows Server 2003
  • Windows Server 2003 Enterprise
  • SQL Server

Po stronie dostawcy potrzebujemy:

  • Domenę Active Directory Windows Server 2003

Sieć

Aby serwery z obu domen mogły się ze sobą komunikować, potrzebny jest oczywiście VPN. Nie jest konieczne wystawianie całej sieci. Wystarczy, aby domena klienta mogła komunikować się chociażby z jednym kontrolerem domeny i jednym serwerem DNS z drugiej strony.

Konfiguracja serwerów DNS

Do poprawnej synchronizacji danych poprzez IIFP musimy sprawić, aby usługa IIFP w domenie klient.local mogła rozpoznawać po nazwie DNS chociażby jeden kontroler domeny provider.local. Dlatego po stronie klienta należy skonfigurować serwery DNS.
Na serwerze klienta wchodzimy we właściwości serwera DNS na zakładkę Usługi przekazywania dalej, klikamy Nowa i wpisujemy nazwę domeny dostawcy usług, tutaj provider.local. Następnie podajemy adres IP serwera lub serwerów DNS klienta.

obrazek1

Oczywiście, serwer DNS można także skonfigurować, kreując stub zone. Jeżeli serwery klienta widzą prawidłowo serwer DNS providera poprzez łącze VPN, komenda nslookup provider.local powinna zwrócić adres IP kontrolerów z drugiej domeny.

Konfiguracja domeny klienta

Przed zainstalowaniem IIFP trzeba się troszkę pomęczyć z konfiguracją środowiska w obu domenach.

Tworzymy konta dla usługi MIIS Service oraz dla agenta synchronizacji.

W domenie klienta tworzymy nowe, zwykłe konta, np. o nazwie MIISService (dla usługi) oraz MIISAgentSvc (dla agenta). Zaznaczamy, by hasło nie wygasało. Jak przystało na konta usługi, powinny one mieć ograniczone możliwości logowania, czyli w domenowym GPO powinniśmy je dodać do zasad odmowy logowania lokalnego oraz odmowy logowania poprzez usługi terminalowe.

Dodajemy uprawnienia dla konta agenta w Active Directory.

Konto MIISAgentSvc musi posiadać uprawnienia do zmiany i resetowania haseł użytkownika, gdyż właśnie przy pośrednictwie tego agenta będzie odbywała się synchronizacja haseł.
W przystawce „Użytkownicy i komputery usługi Active Directory" klikamy prawym przyciskiem na nazwę domeny i wchodzimy we właściwości na zakładkę Zabezpieczenia (jeśli jej nie ma, to musimy włączyć w menu widok przystawki -- opcje zaawansowane).Klikamy Dodaj i wpisujemy nazwę agenta MIISAgentSvc. Konto zostanie dodane do listy zabezpieczeń. W uprawnieniach konta MIISAgentSvc zaznaczamy w kolumnie zezwalaj Replikowanie zmian katalogów (ang. Replicate Directory Changes). Klikamy Zastosuj. Teraz wchodzimy na zabezpieczenia OU, w którym znajdują się konta użytkowników klienta, np. o nazwie Klient; w zabezpieczeniach wybieramy MIISAgentSvc i nadajemy mu uprawnienie Odczyt. Następnie wchodzimy w zaawansowane ustawienia zabezpieczeń. Znowu klikamy Dodaj i wpisujemy MIISAgentSvc. W okienku uprawnień dla tego konta z rozwijanej listy Zastosuj dla wybieramy Obiekty Użytkownik (User Objects). Zaznaczamy w kolumnie zezwalaj: Resetowanie hasła i Zmienianie hasła (reset password, change password). Przyciskami OK zamykamy okienka.

Tworzymy grupy zabezpieczeń dla usługi MIIS.

W Active Directory musimy jeszcze dodać cztery grupy zabezpieczeń:

  • MIISAdmins (członek -- administratorzy domeny)
  • MIISBrowse (członkowie -- administratorzy domeny, konto MIISAgentSvc)
  • MIISJoiners (członek -- administratorzy domeny)
  • MIISOperators (członkowie -- administratorzy domeny, konto MIISAgentSvc)

Konfiguracja domeny dostawcy usług

Ten punkt wymaga nieco mniej pracy.

Tworzymy konto dla agenta synchronizacji.

Tak jak poprzednio, tworzymy konto MIISAgentSvc. Konto MIISService jest tu niepotrzebne, bo nie będziemy instalować usługi IIFP w tej domenie.

Dodajemy uprawnienia dla konta agenta w Active Directory.

W domenie dostawcy usług nadajemy jedynie uprawnienia do odczytu dla agenta MIISAgentSvc.
W przystawce „Użytkownicy i komputery usługi Active Directory" klikamy prawym przyciskiem na nazwę domeny i wchodzimy we właściwości na zakładkę Zabezpieczenia (jeśli jej nie ma, to musimy włączyć w menu widok przystawki -- opcje zaawansowane).Klikamy Dodaj i wpisujemy nazwę agenta MIISAgentSvc. Konto zostanie dodane do listy zabezpieczeń. W uprawnieniach konta MIISAgentSvc zaznaczamy w kolumnie zezwalaj Replikowanie zmian katalogów (ang. Replicate Directory Changes) i Odczyt. Klikamy OK.

Instalacja Identity Information Feature Pack

Program IIFP w tym scenariuszu zainstalowany będzie u klienta. Tylko wtedy klienci będą mogli zmieniać hasła w swojej domenie. Możliwy jest także scenariusz odwrotny. Przyjmijmy, że dostawca dostarcza usługi typu hosting Exchange i chcemy, aby użytkownicy mogli ustawiać hasła poprzez Outlook Web Access. Wtedy wszystko robimy na odwrót -- wszystkie komponenty IIFP instalujemy w domenie dostawcy. Niestety, synchronizacja w obie strony nie jest możliwa przy pomocy IIFP ani też MIIS. Jeżeli spróbowalibyśmy synchronizować w obie strony, wtedy hasła zaczną zmieniać się w nieskończoność w obu domenach, gdyż usługi powiadamiania o zmianie hasła będą informowane o tym fakcie naprzemiennie w obu domenach, a IIFP będzie chciał co chwilę zmieniać hasło w drugiej domenie.


Program aktualnie jest w wersji SP2. Ściągamy go ze strony:

Identity Integration Feature Pack for Microsoft Windows Server Active Directory with Service Pack 2 (SP2)

Zakładam, że jest przygotowany SQL Server do przechowywania bazy MIIS. W trakcie instalacji wprowadzamy następujące informacje:

  • Nazwa serwera SQL i instancji, na której ma być założona baza.
  • Poświadczenia dla konta usługi MIIS Service. Tu wpisujemy nazwę konta MIISService i jego hasło. Wpisujemy również NETBIOSOWĄ nazwę domeny.
  • W następnym oknie zatwierdzamy nazwy grup. Jeżeli są to grupy domenowe, tak jak w naszym przypadku, to musimy podać nazwy grup w domenowej formie, czyli: KLIENT\MIISAdmins, KLIENT\MIISOperators, KLIENT\MIISJoiners, KLIENT\MIISBrowse.

Instalacja usługi Microsoft Password Change Notification Service

MIIS to nie wszystko, czego nam potrzeba. Musimy zainstalować jeszcze specjalny program na wszystkich kontrolerach w domenie klienta. Program ten ściągamy ze strony:

Microsoft Password Change Notification Service

Jego zadaniem jest monitorowanie zmian haseł użytkowników i powiadamianie o tym fakcie usługi MIIS/IIFP. Podczas instalacji rozszerzany jest schemat Active Directory, więc instalacja musi być wykonywana przez członka grupy Administratorzy Schematu.

  • 1. Najpierw musimy uruchomić rozpakowany instalator takim poleceniem:

    msiexec /i "C:\Program Files\Microsoft Password Change Notification Service\Password Change Notification Service x86.msi" SCHEMAONLY=TRUE

  • 2. Po wykonaniu rozszerzenia schematu uruchamiamy instalator Password Change Notification Service x86.msi już w normalny sposób na kontrolerze domeny, instalując usługę.

  • 3. Instalację Password Change Notification Service x86.msi powtarzamy na pozostałych kontrolerach domeny klienta. Po instalacji wymagany jest restart kontrolera.

Konfiguracja Identity Information Feature Pack

Na początek parę słów objaśnienia, jak to działa. Magazyn danych usługi MIIS/IIFP, którego można umownie nazwać metaverse (brak polskiego odpowiednika), zbiera dane poprzez agentów z obu domen o użytkownikach i tworzy z nich obiekty metaverse'owe. Jeżeli przy pomocy pewnych reguł ustalimy powiązania między obiektami z jednej i drugiej domeny a obiektami metaverse, to otrzymamy jeden obiekt metaverse skojarzony z dwoma obiektami, z każdej domeny z osobna. W ten sposób możemy właśnie otrzymać skojarzenie de facto różnych użytkowników z obu domen, którzy posiadają jakąś wspólną cechę, np. imię i nazwisko bądź nazwę konta. W tym artykule będę kojarzył użytkowników za pomocą atrybutu sAMAccountName. MIIS przy pomocy usługi PCNS i odpowiedniej konfiguracji będzie nam automatycznie zmieniał hasło użytkownika w zdalnej domenie, gdy usługa PCNCS poinformuje o tym, że nastąpiła zmiana hasła.
Przejdźmy teraz do najciekawszej części. Kroki konfiguracji należy wykonać dokładnie według instrukcji, uważając, aby nie popełnić pomyłki, o którą tutaj nietrudno.

Otwieramy konfigurację IIFP.

Start\Programy\Microfost Identity Integration Server\Identity Manager

Indeksujemy atrybut, który będzie identyfikatorem obiektu w bazie MIIS.

Klikamy na pasku zadań Metaverse Designer. Z górnej tabelki Object types wybieramy person, następnie z dolnej wybieramy uid. Klikamy z prawej strony Edit attribute.

obrazek2

W oknie edycji atrybutu uid zaznaczamy pole Indexed.

obrazek3

Klikamy OK.

Tworzymy agenta dla domeny provider.local.

Na pasku klikamy Management Agents. Z menu akcji po prawej stronie wybieramy Create.

obrazek4
  • W pierwszym oknie designera upewniamy się, że tworzymy agenta do Active Directory. Wpisujemy też nazwę, np. Agent dla provider.local. Klikamy Next.
  • W następnym oknie wpisujemy nazwę lasu (provider.local), nazwę użytkownika do łączenia się z lasem (MIISAgentSvc@provider.local) i jego hasło.
obrazek5

Klikamy Next.

  • W kroku Configure Directory Partitions w oknie Select directory partitions wybieramy DC=provider, DC=local. Jeżeli domena klient.local ma kontakt tylko z określonymi kontrolerami w sieci provider.local, to w tym kroku możemy wymusić komunikację ograniczoną właśnie do tych kontrolerów. Służy do tego opcja Only use preferred domain controllers.
obrazek6

Następnie klikamy przycisk Containers.
W oknie wyboru jednostek organizacyjnych wystarczy, jeśli zaznaczymy te jednostki OU, w których znajdują się konta korespondujące z kontami domeny klient.local.

obrazek7

Klikamy OK, następnie Next.

  • W oknie Select object types zaznaczamy obiekt user i zostawiamy zaznaczone obiekty container, domainDNS i organizationalUnit.
obrazek8

Klikamy Next.

  • Następne okno Select attributes służy do wyboru atrybutów konta, którymi będziemy dokonywać dowiązania konta w bazie MIIS do konta w domenie provider.local. Tutaj jest dużo możliwości wyboru, w jaki sposób będziemy łączyć te konta ze sobą. Przyjmijmy, że w obu domenach użytkownicy będą posiadali identyczny atrybut sAMAccountName, czyli nazwę użytkownika. Taki atrybut więc wybierzmy.
obrazek9

Klikamy Next.

  • Kolejne okno -- Configure connector filter -- pozostawiamy bez zmian. Klikamy Next.
  • W kroku Configure join and projection rules konfigurujemy asocjację obiektu AD z obiektem metaverse. Z górnego okna Data Source Object Type wybieramy user i klikamy na New join rule.
obrazek10

W oknie konfigurowania reguły z listy Data source attribute wybieramy sAMAccountName. Mapping type pozostawiamy na Direct, z rozwijanej listy Metaverse object type wybieramy person, a jako Metaverse attribute wybieramy uid. Teraz klikamy na Add condition. Warunek zostanie dodany.

obrazek11

Dzięki temu konto domeny provider.local będzie dowiązane poprzez atrybut sAMAccountName z obiektem w bazie MIIS, którego atrybutem wiążącym z kontem w domenie jest atrybut uid.

  • Następne okno Configure attibute flow jest dość skomplikowane. Tu konfigurujemy, jakie atrybuty obiektu AD są wpisywane w atrybuty metaverse (import) lub odwrotnie (export). Tu konfigurujemy przepływ danych z obiektu AD do obiektu metaverse. Tutaj mamy możliwość synchronizowania atrybutów z jednej domeny do drugiej, dzięki opcji export. Jednak jest to temat na inny artykuł. Importu danych do metaverse będziemy dokonywać z domeny klient.local, dlatego przy konfiguracji agenta dla provider.local możemy pominąć ten krok. Inna sprawa, jeżeli chcemy dokonywać eksportu wybranych atrybutów do obiektów w domenie provider.local. Wtedy konfigurujemy to właśnie w tym miejscu.
  • W kolejnym kroku Configure deprovisioning pozostawiamy Make them disconnectors.
  • W kroku Configure extensions klikamy Enable pasword management, aby IIFP mógł resetować hasła w domenie provider.local. Klikamy Finish.

Tworzymy agenta dla domeny klient.local.

Czynności będą podobne -- będą różnić się tylko w pewnych miejscach, więc w skrócie:

  • Znów na pasku klikamy na Managements Agents i z menu akcji wybieramy Create.
  • W pierwszym oknie pozostawiamy Management Agent for: Active Directory. Wpisujemy nazwę, np. "Agent dla klient.local".
  • W następnym kroku podajemy poświadczenia do łączenia się z domeną klient.local. Wpisujemy nazwę lasu klient.local, nazwę użytkownika MIISAgentSvc, hasło i domenę.
  • W następnym oknie zaznaczamy partycję katalogu DC=klient,DC=local. Gdy klikniemy na przycisk Containers, będziemy mogli ograniczyć synchronizację do wybranych OU.
  • W kroku Select object types do obiektów container, domainDNS i organizationalUnit, dodajemy obiekt typu user.
  • W kolejnym oknie wyboru atrybutów do asocjacji obiektów pomiędzy domenami wybieramy odpowiedni atrybut, w tym scenariuszu jest to sAMAccountName.
  • Krok Configure Connector Filter możemy pozostawić bez zmian.
  • W oknie Configure join and projection rules zaznaczamy obiekt user i klikamy na New projection rule.
obrazek12

W oknie Projection pozostawiamy wybór Declared i typ person.


obrazek13

Klikamy OK. Zostanie dopisana nowa reguła z akcją Project. Klikamy Next.

W tym momencie deklarujemy, że obiekty w bazie MIIS typu person będą tworzone (projekcja obiektów) podczas importu obiektów z domeny klient.local. W analogicznym kroku agenta dla provider.local zrobiliśmy Join rule, czyli obiekty mają być dowiązywane, gdyż nie chcemy tworzyć dla nich obiektów person w bazie metaverse MIIS. Tutaj chcemy, aby obiekty metaverse były tworzone właśnie z kont w domenie klient.local.

  • Przechodzimy do kroku Configure Attribute Flow. Tutaj zdefiniujemy przepływ atrybutów sAMAccountName z obiektów AD do atrybutów uid obiektów Metaverse. Po prawej stronie na rozwijanej liście Data source object type ma być wybrany user. Na rozwijanej liście Metaverse object type ma pozostać person. Na liście Data source attribute wybieramy sAMAccountName, jeżeli wcześniej w kroku Select attributes wybraliśmy ten właśnie atrybut. Jeżeli wybrany był inny, wówczas tutaj również on się pojawi. Jako Flow direction wybieramy Import. Na liście Metaverse attribute wybieramy uid.
obrazek14

Klikamy przycisk New. Konfiguracja atrybutu zostanie dodana do listy na górze.

  • W kroku Configure Deprovisioning pozostawiamy Make them disconnectors.
  • W następnym kroku zaznaczamy Enable password management. Klikamy Finish.

Tworzymy profile uruchamiania synchronizacji dla agentów.

  • Wybieramy agenta domeny provider.local. Z menu akcji wybieramy Configure run profiles.
  • Klikamy na New profile. W nazwie wpisujemy np. "Full import and Synchro". Kliamy Next.
  • W następnym oknie konfigurujemy krok reguły. Wybieramy typ kroku: Full import and Full Synchronization. Klikamy Next.
  • W następnym kroku możemy nie zmieniać nic, ale w razie czego można zwiększyć Timeout np. do 3000 ms. Klikamy Finish.
  • W oknie konfiguracji profili uruchamiania zobaczymy gotowy profil.
    obrazek15
  • Klikamy na Script i zapisujemy skrypt wykonujący dany profil do pliku .vbs.
  • Taki sam profil reguł tworzymy dla domeny klient.local, następnie generujemy z tego profilu skrypt .vbs.

Teraz możemy uruchamiać synchronizację albo poprzez Identity Managera, wybierając danego agenta i z menu akcji klikając na Run, albo uruchamiając odpowiedni skrypt .vbs. Ponieważ synchronizacja powinna odbywać się cyklicznie, skrypty te należy dodać do Zaplanowanych Zadań w Windows i uruchamiać je co parę godzin.

Można utworzyć również profile Delta import i Delta synchronization i wyeksportować je do skryptu, używając zamiast Full import and Full Synchronization. Skrócą one czas synchronizacji domeny z bazą metaverse. Jednak po zmianie konfiguracji agenta zawsze na początek należy wykonać pełną synchronizację.

Rejestrujemy SPN dla usługi Password Change Notification Service.

Do wykonania tej czynności potrzebny jest zainstalowany pakiet Windows Server 2003 Support Tools z płytki instalacyjnej Windows.
Wykonujemy polecenie w domenie klienta:
Setspn.exe -A PCNSCLNT/IIFP_serwer.klient.local KLIENT\MIISService,

gdzie IIFP_serwer.klient.local to nazwa serwera MIIS, a KLIENT\MIISService to konto, pod którym jest uruchomiona usługa MIIS. Po tej operacji trzeba zrestartować serwer.

Konfigurujemy usługę Password Change Notification Service.

Musimy teraz wskazać usługom PCNS zainstalowanym na kontrolerach, gdzie znajduje się serwer MIIS/IIFP. Tutaj możemy również określić dwie grupy: zawierającą członków, których hasła mają być replikowane (inclusion group), oraz grupę wyłączenia, którzy z replikacji mają być wyłączeni (exclusion group). Członkowie exclusion group są zawsze wyłączeni z replikacji, nawet jeśli należą do inclusion group.
Zatem w folderze C:\Program Files\Microsoft Password Change Notification wykonujemy polecenie:

C:\Program Files\Microsoft Password Change Notification>Pcnscfg.exe addtarget /N:miis_serwer 
/A:miis_serwer.klient.local /S:PCNSCLNT/win2003vm1.klient.local /FI:PasswordSyncInclusion 
/FE:PasswordSyncExclusion /F:3 /I:600 /D:FALSE /WI:60,

gdzie win2003vm1 jest nazwą serwera MIIS, a miis_serwer.klient.local jest nazwą FQDN tego serwera. Grupa użytkowników włączonych do synchronizacji to PasswordSyncInclusion, a wyłączonych -- PasswordSyncExclusion.

Włączamy synchronizację haseł w IIFP.

Pozostaje nam już tylko włączenie synchronizacji haseł w agencie IIFP. Zatem w Identity Managerze wchodzimy w zakładkę Managemets Agents, wybieramy agenta Agent dla klient.local i klikamy na Properties w menu akcji. Przechodzimy do Configure Directory Partitions i zaznaczamy opcję Enable this partition as password synchronization source. Następnie klikamy na przycisk Targets i wybieramy agenta Agent dla provider.local. Na dole okna widzimy, że opcja Specify maximum number of password changes for a 24 hour period jest domyślnie ustawiona na 5, co oznacza, że synchronizacja haseł zostanie przeprowadzona maksymalnie pięć razy . Możemy zwiększyć tę liczbę albo całkowicie wyłączyć to ograniczenie.

obrazek16

Przyciskamy OK i zamykamy obydwa okienka.
Ostatnia czynność to włączenie możliwości synchronizacji haseł poprzez IIFP. W Identity Managerze z menu wybieramy Tools -> Options i na samym dole zaznaczamy Enable Password Synchronization.

obrazek17

Podsumowanie

Po poprawnej replikacji hasła na kontrolerze domeny klient.local w dzienniku Aplikacji pojawi się zdarzenie 2100, źródło PCNSSVC: „The password notification has been delivered to all targets". Jeżeli mamy włączoną inspekcję zdarzeń w domenie provider.local, zobaczymy zdarzenie mówiące o zmianie hasła w dzienniku Security, użytkownik MIISAgentSvc, zdarzenie 628. Jeśli coś jest nie tak, to po wykonaniu synchronizacji użytkowników domen z bazą metaverse, możemy zobaczyć jej efekt. W Identity Managerze po wejściu na zakładkę Metaverse Search możemy wyszukać wszystkie zaimportowane obiekty. Trzeba pamiętać, aby na liście kolumn wyświetlanej listy obiektów była kolumna uid. Po wejściu we właściwości obiektu na zakładkę Connectors ujrzymy, czy obiekt jest skojarzony z jednym czy z dwoma konektorami.

obrazek18

Na powyższym screenie widzimy, że obiekt został prawidłowo skojarzony z kontem w jednej i drugiej domenie. Jeżeli jest inaczej, wtedy dla danego użytkownika nie zadziała replikacja hasła po jego zmianie w domenie klient.local.

Identity Information Feature Pack potrafi synchronizować również inne atrybuty kont, grup, członkostwa grup i inne obiekty Active Directory. Jest też w stanie tworzyć obiekty, jeśli mu w tym pomożemy, otrzymując narzędzie do pełnej synchronizacji kont pomiędzy domenami. Postaram się napisać o tym w następnym artykule.

Autor:


Jacek Kochan (Jacolex)

Jacek Kochan (Jacolex)
MCITP:Messaging,MCSE+S/M MCTS:Hosting 2003,SBS,EBS


www.kochan.biz

tagi: domena

Komentarze 8

Jacek Doktór Ekspert WSS
Jacek Doktór
4247 pkt.
Guru
MVP
06-12-2008
oceń pozytywnie 0
Bardzo fajny artykuł i na ciekawy temat. Poprosimy o więcej :)

Jacek Doktor -
Polska Grupa System Center
Jacek Kochan Ekspert WSS
Jacek Kochan
3627 pkt.
Guru
06-12-2008
oceń pozytywnie 0
Dzięki! W przyszłym roku będzie... coś tam, coś tam ;)

--------------------
Jacek Kochan
MCSE+S/M 2003, MCITP: Messaging
http://www.kochan.biz
Tomasz Onyszko VIP
Tomasz Onyszko
8031 pkt.
Guru
MVP
09-12-2008
oceń pozytywnie 0
Należy tylko dodać że IIFP nie jest już rozwiązaniem oficjalnie wspieranym ... wraz MIIS 2003 przeszedł już do rozszerzonej fazy wsparcia. Pewnie wiekszości ludzi to nie bedzie przeszkadzać ale warto to dodać.


--
Tomasz Onyszko
http://www.w2k.pl/
Jacek Kochan Ekspert WSS
Jacek Kochan
3627 pkt.
Guru
10-12-2008
oceń pozytywnie 0
A zanosi się na jakąś nowszą darmówkę?

--------------------
Jacek Kochan
MCSE+S/M 2003, MCITP: Messaging
http://www.kochan.biz
Tomasz Onyszko VIP
Tomasz Onyszko
8031 pkt.
Guru
MVP
10-12-2008
oceń pozytywnie 0
Z tego co wiem to niestety nie ... IIFP już nawet zniknęło z downloads ale z różnych powowdów zostało przywrócone.

--
Tomasz Onyszko
http://www.w2k.pl/
Konrad Sagala Ekspert WSS
Konrad Sagala
3609 pkt.
Guru
MVP
05-01-2009
oceń pozytywnie 0
Zawsze można potestować ILM 2 w wersji RC ;) . IIFP niestety nie obsługuje Exchange 2007 (ale z Exchange 2003 scenariusz sychronizacji GAL śmiga)

_______________________
Pozdrawiam, Konrad [Microsoft Exchange MVP]
PEPUG
Mój Blog
Klaudiusz Żabiński
Klaudiusz Żabiński
43 pkt.
Poczatkujacy
11-11-2010
oceń pozytywnie 0

Hej,

 

Czy istnieje, oprócz ciut drogiego ILM 2007 jakieś rozwiązanie dla domen, gdzie klient ad ma poziom lasu 2003, ale niestety poziom domeny 2008 R2?

IIFP w moim przypadku niestety jest bezużyteczne.

Dzięki

Jacek Kochan Ekspert WSS
Jacek Kochan
3627 pkt.
Guru
11-11-2010
oceń pozytywnie 0

Sporo czasu minęło więc nie pamiętam dokładnie, ale chyba w testowym środowisku miałem właśnie konfigurację z poziomem domeny 2008 R2 i działało. W jaki sposób objawia się to niedziałanie? Lepiej zadaj takie pytanie na forum Windows Server, bo tutaj nikt może w najbliższym czasie  nie zajrzeć.

Jacek Kochan
MCITP: Ent. Admin, Ent. Messaging, MCSE+S/M 2003
www.kochan.biz

pkt.

Zaloguj się lub Zarejestruj się aby wykonać tę czynność.