Zmiana sposobu logowania z federacji na uwierzytelnianie przekazywane

Piotr Bieliński

Zmiana sposobu logowania z federacji na uwierzytelnianie przekazywane
21 listopada, 2019 APN Promise SA

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:

Rysunek 1: Logowanie użytkownika przed wdrożeniem

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.

Rysunek 2: Azure AD Connect - informacje o AD FS

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.

Rysunek 3: Azure AD Connect - dodatkowa wdrożenia AD FS

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 Enable single sign-on.

Rysunek 4: Zmiana metody logowania na PTA z włączonym SSO

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

Rysunek 5: Wybór domen

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.

Rysunek 6: Koniec pracy kreatora

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:

Rysunek 7: Logowania użytkownika po wdrożeniu

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.

Podziel się

Autor: Piotr Bieliński

Piotr Bieliński

Piotr Bieliński

Inżynier systemowy

Absolwent Wydziału Elektroniki i Technik Informacyjnych Politechniki Warszawskiej. Od dwóch lat w APN Promise, gdzie zajmuje się wdrażaniem i migracją usług komunikacyjnych. W wolnych chwilach pasjonat sportów wytrzymałościowych.

Zespół: Cloud Productivity

Ostatnie artykuły autora

Jak chronić dane wrażliwe w Microsoft 365

Jak chronić dane wrażliwe w Microsoft 365

Piotr Bieliński wyjaśnia czym są dane wrażliwe w rozumieniu Microsoft, jak można je chronić dzięki portalowi Security & Compliance oraz jaką rolę w tym procesie odgrywają typy danych. Krok po kroku pokazuje również jak stworzyć własny typ danych.

Zmiana sposobu logowania z federacji na uwierzytelnianie przekazywane

Zmiana sposobu logowania z federacji na uwierzytelnianie przekazywane

Piotr Bieliński przeprowadzi Cię krok po kroku przez proces planowania, przygotowania i wdrożenia zmiany polegającej na przejściu z ADFS na Pass-through Authentication w organizacji. Wyjaśnia również na co zwrócić szczególną uwagę i dlaczego testy są tak istotne.

Zwiększenie efektywności w zasięgu ręki

Zwiększenie efektywności w zasięgu ręki

Piotr Bieliński i Monika Kubiak wyjaśniają w jaki sposób narzędzia IT usprawniają pracę w firmie i jak przeprowadzić wdrożenie, aby wykorzystać pełen ich potencjał. Podpowiadają również, jak zmierzyć efektywność tego procesu.

Skontaktuj się z autorem

 

    Administratorem danych gromadzonych z wykorzystaniem formularza jest A.P.N. Promise S.A. Podane przez Ciebie dane będą przetwarzane w zakresie niezbędnym do podjęcia kontaktu lub realizacji określonego żądania zgodnie z art. 6 ust. 1 lit. b RODO przez okres niezbędny dla realizacji Twojego zgłoszenia. Wszelkie informacje w zakresie przetwarzania podanych przez Ciebie w formularzu danych oraz posiadanych uprawnieniach znajdziesz w Polityce prywatności. Kliknij i dowiedz się więcej jeżeli informacje podane powyżej nie są dostatecznie jasne!