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











Identity Lifecycle Manager "2" RC - publikowanie kont w AD i podglądanie haseł użytkowników

31-08-2009 11:00 | Jacek Kochan
W tym artykule pokażę, w jaki sposób przy pomocy ILM "2" można tworzyć konta użytkowników w Active Directory, pochodzących z innego źródła danych, synchronizując przy tym ich atrybuty. Pokażę również ciekawą funkcjonalność – możliwość przechwytu zmian haseł w Active Directory otwartym tekstem przy pomocy ILM, co dla wielu z nas może być pewną ciekawostką, a nawet sensacją.

Wstęp

W artykule, jaki ukazał się jakiś czas temu na temat Microsoft Indentity Integration Server , pokazałem możliwości tego produktu w zakresie importu atrybutów obiektów z Active Directory do metabazy MIIS oraz synchronizacji haseł pomiędzy odrębnymi domenami. W tym artykule posłużę się nowszą wersją MIIS o nazwie Identity Lifecycle Manager w wersji 2 RC. Pokażę, jak z jego pomocą można eksportować atrybuty obiektów z metabazy przy pomocy ILM "2", publikując w ten sposób użytkowników i jednocześnie zachowując synchronizację własności obiektów pomiędzy różnymi bazami kont. W tym przykładzie będzie to akurat synchronizacja pomiędzy Active Directory i bazą SQL Server. Pokażę również ciekawą funkcjonalność - możliwość przechwytu zmian haseł w Active Directory otwartym tekstem przy pomocy ILM, co dla wielu z nas może być pewną ciekawostką, a nawet sensacją.

Instalacja ILM 2

Oprogramowanie ILM 2 składa się z kilku komponentów, które można instalować na odrębnych maszynach. Rzecz jasna można też wszystkie zainstalować na jednym systemie.

Lista komponentów:

  • ILM Synchronization Service. Funkcja znana ze wcześniejszych wydań tego oprogramowania, czyli praktycznie usługa MIIS. Instalacja tej usługi jest podobna do instalacji opisywanej w artykule dotyczącym darmowej wersji MIIS, czyli o Identity Integration Feature Pack.
  • ILM Service Software. Usługa obsługująca żądania użytkowników.
  • ILM Portal and Password Portal Software. Aplikacja umieszczona na uprzednio zainstalowanym portalu WSS 3.0. Umożliwia m.in. zarządzanie użytkownikami, grupami i hasłami poprzez specjalnie utworzone przepływy informacji, czyli workflow.

Wymagania do instalacji są następujące: systemem operacyjnym musi być Windows Server 2008 64-bit, potrzebujemy również SQL Server 2008 64-bit. Na serwerze powinien być również zainstalowany PowerShell. Warto również mieć dostęp do Visual Studio 2008 i odrobinę umiejętności w posługiwaniu się nim. Będzie to niezbędne do tworzenia rozszerzeń ILM. Tak na prawdę ILM pokazuje swoje możliwości dopiero po ubraniu go w odpowiednie rozszerzenia, które niestety trzeba przygotowywać samemu, czy też przez dewelopera.

Ważna uwaga: Windows powinien mieć angielskie ustawienia regionalne. W przeciwnym wypadku ujrzymy błąd przy próbie wejścia na witrynę SharePoint portalu ILM.

Najpierw instalujemy usługę ILM „2" Synchronization Service. W trakcie instalacji podajemy:

  • nazwę konta dla usługi Microsoft Identity Integration Server (tak, ciągle ta sama stara nazwa tej usługi), hasło i domenę,
  • nazwy grup używane przez ILM, domyślne to: MIISAdmins, MIISOperators, MIISJoiners, MIISBrowse, MIISPasswordSet.

Dokładny opis instalacji całego serwera ILM "2" znajduje się pod linkiem:

ILM "2" (Release Candidate) Installation Guide.

Następnie instalujemy ILM „2" Server wraz z portalem. Rzecz jasna komponenty portalu do ShareSointa możemy instalować na osobnym serwerze, uprzednio instalując na nim SharePointa. W trakcie instalacji będziemy musieli podać:

  • Nazwę serwera SQL, na którym ma zostać zainstalowana baza (mój serwer nazywa się ILM2-SRV) i nazwę bazy (domyślnie: MSILM),
  • Nazwę konta usługi ILM,
  • dane dotyczące wcześniej zainstalowanego ILM Synchronization service - nazwę serwera i konto, pod którym będzie uruchamiany agent ILM.

Po instalacji będziemy mogli korzystać z witryny SharePoint: http://localhost/identitymanagement/default.aspx.

Scenariusz

W tym artykule pokażę, w jaki sposób można importować tożsamości z jednego miejsca do ILM, aby móc nimi zarządzać oraz wyeksportować do innego źródła danych. Mogą to być przykładowo dwie domeny AD czy też domena AD i baza SQL. Synchronizację można przeprowadzać z różnymi obiektami i systemami, nawet z plikiem tekstowym, więc możliwości jest sporo. Jako że w artykule o IIFP była opisana synchronizacja haseł pomiędzy dwoma domenami, więc dla różnorodności w tym artykule opiszę import użytkowników z tabeli w bazie SQL Server do bazy AD. Następnie pokażę, jak można przeprowadzać uniwersalną synchronizację haseł poprzez logowanie zmienianych haseł do pliku xml.

