Na początek należy zaznaczyć, że chodzi o przejście z ADFS na Pass-through Authentication. Polskie tłumaczenie bywa problematyczne…

PTA, jak na standardy chmury Microsoft 365, nie jest nowym rozwiązaniem (dostępne od 2017 roku) i jego wdrożenie od zera jest już dość szeroko udokumentowane w sieci. Natomiast jeśli chodzi o migrację z AD FS, w szczególności w bardziej złożonych środowiskach, to artykułów w dalszym ciągu brakuje.

W tym artykule opisany zostanie proces przejścia w organizacji, w której:

• w jednym lesie AD skonfigurowane jest kilkanaście relacji zaufania z innymi lasami,
• synchronizacja katalogów z wybranych lasów AD do Azure AD odbywa się za pomocą jednej maszyny z Azure AD Connectem,
• skonfigurowana jest federacja za pomocą serwerów AD FS na wszystkich synchronizowanych domenach,
• występuje kilka serwerów Exchange, przechowujących skrzynki pocztowe użytkowników,
• skonfigurowane jest połączone hybrydowe do Office 365,
• istnieje jedna organizacja Office 365,
• użytkownicy logują się z wykorzystaniem mechanizmu MFA.

Z poziomu portalu Azure (sekcja Azure Active Directory -> Azure AD Connect) konfiguracja logowania użytkowników wygląda następująco:

Istnieją dwa główne powody zmiany sposobu logowania:

• zmniejszenie poziomu komplikacji środowiska,
• zniwelowanie konieczności utrzymania dodatkowych serwerów.

Planowanie

W zależności od tego, jak były skonfigurowane serwery ADFS, należy podążać ścieżką określoną przez Microsoft. Jeśli usługa AD FS została skonfigurowana przy pomocy Azure AD Connect (jak na rysunku poniżej), to zmiany metody logowania można dokonać przez kreator konfiguracji Azure AD Connect. Taka sytuacja występuje w opisywanym przypadku.

W wypadku natomiast, gdy w konfiguracji Azure AD Connecta nie ma informacji o AD FS, konwersji domen należy dokonać ręcznie przez Powershella.

Niekiedy Azure AD Connect błędnie nie wyświetla informacji o usłudze ADFS, mimo że była ona skonfigurowana. Dlatego warto powrócić do dokumentacji z wdrożenia lub przejść do konfiguracji logowania użytkowników i tam zweryfikować, czy pole Federation with AD FS jest zaznaczone.

Na prace należy przeznaczyć kilkugodzinne okienko serwisowe, ponieważ po konwersji domeny Azure AD może nadal wysyłać prośby o zalogowanie do serwerów AD FS przez następne 4 godziny. W związku z tym użytkownicy mogą napotkać problemy z zalogowaniem się do usług.

Informację o planowanym okienku, potencjalnych problemach i skutkach zmiany należy zakomunikować użytkownikom.

Przed wdrożeniem należy rozważyć zmianę kilku ustawień, które mogą zwiększyć bezpieczeństwo i user experience nowej technologii:

• named locations – po konfiguracji mechanizm MFA dla użytkowników w sieci firmowej zostanie wyłączony (zobacz jak to zrobić),
• hybrid Azure AD joined devices – dla zapewnienia Seamless SSO dla nowych urządzeń dołączanych do domeny AD po konwersji na PTA (zobacz jak to zrobić),
• branding – celem zwiększenia bezpieczeństwa, np. jako forma ochrony przed phishingiem (zobacz jak to zrobić),
• smart lockout – zabezpieczenie przed atakami brute-force na hasła (zobacz jak to zrobić),
• polityka GPO – dodanie witryny autologon.microsoftazuread-sso.com do strefy „Lokalny intranet”. celem zapewnienia mechanizmu Seamless SSO dla użytkowników korzystających z urządzeń dołączonych do domeny.

Backup

Na początek należy wykonać kopię zapasową środowiska. W tym celu:

