Przejdź do treści

Azure AD Connect – synchronizacja lokalnego Active Directory z chmurą

5
(1)

Korzystanie z Azure Active Directory (AAD) często nie polega na trzymaniu zasobów i zarządzaniu tożsamością wyłącznie w chmurze. Bardzo często, szczególnie w przypadku firm przynajmniej częściowo migrujących swoje środowiska do chmur, mamy do czynienia z tzw. środowiskiem hybrydowym – część usług/zasobów przechowywanych jest w chmurze, a część lokalnie w serwerowni danej firmy. Oznacza to, że użytkownicy korzystający z różnych elementów środowiska mogą potrzebować dostępu zarówno do zasobów przechowywanych lokalnie, jak i tych przechowywanych w chmurze. W takim przypadku tworzenie oddzielnych kont w AAD nie jest najbardziej optymalnym rozwiązaniem – zdecydowanie lepsze jest utrzymywanie jednej tożsamości dla jednego użytkownika (Single sign-on). Dlatego więc, szczególnie na potrzeby środowisk hybrydowych, udostępnione zostało darmowe narzędzie Azure AD Connect.

Azure AD Connect to narzędzie umożliwiające synchronizację pomiędzy środowiskiem lokalnym (on-premises) oraz chmurowym. Narzędzie to do swojego działania nie wymaga żadnych innych elementów umożliwiających połączenie pomiędzy środowiskami, jak np. VPN czy Express Route. Jedynym wymaganiem będzie instalacja klienta/agenta na kontrolerze domeny. Skąd więc go pobrać?

Będąc zalogowanym do portalu Azure przechodzimy do Azure Active Directory i odnajdujemy zakładkę Azure AD Connect w panelu po lewej stronie:

Po wejściu do zakładki możemy w niej znaleźć bezpośredni link do pobrania:

Instalacja sprowadza się jedynie do pobrania instalatora oraz uruchomienia go, więc nie ma sensu dokładnie opisywać tego procesu. Po zakończonej instalacji Azure AD Connect zostaje uruchomiony:

Po zaakceptowaniu wymaganych regulaminów zobaczymy ekran przedstawiający nam zadania, które mogą zostać automatycznie wykonane dla aktualnego lasu. Aby w pełni omówić cały proces wybieram opcję Customize:

W kolejnym kroku zobaczymy szereg dostępnych opcji dla dostosowania instalacji pod swoje potrzeby. Z racji, że w przypadku mojego środowiska nie zachodzi potrzeba zmiany domyślnych ustawień nie zaznaczam żadnej z dostępnych opcji i klikam przycisk install (spowoduje to utworzenie na urządzeniu lokalnej bazy SQL):