Konfiguracja źródłowej bazy użytkowników

Do celów prezentacyjnych utworzyłem tabelę kont w bazie o nazwie UsersDB, w których umieściłem redaktorów naszego kochanego portalu wss. Szybki skrypt tworzący tabelę:


CREATE TABLE [dbo].[Users](
	[UserID] [int] IDENTITY(1,1) NOT NULL,
	[FirstName] [nchar](30) NULL,
	[LastName] [nchar](30) NULL,
	[accountName] [nchar](30) NOT NULL,
	[JobTitle] [nchar](30) NULL
) ON [PRIMARY]

W tabeli znajdują się następujący użytkownicy:

Użytkownicy z bazy UsersDB

Jeżeli kogoś z redakcji pominąłem, to przepraszam.

Identity Manager

Identity Manager, który posłuży m.in. do konfiguracji agentów, ma identyczny interfejs, jak Identity Integration Feature Pack, MIIS, czy ILM 1.

W scenariuszach synchronizacji atrybutów pomiędzy różnymi bazami użytkowników, takich jak AD, SQL, możemy obyć się bez portalu ILM „2" i przetwarzanych danych poprzez ten portal, trzymanych w bazie MSILM. Wystarczy skonfigurować dobrze agentów w Identity Managerze. Jednak gdy chcemy bardziej zaawansowanych możliwości zarządzania użytkownikami i grupami, chociażby z możliwości kreowania użytkowników w AD, musimy skorzystać z portalu i bazy MSILM.

Ponieważ do synchronizacji z innymi bazami użytkowników potrzebni są agenci zarządzania, tak samo musimy utworzyć agenta do synchronizacji bazy metaverse (zwaną też metabazą) z bazą MSILM. W sumie potrzebujemy utworzyć trzech agentów zarządzania, co uczynimy na zakładce "Management Agents".

Konfiguracja agenta SQL

Agent ten będzie wskazywał na źródło danych w bazie UsersDB na serwerze SQL. Bazę tą umieściłem na tym samym serwerze, co bazy serwera ILM.

W skrócie opiszę konfigurację agenta.

  • Klikamy na przycisk Create i wybieramy agenta dla SQL Server. Nazwę go SQL MA.
  • W drugim kroku „Connect to database" wpisujemy dane do połączenia z bazą - nazwę serwera (ILM2-SRV), bazy (UsersDB) i tabeli (Users). Wpisujemy też nazwę użytkownika i hasło, który ma uprawnienia do korzystania z bazy UsersDB.
  • W trzecim kroku „Configure columns" ujrzymy konfigurację tabeli. Tutaj musimy ustalić, która kolumna będzie odpowiedzialna za identyfikację rekordów. Klikamy na Set Anchor i wybieramy kolumnę „accountName".
  • SQL MA - Configure Columns

  • W następnych krokach nie robimy nic. W ostatnim kroku klikamy Finish.

Musimy też skonfigurować na szybko profil uruchamiania, który będzie nam synchronizował bazę SQL z metabazą.

  • Z menu akcji wybieramy Configure Run Profiles, klikamy na New Profile.
  • Wpisujemy nazwę, np. Synchro, następnie konfigurujemy krok: Full import and full synchronization. Taki profil wystarczy do celów szkoleniowych, bez zabawy z profilami synchronizacji delta. Resztę ustawień pozostawiamy domyślnie.

Konfiguracja agenta ILM

Ten agent będzie odpowiadał za synchronizację danych pomiędzy bazą MSILM serweram ILM „2" a metabazą.

  • Klikamy na Create i wybieramy agenta dla Identity Lifecycle Manager. Nazwę go ILM MA.
  • W drugim kroku podajemy nazwę serwera SQL z bazą MSILM. W moim przypadku jest to serwer ILM2-SRV i baza MSILM. Wpisujemy też nazwę użytkownika i hasło, który ma uprawnienia do korzystania z bazy MSILM.
  • Trzeci, czwarty i piąty krok pozostaiwamy bez zmian. W kroku „Configure Object Type Mappings" uzupełniamy mapowania dla typów obiektów group i user. Klikamy na Add Mapping i mapujemy z typem obiekty metabazy, odpowiednio z group i person.
  • W kroku „Configure Attribute Flow" musimy skonfigurować przepływ atrybutów pomiędzy bazą MSILM a metabazą. W naszym przypadku robimy to tylko dla obiektów typu „person". Powiniśmy skonfigurować następujące atrybuty dla kierunku przepływu import i export: accountName, employeeID, displayName, firstName, lastName, jobTitle.

    Dodatkowo musimy dodać przepływ typu Import dla atrybutu: expectedRulesList.

    Dla każdego atrybutu wskazujemy atrybut z miejsca źródłowego i ten sam atrybut w metabazie. Klikamy na import i New, a potem na export i znowu New.

    Pozostałych atrybutów, istniejących już w konfiguracji, nie usuwamy.

    Przepływ export będzie kopiował dane z metabazy do serwera ILM - będą to dane zaimportowane z bazy UsersDB do metabazy. Przepływ import będzie służył do kopiowania użytkowników z serwera ILM, którzy będą założeni na tym serwerze poprzez interfejs portalu ILM, do metabazy. Konfiguracja przepływu atrybutów powinna wyglądać mniej więcej tak:

  • Konfiguracja przeplywu atrybutow

  • W pozostałych krokach nic nie robimy. Na koniec klikamy Finish.