• użyto narzędzia AD FS Rapid Restore Tool,
• wykonano eksport reguł poświadczeń (claim rules) za pomocą Powershella (zobacz jak to zrobić),
• wykonano kopię zapasową maszyny z rolą AD FS,
• wykonano polecenie get-msoldomain i wyeksportowano do pliku wynik zawierający nazwę domeny i wartość pola Authentication.

Wdrożenie

W kreatorze konfiguracji Azure AD Connect należy wybrać opcję Change User Sign in, następnie połączyć się do Azure AD za pomocą poświadczeń globalnego administratora. W kroku User sign-in należy wybrać Pass-through authentication i  Enable single sign-on.

W kolejnym oknie należy wpisać poświadczenia administratora domeny dla domen, dla których ma być włączony mechanizm single sign-on.

Po kliknięciu Configure w kolejnym kroku WSZYSTKIE domeny zaczną zmieniać swój status z federated na managed. Proces ten zajmuje kilka-kilkanaście minut w zależności od liczby domen i użytkowników.

Po ukończeniu zadania kreator wyświetla wynik działania.

Jeśli występują ostrzeżenia, jak na zdjęciu powyżej, oznacza to, że dla dwóch domen nie udało się skonfigurować SSO. Procedura naprawy zostanie opisana w kolejnym rozdziale.

Konfiguracja domen

Na obecnym etapie należy zdecydować, które domeny mają pozostać ze statusem Managed, a które z powrotem przejść na status Federated. W opisywanym przypadku wszystkie domeny, dla których nie został skonfigurowany mechanizm PTA mają być z powrotem sfederowane. W tym celu na serwerze ADFS uruchomić należy powershell i wykonać polecenie dla każdej domeny:

Convert-MsolDomainToFederated -SupportMultipleDomain -DomainName domena.pl

Aby dodać SSO dla brakujących domen (ostrzeżenie na rysunku 3) należy uruchomić Powershell na stacji z Azure AD Connect i wykonać kolejno polecenia:

1. cd "C:Program FilesMicrosoft Azure Active Directory Connect"

2. import-module .azureadsso.psd1

3. New-AzureADSSOAuthenticationContext - podać poświadczenia globalnego administratora

4. Get-AzureADSSOStatus – weryfikacja domen, dla których ustawienie zostało włączone

5. Enable-AzureADSSOForest - podać poświadczenia administratora domeny, dla której ustawienie nie zostało włączone

6. Get-AzureADSSOStatus – ponowna weryfikacja domen

Po dodaniu trzeciej domeny i zainstalowaniu drugiego agenta sytuacja w portalu Azure wygląda jak na rysunku poniżej:

Testy

Po wdrożeniu użytkownicy z domen uprzednio sfederowanych nie powinni być już przekierowywani do strony logowania ADFS. Zachowanie to najlepiej jest zaobserwować w trybie prywatnym przeglądarki. Wtedy użytkownik podaje zarówno swój UPN, jak i hasło na stronie logowania Azure AD.  W trybie normalnym użytkownik powinien zostać automatycznie zalogowany do witryn Office 365, wspierających mechanizm domain hint (np. myapps.microsoft.com/domena.pl). Niestety obecnie strona portalu Office 365 (portal.office.com) nie wspiera tego rozwiązania i użytkownik jest zmuszony podać swój UPN. Po wpisaniu użytkownik zostanie automatycznie zalogowany, hasło nie jest już wymagane.

Testy należy przeprowadzić z wykorzystaniem wszystkich aplikacji Office 365 używanych przez użytkowników, zarówno na komputerach,  jak i na urządzeniach mobilnych. W opisywanym przypadku wystąpiły problemy z aplikacją Teams. Po upływie kilkunastu godzin klient Teams odwoływał się jeszcze do AD FS. Po wpisaniu błędnego hasła kolejne próby logowania przebiegały już bezproblemowo.

Podsumowanie

Wdrożenie metody Pass Through Authentication w środowisku wielodomenowym z uprzednio skonfigurowaną federacją jest jak najbardziej możliwe, ale wymaga dokładnego zaplanowania i przeprowadzenia konfiguracji zarówno na tenancie, jak i na środowiskach lokalnych. Opcjonalne jest też pozostawienie niektórych domen jako sfederowane i stopniowe przechodzenie na PTA.