Po przeprowadzonej instalacji pojawi się nam lista niedostępnych wcześniej opcji, dzięki którym możemy skonfigurować odpowiednią synchronizację. Pierwszym i jednocześnie niezwykle istotnym krokiem jest wybór metody uwierzytelniania dla użytkowników. Na liście widzimy kilka dostępnych metod:

  • Password Hash Synchronization – przy tej metodzie hasła znajdujące się w lokalnym AD są synchronizowane z AAD. Oznacza to, że przy zastosowaniu SSO (o czym niżej) przy okazji logowania się do Azure hasło nie jest przesyłane do serwera, ponieważ jego kopia (a w zasadzie zaszyfrowywana kopia hasha takiego hasła) już się tam znajduje, co znacząco utrudnia podsłuchanie takiego ruchu (który swoją drogą jest oczywiście szyfrowany, logowanie odbywa się poprzez protokół HTTPS). Mechanizm synchronizacji co 2 minuty synchronizuje hasła pomiędzy środowiskiem lokalnym i chmurowym, więc w przypadku zmiany hasła danego użytkownika w środowisku lokalnym, po kilku minutach będzie ono zmienione również w środowisku chmurowym (hasło w środowisku lokalnym nadpisuje to w środowisku chmurowym). Minusem tego rozwiązania jest fakt, że z punktu widzenia administratora konto w lokalnym AD i w chmurze to 2 oddzielne konta, mimo iż z punktu widzenia użytkownika takiej różnicy nie widać). Więcej na ten temat można przeczytać tutaj.
  • Pass-through authentication – rozwiązanie, w którym proces uwierzytelniania przebiega wyłącznie w środowisku lokalnym. W ten sposób niezbędne do uwierzytelnienia użytkownika hasło nie jest przechowywane w Azure. Rozwiązanie to pomaga zachować większą kontrolę nad przechowywaniem haseł i spełnić niektóre specyficzne wymagania tego dotyczące. Wymaga to natomiast oddzielnego serwera, a właściwie serwerów, na których zainstalowany będzie agent potwierdzający tożsamość użytkownika logującego się do usług chmurowych. Dlaczego serwerów? Działanie agenta jest kluczowe dla uzyskiwania dostępu do jakichkolwiek zasobów w chmurze. W przypadku jakiejkolwiek awarii niezbędny będzie zapasowy serwer, który przejmie jego rolę – inaczej użytkownicy zostaną całkowicie odcięci od zasobów chmurowych. Więcej na temat tego rozwiązania można przeczytać tutaj.
  • Federation with AD FS – federacja pozwala na utworzenie realcji zaufania pomiędzy środowiskami. Oznacza to, że jeżeli środowisko lokalne oraz środowisko chmurowe mają utworzoną pomiędzy sobą tego typu relacje, to wystarczy, że użytkownik zaloguje się np. do środowiska lokalnego, aby być zalogowanym również w środowisku chmurowym. Zaufanie oznacza w tym przypadku, że środowisko chmurowe ufa środowisku lokalnemu, tj. jeżeli użytkownik uwierzytelnił się w środowisku lokalnym, to środowisko lokalne niejako potwierdza jego tożsamość, więc środowisko chmurowe opierając się na uwierzytelnieniu w środowisku lokalnym nie wymaga już ponownego uwierzytelnienia. Z punktu widzenia użytkownika zostaje on zalogowany do środowiska chmurowego bez konieczności logowania. Skrót AD FS w przypadku tej opcji oznacza, że odbywa się to za pomocą Active Directory Federation Service, które jest rolą Windows Serwera realizującą tę funkcję. Więcej na ten temat można przeczytać tutaj.
  • Federation with PingFederate – opcja działająca identycznie do poprzedniej, z tą różnicą, że zamiast odpowiedniej roli Windows Serwera mamy tu do czynienia z realizacją tej funkcji przez PingFederate – partnera Microsoft
  • Do not configure – opcja, która jak sama nazwa wskazuje, w tym momencie nie konfiguruje żadnej metody uwierzytelniania.

Wreszcie jedna z istotniejszych opcji – Enable Single sign-on. Opcja ta dostępna jest dla pierwszych dwóch opcji wybranych powyżej. Single sign-on to w dużym skrócie podejście, zgodnie z którym użytkownik posiada jedno konto (oraz jedno hasło) do wszystkich usług danej firmy, do których musi się on logować. Dzięki temu użytkownik posiada jedną tożsamość we wszystkich serwisach oraz musi zapamiętać tylko jedno hasło. Jest to zdecydowanie zalecany model, który warto wdrażać jeżeli tylko jest to możliwe, dlatego też warto zaznaczyć tą opcję w przypadku wyboru którejś z pierwszych dwóch metod.

Wybranie konkretnej metody na tym etapie nie jest równoznaczne z koniecznością wykorzystywania tej metody na dłuższą metę – w każdej chwili możemy ponownie uruchomić konfigurację i zmienić wcześniej wybraną metodę.

W kolejnym kroku należy uwierzytelnić się do Azure Active Directory za pomocą konta z uprawnieniami globalnego administratora:

Następnie wybieramy las, w którym znajduje się AD, które chcemy synchronizować. Warto pamiętać, że jeżeli nasze środowisko zawiera wiele lasów, na tym etapie możemy dodać je wszystkie jako środowisko włączone do synchronizacji. Obiekty (np. użytkownicy) z każdego AD zostaną zsynchronizowanie z Azure Active Directory. Aby dodać domenę wybieramy ją z listy i wciskami przycisk Add Directory:

