Jeśli zadajesz sobie pytanie jak skonfigurować synchronizację pomiędzy lokalnym Active Directory, a chmurowym Azure Active Directory, tworząc hybrydowe środowisko, to dobrze trafiłeś. W tym artykule opiszę w jaki sposób przeprowadzić połączyć on-premise z chmurą korzystając z narzędzia ADConnect. Jeśli wydaje Ci się dziwny ten artykuł, przecież mamy rok 2021, to wszyscy powinni być już w chmurze – tak jednak nie jest i w tym, jak i pewnie w następnych latach będą powstawać on-premisowe instancje ADDS oraz nowe tenanty AAD.
Polecam zapoznać się z dokumentacją Microsoftu, tam znajdują się wszystkie zalecenia dot. przygotowania konfiguracji środowiska to instalacji AD Connect-a.
Aby rozpocząć synchronizację kont AD to chmury Microsoft należy zalogować się lub utworzyć konto (jeśli go jeszcze nie macie). Po utworzeniu konta tenant AAD utworzy się automatycznie i otrzymacie rolę Global Administratora. Tenant który się utworzy wynika z emaila, którego wpiszecie w polu rejestracji oraz kreator sprawdza czy takowy już nie istnieje, jeśli tak to możecie utworzyć swój własny z inną nazwą – pokażę to poniżej.
Aby utworzyć nowy (lub kolejny tenant), z menu głównego Azure Active Directory | Overview należy kliknąć przycisk Manage tenants.
Następnie przycisk Create
Następnym krokiem jest przejście kreatora nowego tenantu. W pierwszym kroku jest to wybór typu:
- Azure Active Directory: klasyczny tenant Azure Active Directory z możliwością zakładania/synchronizowania użytkowników i grup oraz zakładani kont gości (B2B – użycie innego Azure AD jako dostawcę tożsamości lub kont Microsoft)
- Azure Active Directory (B2C): tenant, który służy do uwierzytelniania użytkowników tylko z zewnętrznych dostawców tożsamości – portale społecznościowe, firmowi dostawcy tożsamości lub konta lokalne. Rozwiązanie jest stosowane do uwierzytelniania typu firma-klient, przy użyciu posiadanego już konta u swojego dostawcy tożsamości.
Wypełniamy pola wymagane: nazwa organizacji oraz sufix domeny.
Ostatni krok, czyli podsumowanie, wpisanie captcha i tenant utworzony.
Wszystkie tenanty mają domyślnego UPN-a w domenie *.onmicrosoft.com. Dodając własną domenę można to w przyszłości zmienić. Uwaga, jeśli korzystacie z split DNS, to musicie dodać swoją domenę do Custom domain names. Ze względu, że u moim labie korzystam ze split DNS, to dodam zatem domenę do AAD. Aby to zrobić należy wejść w Custom domain names, a następnie wybrać Add custom domain. Po wpisaniu nazwy domeny, należy ją zweryfikować, w tym celu musimy dodać rekord TXT lub MX w naszej publicznej strefie DNS.
Podczas konfiguracji własnej domeny, ustawiłem ją jako domyślną, aby pokrywała się z nazwą domeny on-premise. Krok ten pozwoli mi na synchronizację kont 1:1 (z tymi samymi UPN) pomiędzy AD, a AAD. Ułatwi to użytkownikom proces logowania. Bez tego zabiegu będą się logowali innym loginem w chmurze, a innym w on-premisie.
Dopiero po tych krokach możemy przejść do pobrania AD Connect-a, instalacje oraz pierwsza konfigurację. W dokumentacji AD Connect nie ma przeciwskazań do instalacji i uruchomienia konektora bezpośrednio na kontrolerze domeny, jednak mocno rekomenduję aby był on na dedykowanej maszynie.
Przejdźmy zatem do konfiguratora.
Po akceptacji, przechodzimy dalej, celowo do tego artykułu przejdę przez niestandardową konfigurację, aby przybliżyć wszystkie ustawienia na jakie możecie napotkać podczas instalacji AD Connecta.
W trybie zaawansowanym jest do wyboru kilka dodatkowych opcji konfiguracyjnych. Na ekranie wymaganych komponentów mamy do wyboru:
- Specify a custom installation location – wybór niestandardowego folderu instalacji,
- Use an existing SQL Server – użycie dedykowanej bazy danych. Domyślnie AD Connect korzysta z bazy danych SQL Server 2019 Express LocalDB. Gdy jednak instalujesz AD Connect w środowisku większym niż 100 000 obiektów rekomendowane jest użycie zewnętrznej bazy danych,
- Use an existing service account – uruchomianie usługi synchronizacji na innym koncie,
- Specify custom sync groups – domyślnie instalacja AD Connect tworzy 4 grupy lokalne do zarządzania uprawnieniami aplikacji (administratorzy, tylko do odczytu, operatorzy, do resetu haseł), zaznaczając tą opcję można dodać własne – muszą być to także grupy lokalne, na tym serwerze
- Import synchronization settings – przydatna opcja gdy odtwarzasz usługę AD Connect, np. po awarii
Na kolejnym ekranie mamy do wyboru metody logowania kontami on-premisowymi do usług chmurowych:
- Password Hash Synchronization – za pomocą aplikacji AD Connect wraz z synchronizacją kont do usługi Azure Active Directory są wysyłane hashe haseł (a tak w zasadzie to hashe hashy).
- Pass-through authentication – w momencie logowania do usług chmurowych, zostajemy przekierowani poprzez dedykowany konektor do lokalnego Active Directory, gdzie hasło wpisane w formularzu zostaje porównane z tym lokalnym.
- Federation with AD FS – logując się do usług Microsoft 365 zostajemy przekierowani do lokalnej usługi Active Directory Federation Services, gdzie następuje logowanie
- Federation with PingFederate – ten sam scenariusz co w poprzednim punkcie, tylko do logowania zostaje użyty inny dostawca – PingFederate
- Do not configure – funkcja logowania nie jest skonfigurowana. Możesz wybrać tą opcję, gdy masz innego dostawcę usług federacyjnych.
Do wyboru jest jeszcze opcja Enable single sign-on, która pozwala na automatyczne logowanie z komputerów firmowych. Jest dostępna tylko dla opcji Password Hash Synchronization oraz Pass-through authentication.
Podajemy dane logowania do konta utworzonego w Azure Active Directory, konto musi posiadać rolę Global administratora. Często konto za pomocą którego tworzycie tenanta posiada inny e-mail i UPN, mogą występować problemy z zalogowaniem do chmury poprzez AD Connect – polecam do tego założenie administracyjnego konta na te potrzeby z UPN-em *.onmicrosoft.com.
W następnym kroku podajemy konto z on-premisowego Active Directory. Uprawnienia są niezbędne do założenia konta, które będzie potrzebne do cyklicznej synchronizacji z Azure AD – nazwa rozpoczyna się od MSOL_*. Konto ma wysokie uprawnienia wydelegowane na najwyższym poziomie domeny, dlatego warto je umieścić w OU z mocno okrojonymi uprawnieniami.
Wybieramy las, który chcemy synchronizować do chmury
Weryfikujemy domenę oraz wybieramy atrybut, który będzie domyślną nazwą użytkownika w Azure AD
W kolejnym kroku mamy możliwość wyboru, które OU będą synchronizowane do chmury. W mojej konfiguracji synchronizację ograniczyłem tylko do OU, w których przechowuję użytkowników i komputery. Nie ma potrzeby synchronizacji kont technicznych.
Kolejny krok to wybór sposobu identyfikowania użytkowników lokalnych
Jednym z ostatnich kroków jest filtrowanie użytkowników. Niezależnie od wybranych OU można dodatkowo filtrować użytkowników i/lub komputery po grupie zabezpieczeń
Wybór dodatkowych opcji, m. in. zapis haseł z powrotem do on-premise (Password writeback) – konieczne gdy chcecie używać self-service w Azure, lub synchronizację dodatkowych atrybutów z AD do AAD (celowo zaznaczyłem tą opcję by pokazać ją w następnym kroku).
To już ostatnia opcja do wyboru, zdefiniowanie atrybutów, które mają zostać zsynchronizowane do AAD.
Dobrnęliśmy do końca konfiguracji, po kliknięciu install rozpocznie się konfiguracja wcześniej wybranych elementów oraz pierwsza synchronizacja. Domyślnie synchronizacja jest uruchamiana co 30 min.
Jak widzicie konfiguracja hybrydowej tożsamości pomiędzy lokalnym Active Directory, a chmurowym Azure Active Directory nie jest skomplikowana, jednak trzeba zwrócić uwagę na kilka istotnych elementów, jednak praktycznie wszystkie ustawienia ta się zmienić w trakcie użytkowania konektora. Jeśli chcecie poznać więcej szczegółów na temat AD Connecta, dajcie znać w komentarzach.