Pozostało jeszcze skonfigurowanie profili uruchamiania. Klikamy więc na Configure Run Profiles.

  • Wpisujemy nazwę synchro i wybieramy typ kroku Full import and full sunchronization. Pozostałe opcje bez zmian.
  • Klikany na New Profile, wpisujemy nazwę export i wybieramy typ kroku Export. Pozostałe wartości pozostawiamy bez zmian.

Konfiguracja agenta AD

Ten agent będzie odpowiadał za tworzenie kont w domenie dla użytkowników utworzonych na serwerze ILM i zaimportowanych z bazy UsersDB.

  • Klikamy na Create i wybieramy agenta Active Directory Domain Services. Nazwę go AD MA.
  • W nastepnym kroku podajemy nazwę lasu, użytkownika mającego uprawnienia do tworzenia użytkowników w domenie i nazwę domeny. U mnie jest to domena ilm.local.
  • W kroku Configure Directory Partitions zaznaczamy partycję LDAP: DC=ilm,DC=local. Najlepiej by było skonfigurować w tym miejscu wyspecyfikowany kontener, z którym będzie następowałą synchronizacja z metabazą. W tym celu klikamy na Containers, odznaczamy wszystkie ptaszki i zaznaczamy jeden utworzony wcześniej kontener Active Directory. W moim wypadku jest to OU o nazwie ILM2Objects. Dzięki temu unikniemy nepotrzebnej synchronizacji wszystkich obiektów z naszej domeny.
  • Krok czwarty pozostawiamy w spokoju. W kroku piątym „Select Object Types" zaznaczamy ptaszek przy typie user.
  • W kroku „Select Attributes" zaznaczamy następujące atrybuty: displayName, employeeID, givenName, sn, samaccountname, title, userAccountControl, unicodepwd, userprincipalname.
  • Na liście nie widać dwóch ostatnich atrybutów, więc musimy zaznaczyć opcję Show All.

  • W pozostałych krokach nie robimy już nic.
  • Konfigurujemy również dwa profile uruchamiania. Niech będą to profile te same, co w wypadku agenta ILM MA, czyli Full import and full synchronization i Export.

Portal ILM „2"

Dalszą konfigurację wykonamy już na portalu ILM „2". Wchodzimy na adres http://localhost/identitymanagement/default.aspx. Po lewej stronie mamy panel do zarządzania użytkownikami, grupami, polityką zarządzania itd. Po prawej stronie jest panel administracyjny, w którym interesującym dla nas linkiem są reguły synchronizacji.

Panel ILM2

Pamiętamy, że w agentach SQL MA i AD MA nie musieliśmy konfigurować żadnej synchronizacji. Taką konfigurację przeprowadzimy później, właśnie tutaj.

Reguła synchronizacji z bazą SQL UsersDB

Skonfigurujemy teraz regułę, która będzie odpowiedzialna za import użytkowników z bazy UsersDB do bazy MSILM, czyli do naszego portalu.

  • W sekcji Administration klikamy na Synchronization Rules. Klikamy New, aby utworzyć regułę.
  • Wpisujemy nazwę, np. SQL UsersDB Inbound i pozostawiamy typ przepływu na Inbound. Klikamy Next.
  • Na zakładce Scope jako Metaverse object type wybieramy person, Connected system - wybieramy agenta SQL MA, a Connected Object Type ustawiamy na person. W Object Scope nie ustawiamy nic - wszystkie dane będą synchronizowane. Klikamy Next.
  • Na zakładce Relationship ustawiamy relację pomiędzy dwoma źródłami danych. Ja w tym przykładzie ustawię sobie relację między polem employeeID a accountName. Tak więc w kolumnie MetaverseObject:person(Attribute) ustawiamy employeeID, a w ConnectedSystemObject:person(Attribute) - accountName. Zaznaczamy też ptaszek przy Create object in ILM. Będzie to wskazówka dla agenta, że ma utworzyć obiekt, jeżeli nie znajdzie relacji pomiędzy obiektem w bazie ILM a drugim źródłem danych, czyli bazą SQL.
  • SQL UsersDB Inbound - Relationship

  • Na zakładce Inbound Attribute Flow ustalimy mapowania atrybutów pomiędzy źródłami danych. Wykonamy następujące mapowania:
  • Source Destination
     accountName  employeeID
     accountName  accountName
     firstName  firstName
     lastName  lastName
     firstName + " " + lastName
     displayName
     jobTitle  jobTitle

    Każde mapowanie definiujemy z osobna, klikając na New Attribute Flow. W otwartym okienku wybieramy odpowiednie pola źródłowe i docelowe. Pierwsze mapowanie między accountName a employeeID jest potrzebne dla ustanowienia relacji między obiektami. W przypadku displayName robimy małą sztuczkę. Jako źródło wybieramy firstName, nastepnie klikamy na przycisk Concatenate Value i w drugim polu wybieramy String. W polu wartości wstawiamy spację. Klikamy jeszcze raz na Concatenate Value i wybieramy w trzecim polu lastName. Jako destination wybieramy displayName.

    SQL UsersDB Inbound - Flow definition

    W rezultacie powinniśmy otrzymać następującą listę przepływu atrybutów:

    SQL UsersDB Inbound - Inbound attribute flow

  • Klikamy Next i na zakładce Summary klikamy Submit.