Tak samo jak w przypadku Azure AD musimy uwierzytelnić się za pomocą konta z uprawnieniami administratora we wskazanym lesie. Podajemy więc login oraz hasło do konta głównego administratora oraz wybieramy opcję Create new AD account:

Po poprawnym uwierzytelnieniu zobaczymy dodane AD z „zielonym ptaszkiem” przy nazwie

W kolejnym etapie konfigurujemy uwierzytelnianie w Azure. Do poprawnego działania niezbędne jest dodanie własnej domeny, pasującej do tej wykorzystywanej w środowisku lokalnym, do swojego środowiska Azure. W przypadku środowisk testowych domyślna domena posiada charakterystyczną końcówkę „onmicrosoft.com”. Dla tego typu domen taka konfiguracja nie jest możliwa. Na tym etapie możemy również wskazać atrybut konta, który będzie wykorzystywane jako nazwa użytkownika w Azure AD.

W moim przypadku, z racji skonfigurowanego testowego środowiska zarówno w Azure jak i lokalnie, nie mam też dodanej własnej domeny, stąd przechodzę dalej zaznaczając opcję „Continue without matching all UPN suffixes to verified domains”:

W kolejnym kroku możemy wybrać, czy chcemy zsynchronizować wszystkie obiekty znajdujące się w lokalnym Active Directory czy tylko te wybrane. W moim przypadku zsynchronizuję jedynie elementu znajdujące się we wskazanej jednostce organizacyjnej. Jeżeli chcemy zsynchronizować wszystkie elementy znajdujące się w lokalnym AD wystarczy wybrać dostępną na górze opcję „Sync all domains and OUs”

W następnym kroku możemy wybrać zachowanie mechanizmu synchronizacji w przypadku, gdy nastąpi konflikt dotyczący np. nazwy użytkownika. Problem ten tyczy się przede wszystkim sytuacji, gdy synchronizujemy AD z kilku różnych lasów z naszym Azure AD – wtedy np. użytkownicy o takiej samej nazwie z dwóch różnych lasów trafią do tego samego Azure AD i nastąpi konflikt nazw. W tym miejscu możemy określić jakie atrybuty mają być brane po uwagę w przypadku identyfikacji takich użytkowników. W przypadku synchronizowania jednego lokalnego AD z Azure AD spokojnie można pozostawić domyślne opcje i przejść dalej:

Następnie dostępne mamy kolejne filtry pozwalające na zsynchronizowanie konkretnych użytkowników. Naturalnie filtry te są zależne od wcześniej wybranych opcji – w moim przypadku, gdy wcześniej zaznaczyłem tylko jedną jednostkę organizacyjną, która ma podlegać synchronizacji, ustawione w tym miejscu filtry będą odnosiły się tylko do obiektów, które znajdują się w zaznaczonej wcześniej jednostce organizacyjnej:

Następnie widzimy szereg dodatkowych opcji, które możemy ustawić dla synchronizowanych środowisk. Zaznaczenie poszczególnych opcji zależy od indywidualnych potrzeb, chciałbym jedynie zwrócić tutaj uwagę na „writeback” powtarzający się przy kilku dostępnych opcjach. Dostępna do zaznaczenia opcja „Password writeback” pozwala na synchronizację haseł w dwie strony – w domyślnej konfiguracji, gdy ta opcja nie zostanie zaznaczona hasło ustawione w lokalnym AD zawsze będzie nadpisywało to, które znajduje się w Azure AD, czyli zmiana hasła dla użytkownika będzie mogła odbywać się wyłącznie w lokalnym AD. Włączenie opcji Password writeback powoduje, że hasło zmienione w Azure (także, gdy użytkownik resetuje je samodzielnie nie mogąc zalogować się do swojego konta, o ile ma włączoną taką możliwość) będzie synchronizowane z lokalnym AD tj. hasło zmienione w Azure nadpisze również hasło ustawione w lokalnym AD:

Następnie, w przypadku gdy wcześniej zaznaczyliśmy opcję Enable Single sign-on będziemy musieli jeszcze uwierzytelnić się za pomocą konta lokalnego administratora, aby uruchomić tą usługę:

