AD FS jest przykładem bardzo ciekawej usługi, którą można wykorzystać do obsługi logowania do innych aplikacji przy zastosowaniu podejścia SSO (Single Sign-On) kontami domenowymi Active Directory. Z samej definicji wynika, że najlepszym środowiskiem do wdrożenia AD FS będą wewnętrzne sieci korporacyjne, natomiast technicznie można bez większych przeszkód przeprowadzić integrację także z publicznie dostępnymi usługami (wtedy oczywiście AD FS musi być zewnętrznie udostępnione – logowanie odbywa się na osobnej domenie).
Scentralizowane logowanie jest bardzo dobrą praktyką bezpieczeństwa, a dodatkowo ułatwia codzienne zarządzanie użytkownikami. Przykładowo po zatrudnieniu nowego pracownika nie będzie potrzeby ręcznego zakładania kont w każdym możliwym systemie działającym w firmie – dzięki rozwiązaniom SSO proces ten przebiegnie zdecydowanie sprawniej. Użytkownik z kolei nie będzie zmuszony do ustawiania różnych haseł do wielu systemów, ponieważ w każdym będą stosowane poświadczenia domenowe – tutaj zalecany jest hardening wymagań złożoności haseł oraz ich rotacji w zasadach grupy.
Można wyobrazić sobie również sytuację, w której konto pracownika zostanie przejęte lub w inny sposób naruszone. Po wykryciu incydentu wystarczy zmienić jedno hasło, aby całkowicie zablokować dostęp. Logowanie domenowe powinno być stosowane w każdym systemie obsługującym taką integrację.
Konfiguracja podstawowej instancji AD FS nie powinna sprawiać trudności. Odmienna sytuacja jest niestety z integracją aplikacji. Istnieją jednak gotowe rozwiązania, a część zewnętrznych aplikacji posiada instrukcje dodania logowania przez AD FS w swojej dokumentacji.
AD FS działa na systemach Windows Server i wymaga dostępu do istniejącej domeny Active Directory oraz standardowego certyfikatu SSL (w formacie PFX) używanego do komunikacji (CN musi odpowiadać nazwie domeny, pod którą odbywać się będzie logowanie). Serwer z AD FS musi również być członkiem domeny AD. Najlepiej dodać też „użytkownika technicznego” dedykowanego dla AD FS – tutaj nazwałem to konto adfs_user – w grupie Domain Admins. Certyfikat SSL musi znajdować się w magazynie Personal, dlatego dla zachowania porządku na serwerach polecam utworzyć użytkownika jednoznacznie powiązanego z AD FS.
W tym poradniku pokażę również świetny sposób integracji istniejącej witryny WordPress z logowaniem AD FS przy użyciu wtyczki SAML Single Sign On – SSO Login – członkowie domeny Active Directory będą mogli logować się do Kokpitu z wykorzystaniem swoich poświadczeń domenowych.
Dla naszego scenariusza AD FS będzie dostępne w ramach domeny login.avlab.pl. Przygotowana witryna WordPress działa pod domeną app.avlab.local.
Po zalogowaniu na serwerze jako adfs_user pierwszym i kluczowym krokiem jest dodanie certyfikatu domeny AD FS do magazynu Personal. Wymagany jest format PFX – nawet jeśli posiadamy certyfikat w innym formacie, to bardzo łatwo można dokonać konwersji przykładowo z użyciem narzędzia openssl. Istotne jest, aby w Certificate Import Wizard zaznaczyć opcję Mark this key as exportable.
Instalacja AD FS ogranicza się do użycia powszechnie znanej funkcji Add roles and features w Server Manager. Wystarczy zaznaczyć Active Directory Federation Services w zakładce Select server roles. Dalsze kroki sprowadzają się do klikania przycisków Next i ostatecznie Install.
Po zakończeniu instalacji pozostaje właściwa konfiguracja nowej roli. W tym celu wybieramy z poziomu Server Manager ikonę flagi i najpewniej jedyną widoczną opcję, czyli Configure the federation service on this server.
Jak można się domyślić, w otwartym oknie przy pierwszej zakładce pozostawiamy zaznaczenie przy opcji Create the first federation server in a federation server farm. Po przejściu do kolejnej zakładki jako użytkownik powinien być wskazany adfs_user – jeśli tak właśnie jest, to można kontynuować. Teraz w Specify Service Properties wystarczy wskazać dodany wcześniej certyfikat (nie będzie zresztą innego możliwego wyboru) i ustalić „przyjazną” nazwę usługi.
Po kliknięciu Next w następnym kroku pojawi się błąd Group Managed Service Accounts are not available because the KDS Root Key has not been set. Rozwiązanie nie jest szczególne złożone. Wystarczy uruchomić PowerShell jako administrator, po czym wykonać
Add-KdsRootKey -EffectiveImmediately
Następnie wrócić do poprzedniej zakładki i ponownie przejść do bieżącej. Błąd nie powinien już się pojawiać. Teraz należy przy opcji Use an existing domain user account or group Managed Service Account wybrać Select… i podać poświadczenia domenowe dla użytkownika adfs_user.
Pojawi się pytanie dotyczące używanej bazy danych. Dostępne są dwie opcje – Windows Internal Database i SQL Server. W przypadku wewnętrznych wdrożeń o mniejszej złożoności nic nie stoi na przeszkodzie, aby wykorzystać prostsze rozwiązanie, czyli Windows Internal Database. Następnie pozostanie sprawdzić ustawienia, które zostaną zastosowane i wykonać weryfikację wymagań w kolejnym kroku, a ostatecznie kliknąć przycisk Configure. Okno będzie można zamknąć po zakończeniu konfiguracji.
Należy zwracać uwagę na aktualność certyfikatu SSL (sprawdzi się nawet prosty monitoring np. z użyciem przygotowanego template dostępnego w Zabbix) i odnawiać go przed datą wygaśnięcia. Procedura dodania nowego certyfikatu do magazynu Personal jest analogiczna. Podmianę w AS FS najszybciej można zrealizować poprzez PowerShell – na tej stronie podano świetny opis całego procesu. Ten sam efekt można osiągnąć poprzez podmianę certyfikatu w trybie graficznym w przystawce AD FS Management (AD FS -> Service -> Certifcates).
Usługa po stronie serwera jest już gotowa do obsługi logowania. Jednak przed konfiguracją powiązania z aplikacją warto dostosować wygląd interfejsu webowego. Wszelkie modyfikacje przeprowadza się w PowerShell uruchomionym na prawach administratora. Na początku za pomocą polecenia Get-AdfsWebTheme należy ustalić nazwę domyślnie zastosowanej theme – obecnie to wciąż DefaultAdfs2019.
Tworzymy, aktywujemy nowy motyw (jego zastosowanie można śmiało porównać do motywu potomnego znanego z WordPress) i stronę logowania, po czym restartujemy usługę AD FS:
New-AdfsWebTheme -Name login_avlab -SourceName DefaultAdfs2019
Set-AdfsWebConfig -ActiveThemeName login_avlab
Set-AdfsProperties -EnableIdPInitiatedSignonPage $true
Restart-Service adfssrv
Po wejściu na https://DOMENA/adfs/ls/idpinitiatedsignon powinniśmy zobaczyć komunikat wyglądający podobnie do poniższego.
Można wykonać testowe logowanie danymi domenowymi dowolnego użytkownika.
Pliki motywu muszą znajdować się w osobnym folderze – u nas jest to C:\login_avlab. Ścieżkę do tej lokalizacji trzeba wskazać przy użyciu polecenia
Export-AdfsWebTheme -Name login_avlab -DirectoryPath "C:\login_avlab"
Oprócz tego należy zapewnić dostęp do tego zasobu (włączając w to podfoldery i pliki w nich zawarte) dla użytkownika AD FS.
Pewnie najbardziej widoczną modyfikacją będzie zmiana tła. W tym celu wystarczy zmodyfikować obraz illustration.png znajdujący się w folderze illustration w strukturze folderu z motywem – w naszym środowisku jest to plik C:\login_avlab\illustration\illustration.png. Po zapisaniu zmian trzeba tylko wskazać położenie pliku poleceniem
Set-AdfsWebTheme -TargetName login_avlab -Illustration @{path="C:\login_avlab\illustration\illustration.png"}
Restart usługi nie jest potrzebny.
Wartą wspomnienia możliwość stanowi też dodanie logo. Dla zachowania porządku w folderze z motywem proponuje utworzyć w nim folder logo, a w nim zapisać wybrany przez nas plik pod dowolną nazwą. Aby ustawić przygotowaną grafikę, musimy skorzystać z poniższej komendy
Set-AdfsWebTheme -TargetName login_avlab -Logo @{path="C:\login_avlab\logo\logo.png"}
Z innych użytecznych zmian do wprowadzenia można wymienić dodanie własnego komunikatu przy logowaniu. Myślę, że wyjątkowo przydatne będzie dodanie linku do formularza zmiany hasła. W AD FS ta funkcjonalność domyślnie jest zablokowana (po wejściu na https://DOMENA/adfs/portal/updatepassword pojawi się zwyczajna strona błędu). W celu umożliwienia zmiany hasła należy wejść w AD FS Management -> Service -> Endpoints (polecam zapoznać się z całą listą adresów widoczną w tej karcie) i na samym dole w sekcji Other wybrać /adfs/portal/updatepassword/, a w menu obok kliknąć Enabled. Będzie wymagany restart, o czym poinformuje odpowiedni komunikat.
Wspomniany odnośnik można dodać tym sposobem:
Set-AdfsGlobalWebContent -SignInPageDescriptionText "<p>Zmiana hasła <a href="https://login.avlab.pl/adfs/portal/updatepassword">tutaj</a>.</p>"
Można przystąpić do konfiguracji integracji systemu WordPress z AD FS. Po wejściu do ustawień wymienionej wyżej wtyczki SAML Single Sign On – SSO Login pobieramy Metadata XML File. Zapisujemy tę treść w pliku XML w wybranym folderze na serwerze z AD FS. Dalej w AD FS Management przechodzimy do Relying Party Trusts i wybieramy Add Relying Party Trust… Przy pierwszej zakładce pozostawiamy opcję Claims aware i klikamy przycisk Start. Dalej zaznaczamy checkbox Import data about the relying party from a file i wskazujemy lokalizację zapisanego pliku XML.
Następnie ustalamy nazwę dla tworzonego relying party, zezwalamy na dostęp dla wszystkich (Permit everyone) i przechodzimy wizard do końca (pozostawiając domyślne wybory).
Teraz musimy dostosować konfigurację w Edit Claim Issuance Policy… pod wymagania konkretnej aplikacji. Odpowiednie i działające kroki dla WordPress są następujące – dwie osobne reguły:
- Send LDAP Attributes as Claims
- Transform an Incoming Claim
których dokładne konfiguracje widać poniżej.
Pozostaje dokończyć integrację w ustawieniach wtyczki, przechodząc do karty IDP Configuration, gdzie (z bardzo rozbudowanej listy) wybieramy pierwszą pozycję – ADFS. Dane możemy uzupełnić na podstawie pliku https://DOMENA/federationmetadata/2007-06/federationmetadata.xml bądź zaimportować pobrany plik, a nawet podać adres URL do pliku, aby skrypt automatycznie uzupełnił wartości. Z wyjątkiem certyfikatu i (wybranej przez nas dowolnej) nazwy usługi pozostałe opcje będą zawsze takie same.
Przyciskiem Save zapisujemy konfigurację i weryfikujemy działanie wybierając Test Configuration. Nie powinniśmy napotkać żadnych problemów.
Wtyczka modyfikuje wygląd strony logowania do Kokpitu WordPress.
Logowanie odbywa się na dedykowanej domenie.
Dodatkowo po wejściu na https://DOMENA/adfs/ls/idpinitiatedsignon pojawi się możliwość wylogowania.
Active Directory Federation Services stanowi wygodną, prostą w uruchomieniu usługę SSO, która świetnie sprawdzi się przede wszystkim w sieciach wewnętrznych. To dojrzałe rozwiązanie, w pełni gotowe do zastosowań produkcyjnych. Wdrożenie logowania SSO przynosi wiele korzyści z punktu widzenia bezpieczeństwa, ale także wygody dla użytkowników i administratorów.