Konfiguracja pierwszeństwa w przepływie atrybutów

Po skonfigurowaniu reguły synchronizacji z bazą SQL może nastąpić problem, gdyż do metabazy będą próbowały zapisywać informacje dwa źródła danych do tych samych atrybutów jednocześnie. Ten konflikt rozwiązywany jest konfiguracją kolejności pierwszeństwa agentów. Musimy ustawić pierwszeństwo agenta SQL MA nad agentem ILM-MA. Najpierw musimy jednak uruchomić run-profile agentów. Dla obu agentów uruchamiamy więc profil uruchamiania synchro.

Teraz, gdy reguła synchronizacji utworzona w portalu ILM oraz obiekty z bazy UsersDB zostały zaimportowane do metabazy, możemy ustawić kolejność pierwszeństwa przepływu atrybutów. W tym celu w Identity Managerze wchodzimy na Metaverse Designer.

  • W Object Types zaznaczamy typ person.
  • Z dolnej listy atrybutów wybieramy atrybut accountName. Po prawej stronie z menu akcji wybieramy Configure Attribute Flow Precedence.
  • Configure attribute flow precedence

  • W otwartym okienku przestawiamy agenta ILM MA na drugą pozycję, a SQL MA na początek.
  • To samo wykonujemy dla atrybutów: firstName, lastName, displayName, employeeID, jobTitle.
  • Dodatkowo warto włączyć indeksowanie dla atrybutów accountName i employeeID. Klikamy na atrybut, wybieramy z akcji Edit Attibute i zaznaczamy ptaszek przy Indexed.

Teraz w zasadzie możemy uruchomić agentów synchronizacji. Lepiej jednak w tym momencie tego nie robić, dopóki nie zostaną wykonane pozostałe kroki konfiguracji agentów i portalu ILM. Dlaczego - o tym później. Nic złego się nie stanie, jeśli teraz uruchomimy profile agentów. Jednak później możemy mieć mały kłopot, którego nie udało mi się rozwiązać. Jeśli jednak koniecznie chcemy sprawdzić, czy działa synchronizacja, włączamy profile uruchamiania - na agencie SQL MA profil Synchro, a na agencie ILM MA - Synchro a potem Export. Profil export wyeksportuje użytkowników z metabazy do portalu ILM, czyli do bazy MSILM.

Możemy sprawdzić wynik eksportu, wchodząc na portal na sekcję Users i klikając na search.

ILM2 eksport

Reguła synchronizacji z Active Directory

Pora na utworzenie reguły eksportu użytkowników ILM do Active Directory.

  • Na zakładce Administration znowu klikamy na Synchronization Rules. Klikamy New, aby utworzyć regułę.
  • Wpisujemy nazwę, np. AD Outbound i pozostawiamy typ przepływu na Outbound. Klikamy Next.
  • Na zakładce Scope jako Metaverse object type wybieramy person, Connected system - wybieramy agenta AD MA i Connected Object Type ustawiamy na user. Klikamy Next.
  • Na zakładce Relationship ustawiamy relację obiektów pomiędzy bazą ILM a połączonym Active Directory. Proponuję ustawić relację poprzez pole employeeID. Tak więc w kolumnie MetaverseObject:person(Attribute) ustawiamy employeeID, a w ConnectedSystemObject:person(Attribute) - również employeeID. Zaznaczamy też ptaszek przy Create object in connected system.
  • Na zakładce Parameters nie robimy nic. Na zakładce Outbound Attribute Flow ustalimy mapowania atrybutów pomiędzy źródłami danych. Wykonamy następujące mapowania:
  • Source Destination
     employeeID  employeeID
     displayName  displayName
     firstName  givenName
     lastName  sn
     accountName
     sAMAccountName
     jobTitle  title
     accountName + "@ilm.local"
     userPrincipalName
     "512"  userAccountControl
     "CN=" + displayName + ",OU=ILM2Objects,DC=ilm,DC=local"  dn
     "Password1"  unicodePwd

    Nazwy atrybutów LDAP, czyli w tym wypadku z AD, różnią się nieco od nazw ILM. Jeżeli w polu Destination nie widać jakiegoś atrybutu, to znaczy, że nie wybraliśmy go konfigurując agenta AD MA.

    Znowu musimy posłużyć się sztuczką, aby wykonać cztery ostatnie mapowania. W wypadku userAccountControl, jako source podajemy Number i wartość 512. Dla unicodePwd podajemy String, wpisując domyślne hasło, w tym przykładzie jest to „Password1". Proszę się nie obawiać, po zaimportowaniu użytkownika do AD, atrybut zostanie wpisany do hasła użytkownika i wykasowany. Atrybut userPrincipalName składa się z accountName i ciągu „@ilm.local". Do skonstruowania atrybutu dn musimy utworzyć ścieżkę LDAP do tworzonego obiektu. A więc jako pierwsze pole źródła podajemy String o wartości „CN=", do drugiego pola wrzucamy np. displayName (choć może to być też np. accountName, ale displayName później będzie ładniej wyglądał), a do trzeciego pola dalszy ciąg ściezki LDAP.

    AD Outbound - Flow definition

    Po dodaniu wszystkich potrzebnych mapowań, musimy zaznaczyć jeszcze w kolumnie „Initial flow only" ptaszki przy polach: employeeID, userAccountControl, dn, unicodePwd. Będzie to oznaczać, że te pola będą ustawione tylko przy pierwszej synchronizacji.

    Na koniec powinniśmy otrzymać mniej więcej coś takiego:

    AD Outbound - Outbound Attribute Flow

  • Klikamy więc Next i Submit.

Konfiguracja procesu Workflow dla reguły synchronizacji AD

Utworzenie reguły do synchronizacji AD to niestety nie wszystko. Następną rzeczą, którą trzeba zrobić, to utworzenie akcji na zakładce Workflows, znajdującej się po lewej stronie panelu portalu ILM. W Workflows klikamy na New.

  • Wpisujemy nazwę procesu, np. AD Outbound Action. Jako typ przepływu wybieramy Action. Klikamy Next.
  • Na zakładce „Activities" w oknie Activity Picker wybieramy Synchronization Rule Activity I klikamy Select. Ukaże się okno Select Synchronization Rule, w którym wybieramy wcześniej utworzoną regułę AD Outbound. Jako akcję pozostawiamy Add. Klikamy na przycisk Save.
  • AD Outbound Action

     

  • Klikamy Next i Submit.

Konfiguracja polisy zarządzania

Pozostała jeszcze jedna rzecz do zrobienia. W portalu ILM klikamy w lewym menu na Management Policies. Klikamy New, aby utworzyć polisę.

  • Jako nazwę podajemy np. AD Outbound MP. Klikamy Next.
  • Na zakładce "Requestors and Operations" w polu Specific Set of Requestors wpisujemy All people. Klikamy na ptaszek weryfikacji podanej nazwy, następnie w sekcji Operation zaznaczamy Create resource i Modify resource attributes.
  • AD Outbound MP

  • Na następnej zakładce w sekcjach Target Resource Definition Before Request i Target Resource Definition After Request, w polach Specific Set of Objects również wpisujemy All people i klikamy na przycisk walidacji. Następnie klikamy Next.
  • Na zakładce „Policy workflows" zjeżdżamy belką na sam dół i wybieramy wcześniej utworzoną akcję AD Outbound Action. Klikamy Next i Submit.

Synchronizacja ILM z AD

W tym momencie możemy już uruchomić profile agentów w Identity Managerze, aby wykonać synchronizacje między źródłami danych. Profile synchro będą importować dane do metabazy, a profile export - tworzyć i modyfikować obiekty w źródłach danych - w portalu ILM i w domenie ilm.local.

Tutaj niestety jest mały problem. Jeżeli wcześniej wykonaliśmy import użytkowników z bazu UsersDB do portalu ILM, to teraz po uruchomieniu wszystkich run-profili nic się nie wydarzy. Jest to spowodowane tym, że akcja AD Outbound Action wykonywana jest, gdy polisa zarządzania AD Outbound MP wykryje jakąś modyfikację na zdefiniowanych użytkownikach. Jeżeli użytkowników mamy zaimportowanych przed skonfigurowaniem polisy, to ci użytkownicy już nie zostaną wyeksportowani do agenta AD. Jak to obejść - na tą chwilę nie wiem. Jeżeli ktoś ma jakiś pomysł, to proszę o kontakt lub komentarz. Wtedy zmodyfikuję artykuł z adnotacją o autorze tego sposobu.

Aby trigger zadziałał, trzeba zmodyfikować każdego użytkownika z osobna. W zasadzie wystarczy w panelu ILM wejść na zakładkę Users, wyświetlić użytkowników, a następnie kliknąć na danego użytkownika i po wyświetleniu jego atrybutów zamknąć przyciskiem OK i Submit. Serwer ILM uzna to już za modyfikację użytkownika i wyzwoli akcję AD Outbound Action. Aby sprawdzić, czy akcja zostanie wykonana, trzeba powtórnie wejść we właściwości tego użytkownika na zakładkę Provisioning.

ILM Update User

Na górze widzimy, że w polu Expected Rules List została dopisana reguła synchronizacji AD Outbound ze statusem Pending, co oznacza, że po uruchomieniu run-profili Synchro i Export, użytkownik zostanie wyeksportowany do domeny ilm.local.

Aby sprawdzić poprawność eksportu do AD, możemy też bepzośrednio w portalu ILM utworzyć nowego uzytkownika, bez wcześniejszego importu z bazy UsersDB. W tym celu utworzyłem siebie.

ILM create user

Wypełnić trzeba wszystkie niezbędne pola, potrzebne do synchronizacji użytkownika z AD, włączając w to employeeID. Po założeniu użytkownika możemy sprawdzić, czy w jego właściwościach na zakładce Provisioning pojawiła się reguła AD Outbound.

Wykonujemy run-profile dla agentów ILM MA: Synchro i Export, a potem dla AD MA: Export.

Po udanej synchronizacji wszystkich użytkowników, powinniśmy otrzymać całą taką listę kont w Active Directory:

AD users

Eksport haseł

Teraz gdy mamy już gotowe konta w AD i użytkownicy mogą na nich pracować, może się okazać, że na przykład użytkownicy mają też konta w jakimś obcym systemie i chcą mieć te same hasła, co w domenie. Pokażę zatem, jak wykonać eksport zmienianych haseł przykładowo do pliku xml.

Dłubanie w Visual Studio

Niestety drodzy administratorzy, ale wtyczkę dll musimy sobie napisać i skompilować sami. Na początek podaję link, w którym wszystko jest dokładnie objaśnione:

Creating a Password Extension in Visual Basic .NET

Ja opiszę w skrócie, jak wykonać szybko taką wtyczkę.

Do wykonania operacji potrzebujemy Visual Studio. Warto mieć go zainstalowane lokalnie na serwerze ILM, gdyż będziemy mieli wtedy możliwość debugowania kodu.

  • W Visual Studio tworzymy nowy projekt typu Class Library.
  • Najpierw musimy zaimportować do nowego projektu biblioteki z ILM. Znajdziemy je w katalogu instalacyjnym ILM „2" RC:

    ILM2_RC0\Metadirectory Services and User Provisioning\Setup\PFiles\Microsoft Identity Integration Server\Bin\PFiles\Microsoft Identity Integration Server\Bin\Assemblies

    Interesują nas dwa pliki dll:

    • Microsoft.MetadirectoryServices.dll
    • Microsoft.MetadirectoryServicesEx.dll
  • Kopiujemy je na komputer, na którym mamy Visual Studio, albo rozpakowujemy instalkę i importujemy bezpośrednio z niej.
  • W menu Visual Studio klikamy Project -> Add Reference. Wchodzimy na zakładkę Browse i wybieramy lokalizację tych dwóch plików. Zaznaczamy obydwa pliki i wciskamy OK.
  • VS add reference

  • Teraz trzeba napisać kod wtyczki. Zdaję sobie sprawę z tego, że jesto to zadanie przewyższające możliwości typowego it-prosa. Bez obaw. Microsoft przygotował przykładowe listingi takiej wtyczki. Przykłady kodów w językach C# i Visual Basic można znaleźć tu:
  • Example: Password Extension

    Używając Visual Studio 2008 natknąłem się niestety na błąd przy kompilacji - w linijce, gdzie jest:

    If Nothing <> m_xmlWriterExport Then

    Wystarczyło tą linijkę zamienić na:

    If Nothing Is m_xmlWriterExport = False Then

    Przykładowy kod ze strony MSDN jest dość toporny w działaniu - każdy zapis kasuje stary plik xml i zapisuje na jego miejsce nowy. Dlatego stworzyłem prostszy i krótszy kod, zapisujący zmieniane hasła do pliku tekstowego, dopisując do niego kolejne rekordy.

    
    Imports System
    Imports System.IO
    Imports System.Text
    Imports System.Collections.Specialized
    Imports Microsoft.MetadirectoryServices
    
    Namespace SamplePasswordManagement
        Public Class SampleMAPasswordManagement
            Implements IMAPasswordManagement
            Public Sub New()
            End Sub
            Public Sub BeginConnectionToServer(ByVal connectTo As String, _
                                           ByVal user As String, _
                                           ByVal password As String) _
                        Implements IMAPasswordManagement.BeginConnectionToServer
            End Sub
            Public Sub EndConnectionToServer() _
                        Implements IMAPasswordManagement.EndConnectionToServer
            End Sub
            Public Function GetConnectionSecurityLevel() As ConnectionSecurityLevel _
                            Implements IMAPasswordManagement.GetConnectionSecurityLevel
                Return ConnectionSecurityLevel.NotSecure
            End Function
            Public Sub SetPassword(ByVal csentry As CSEntry, ByVal NewPassword As String) _
                            Implements IMAPasswordManagement.SetPassword
                Dim InputString
                InputString = csentry.DN.ToString & "," & NewPassword & vbCrLf
                My.Computer.FileSystem.WriteAllText(MAUtils.MAFolder & "\hasla.txt", InputString, True)
            End Sub
            Public Sub ChangePassword(ByVal csentry As CSEntry, _
                                      ByVal OldPassword As String, _
                                      ByVal NewPassword As String) _
                        Implements IMAPasswordManagement.ChangePassword
                Dim InputString
                InputString = csentry.DN.ToString & "," & NewPassword & vbCrLf
                My.Computer.FileSystem.WriteAllText(MAUtils.MAFolder & "\hasla.txt", InputString, True)
            End Sub
            Public Sub RequireChangePasswordOnNextLogin(ByVal csentry As CSEntry, _
                                                        ByVal fRequireChangePasswordOnNextLogin As Boolean) _
                        Implements IMAPasswordManagement.RequireChangePasswordOnNextLogin
                Throw New EntryPointNotImplementedException
            End Sub
        End Class
        Module Nodes
        End Module
    End Namespace 'SamplePasswordManagement
    

    Po zmianie hasła usługa MIIS wywoła metodę SetPassword, która dopisze do pliku tekstowego hasla.txt linijkę z nazwą konta użytkownika (będzie to konkretnie wartość brana z pola, które podaliśmy jako Anchor przy konfiguracji agenta SQL MA) i zmienionym hasłem, rozdzielonym przecinkiem.

    Nie chcę zagłębiać się za bardzo w opis metod i ogólnego działania tego kodu. Wszystko można wyczytać na stronach MSDN. Napomknę jeszcze, że metoda ChangePassword nie jest wykorzystywana - nie wiem, dlaczego. Wszystkie odwołania - resety i zmiany haseł przez użytkowników - obsługiwała procedura SetPassword.

    Jeżeli ktoś chce napisać własne rozszerzenie, to radzę też przeczytać, w jaki sposób można debugować kod, podpinając go do procesu usługi MIIS:

    Attaching the Debugger to the Process

  • Po wklejeniu kodu do projektu kompilujemy go, wybierając w menu: Build -> Build nazwa_projektu (mój projekt nazwałem ILMPasswdXML).
  • W folderze projektu nazwa_projektu\bin\release znajdziemy gotowy plik nazwa_projektu.dll, który kopiujemy na serwer, na którym mamy zainstalowany Identity Manager do ścieżki: C:\Program Files\Microsoft Identity Integration Server\Extensions\

Password Synchronization Service

Kto czytał artykuł o IIFP, ten wie, że aby móc synchronizować hasła z domeny, trzeba w tej domenie zainstalować usługę synchronizacji haseł na kontrolerach domeny. Tutaj ważna uwaga: hasła możemy synchronizować tylko z tej domeny, w której zainstalowany jest ILM Synchronization Service. Instalkę usługi synchronizacji haseł znajdziemy w folderze instalacyjnym ILM:

C:\ILM2_RC0\Metadirectory Services and User Provisioning\Password Synchronization

Niestety nie udało mi się zainstalować usługi z tej instalki. Próbowałem na różnych systemach - od 2003 do 2008 R2, 32-bit i 64-bit. Na żadnym usługa nie dała się uruchomić. Radzę więc ściągnąć starszą instalkę ze stron Microsoft, która działa:

Microsoft Password Change Notification Service

  • Po rozpakowaniu instalki do C:\Program Files (x86)\Microsoft Password Change Notification Service musimy wykonać instalację wraz z uaktualnieniem schematu AD. Robimy to poleceniem:
  • MSIEXEC.EXE /i " C:\Program Files (x86)\Microsoft Password Change Notification Service\Microsoft Password Change Notification Service x64.msi" SCHEMAONLY=TRUE

  • Drugim krokiem jest instalacja usługi na każdym z pozostałych kontrolerów.
  • Trzecim krokiem jest dodanie spn-u, co robimy poleceniem:
  • Setspn.exe -A PCNSCLNT/ilm2-srv.ilm.local ilm\ilmsvc

    Ilm2-svc.ilm.local to pełna nazwa fqdn serwera z usługą Microsoft Identity Integration Server. Ilm\ilmsvc to konto, pod którym działa usługa MIIS.

  • Czwartym krokiem jest konfiguracja usługi PCNS na kontrolerze domeny:
  • C:\Program Files\Microsoft Password Change Notification>Pcnscfg.exe addtarget /N:ilm2-srv /A:ilm2-srv.ilm.local /S:PCNSCLNT/ilm2-srv.ilm.local /fi:"Domain Users" /f:3

Konfiguracja Identity Manager

Najpierw wybierzemy utworzoną wtyczkę, uaktywniając ją na agencie synchroznizacji SQL MA.

  • Otwieramy właściwości agenta SQL MA, wchodzimy na zakładkę Configure Extensions, klikamy na ptaszek Enable password management, klikamy przycisk Select i wybieramy plik dll, który skompilowaliśmy i skopiowaliśmy do katalogu rozszerzeń serwera MIIS. Wciskamy jeszcze Settings i odznaczamy ptaszek przy Require secure connection for password synchronization operations.
  • Configure extensions

  • Wciskamy OK.
  • Teraz skonfigurujemy agenta AD MA, aby domena ilm.local służyła jako źródło synchronizacji haseł.

  • Otwieramy agenta AD MA. Wchodzimy na sekcję Configure Directory Partitions i zaznaczamy ptaszek przy Enable this partition as password synchronization source.
  • Następnie klikamy na Targets I zaznaczamy agenta SQL MA. Odznaczamy też ptaszek przy Specify maximum number of password changes...
  • AD MA - Password synchronization

  • Klikamy dwa razy OK.
  • Pozostaje nam jeszcze uaktywnić synchronizację haseł w Identity Managerze. Robimy to wchodząc w menu Tools -> Options i zaznaczając ptaszek przy Enable Password Synchronization.
  • I to wszystko. Teraz każda zmiana hasła przez użytkownika, który został zaimportowany z bazy SQL UsersDB, będzie skutkować wpisem do dziennika zdarzeń aplikacji na kontrolerze domeny o identyfikatorze 2100, a następnie zapisem hasła czystym tekstem do pliku tekstowego na serwerze ILM do ścieżki:

    C:\Program Files\Microsoft Identity Integration Server\MaData\SQL MA\hasla.txt

    W tym scenariuszu, jeżeli zmienię lub zresetuję hasło na koncie Mariusza Kędziory albo na swoim, to zostanie wywołane zdarzenie ID 2100 na kontrolerze, hasło zostanie przekazane do usługi MIIS, ale nie zostanie zapisane do pliku hasla.txt. Dzieje się tak, ponieważ agent synchronizuje hasła tylko dla tych użytkowników, którzy są podłączeni w metabazie pod konektor SQL MA. A więc zmiana hasła zadziała tylko dla zaimportowanych użytkowników z bazy UsersDB.

    Podsumowanie

    Myslę, że zmienią teraz zdanie ci, którzy dotychczas uważali, że nie można odczytać haseł użytkowników z kontrolera odmeny otwartym tekstem. Wprawdzie tylko tych zmienianych haseł, ale zawsze coś.

     

    Autor:


    Jacek Kochan (Jacolex)

    Jacek Kochan (Jacolex)

    Centrum Innowacji Microsoft przy PCSS

    MCITP:Ent. Admin, Messaging
    MCTS: Hosting,SBS,EBS

    www.kochan.biz

    Podobne artykuły

    Komentarze 7

    Jacek Kochan Ekspert WSS
    Jacek Kochan
    3627 pkt.
    Guru
    31-08-2009
    oceń pozytywnie 0
    Odczytywanie odbywa się na kontrolerze tak czy inaczej, o to chodziło.

    --------------------
    Jacek Kochan
    MCSE+S/M 2003, MCITP: Ent. Admin, Messaging
    http://www.kochan.biz
    Tomasz Onyszko VIP
    Tomasz Onyszko
    8031 pkt.
    Guru
    MVP
    31-08-2009
    oceń pozytywnie 0
    No OK - skoro sensacją określamy interfejs od lat opisany na MSDN to może tak i jest ... odczytanie odbywa się na DC ... tak bo tam zainstalowane jest rozszerzenie filtra haseł.

    Hasło nie jest odczytywane z bazy danych kontrolera ... ale moze to ja widze tutaj roznice.

    BTW - dlaczego dla AD MA uzywasz codeless provisioning a dla SQL MA nie?

    --
    Tomasz Onyszko
    http://www.w2k.pl/
    Jacek Kochan Ekspert WSS
    Jacek Kochan
    3627 pkt.
    Guru
    31-08-2009
    oceń pozytywnie 0
    No właśnie. Chciałem po prostu zwrócić uwagę, że jest taka możliwość. Ale nie napisałem, że hasło jest odczytywane z bazy kontrolera, gdzie jak wiadomo, są trzymane tylko hashe.

    Dla SQL MA nie ma w tym scenariuszu w ogóle provisioningu. Jest tylko w jedną stronę, żeby artykuł za bardzo się nie rozrósł :)

    --------------------
    Jacek Kochan
    MCSE+S/M 2003, MCITP: Ent. Admin, Messaging
    http://www.kochan.biz
    Tomasz Onyszko VIP
    Tomasz Onyszko
    8031 pkt.
    Guru
    MVP
    31-08-2009
    oceń pozytywnie 0
    Ależ oczywiście że masz provisioning w przypadku SQL MA tylko jako dla ILM MA. To że to działa tak jak to opisałeś to inna sprawa ale przepływy danych które skonfigurowałeś ręcznie można też skonfigurować jako incoming synchronization rule. Tak że akurat całość tego scenariusza bardzo prostego zresztą dało się opędzić uzywając tylko konfiguracji po stronie ILM.

    Z takich uwag jeszcze ... jeżeli ktoś chce eksperymentować z ILM2 racze poczekać do RC1.

    --
    Tomasz Onyszko
    http://www.w2k.pl/
    Jacek Kochan Ekspert WSS
    Jacek Kochan
    3627 pkt.
    Guru
    31-08-2009
    oceń pozytywnie 0
    Scenariusz ten oparłem na scenariuszach ze stron Technet :)

    Wiedziałem, że ktoś uzna, że to żadna sensacja. Ale większość nie czytała tych dokumentacji na MSDN i nie ma o tym pojęcia. Może Cię zdziwię, ale są inżynierowie w MSFT (a spotkałem jednego), którzy stwierdzą, że wyciąganie haseł czystym tekstem z DC nie jest możliwe w żaden sposób.

    --------------------
    Jacek Kochan
    MCSE+S/M 2003, MCITP: Ent. Admin, Messaging
    http://www.kochan.biz
    Tomasz Onyszko VIP
    Tomasz Onyszko
    8031 pkt.
    Guru
    MVP
    31-08-2009
    oceń pozytywnie 0
    I ja się z nim zgadzam :)

    A prosszym sposobem zdobycia hasel do katalogu jest po prostu sluchanie ruchu sieciowego - w kazdej sieci o rozmiarze wiecej niz kilka stacji znajdzie sie jakas web strona albo inna aplikacja ktora uzywa LDAP simple bind bez SSL. Od pewnego rozmiaru organizacji to jest nawet pewne ... :)

    --
    Tomasz Onyszko
    http://www.w2k.pl/
    Jacek Kochan Ekspert WSS
    Jacek Kochan
    3627 pkt.
    Guru
    01-09-2009
    oceń pozytywnie 0
    Napisałem "w żaden sposób" - a ten sposób jest.
    Zwracam uwagę na to, że "uświadomiony" admin, którego nikt nie kontroluje, dostaje łatwe narzędzie do podglądania zmienianych haseł w domenie. Pozostawiam kwestię, czy jest to sposób lepszy od sniffowania, czy nie.

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

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