Podobnie jak poprzednio, po podaniu prawidłowych danych i uwierzytelnieniu się jako lokalny administrator zobaczymy „zielony ptaszek” oznaczający, że proces przebiegł poprawnie:

W ostatnim kroku potwierdzamy wprowadzoną przez nas konfigurację i klikamy na Install, aby rozpocząć proces synchronizacji naszych środowisk:

Po ukończonej synchronizacji otrzymujemy informację o zakończeniu procesu synchronizacji:

Po zakończonej synchronizacji możemy sprawdzić zmiany w naszym środowisku. W Active Directory Users and Computers w zakładce Computers powinien znajdować się wirtualny komputer o charakterystycznej nazwie:

Istnienie tego komputera w lokalnym AD, które podlega synchronizacji jest niezbędne do jego poprawnego działania. Należy więc zadbać o to, aby nie został on usunięty z AD np. przez inną osobę posiadającą do niego dostęp. Jego istnienie w AD wynika z wykorzystywania Single sign-on i jest to tzw. Kerberos proxy, umożliwiający poprawne działanie tej usługi.

W synchronizowanej przeze mnie jednostce organizacyjnej znajdują się dwa konta użytkowników:

W Azure AD w zakładce Users możemy zauważyć, że utworzone w lokalnym AD konta zostały prawidłowo zsynchronizowane:

Świadczyć o tym może również parametr Source mający wartość Windows Server AD widoczny przy obu użytkownikach. Dzięki takiemu oznaczeniu łatwo zidentyfikować, które konta zostały dodane do Azure AD na skutek synchronizacji z lokalnym AD:

W zakładce Azure AD Connect możemy znaleźć informacje dotyczące statusu synchronizacji pomiędzy środowiskami:

Słowo końcowe

Azure AD Connect to niezwykle użyteczne narzędzie w sytuacji, gdy firma zaczyna swoją przygodę z chmurą stawiając środowisko hybrydowe. Prawidłowo działające narzędzie nie tylko pozwala ułatwić pracę administratorowi, który dokonuje ewentualnych zmian (np. opisywanego hasła) tylko w jednym środowisku, ale również użytkownikowi, który posiadając jedno konto w obu środowiskach nie musi pamiętać nic ponad dotychczasowe hasło wykorzystywane przeze niego do logowania się do lokalnego środowiska domenowego.

Sam proces synchronizacji pozwala również zaoszczędzić masę czasu, szczególnie w przypadku dużych firm posiadających rozbudowane AD, który byłby niezbędny na przenoszenie obiektów i odtwarzanie struktury z lokalnego środowiska w środowisku chmurowym. Dzięki temu Azure AD Connect wydaje się być nieodłącznym narzędziem środowiska hybrydowego, którego znajomością powinna móc popisać się każda osoba administrująca czy zabezpieczająca tego typu środowisko w swojej firmie.

Coś jest dla Ciebie niezrozumiałe? Chciałbyś wyrazić opinię na temat artykułu? Znalazłeś jakiś błąd? Koniecznie daj mi o tym znać wysyłając maila lub wypełniając formularz!

Czy ten wpis był dla Ciebie przydatny?

Zostaw ocenę!

Średnia ocena 5 / 5. 1

Nikt nie ocenił jeszcze tego wpisu. Bądź pierwszym, który to zrobi!

Przykro mi, że post nie był dla Ciebie przydatny ...

Podziel się proszę swoją opinią

Twoja opinia jest dla mnie niezwykle ważna

1 komentarz do “Azure AD Connect – synchronizacja lokalnego Active Directory z chmurą”

  1. Fajny art, a pytanie takie jak mam w Azure dodana domenę niestandardową zakupioną z hostingu np klawaitura.pl To jak robić aby można się było logować do np teams imie.nazwisko@klawiatura.pl bo mi działa tylko z „onmicrosoft.com” i z panelu Azure nie mogę tego zmienić pomimo ze przed synchronizacją każde konto stworzone bezpośrednio w azure taką opcję ma :/

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *