Wieloskładnikowe uwierzytelnianie jest rozwiązaniem, które zdecydowanie zwiększa bezpieczeństwo kont użytkowników w naszej organizacji. Nie jest to też nowość dla zdecydowanej większości osób, ponieważ każdy z nas mógł się spotkać z wymaganym potwierdzeniem przelewu w banku za pomocą kodu SMS. Dzięki temu, odpowiednio zaplanowane wdrożenie MFA w firmie nie powinno przysporzyć większych problemów, a zdecydowanie zwiększy bezpieczeństwo danych firmowych.

Z tego względu, w tym artykule opisane zostały niezbędne kroki konfiguracji środowiska KEMP wraz z Office 365. Pozwala to na wykorzystanie logowania chmurowego jako sposobu uwierzytelniania użytkowników do LoadBalancer’a KEMP, który następnie przekazuje połączenie do docelowych serwerów – w tym przypadku są to serwery Exchange.

1.    Środowisko testowe

W środowisku, które zostało wykorzystane do przetestowania scenariusza, wykorzystany został serwer wirtualny KEMP oraz serwer Exchange 2019.

Publikacja Exchange odbywa się przez serwer KEMP i jest dostępna pod adresem mail2.apn365demo.pl

Lokalne środowisko zostało skonfigurowane na domenie apn365demo.local

UWAGA

Serwer KEMP musi posiadać licencje Enterprise lub Enterprise Plus ze względu na wykorzystanie mechanizmu ESP (Edge Security Pack).

1.1.     Schemat rozwiązania

Poniższy, bardzo prosty rysunek, przedstawia sposób w jaki przebiega uwierzytelnianie użytkownika w opisywanym scenariuszu.

Użytkownik wchodząc na adres mail2.apn365demo.pl, jest przekierowywany na serwer KEMP (1). KEMP w konfiguracji Virtual Services, posiada wpisane ustawienia przekierowujące użytkownika do ekranu logowania Azure (2). Po prawidłowym uwierzytelnieniu (3), KEMP przekierowuje użytkownika na serwer Exchange (4) i za pomocą odpowiednio skonfigurowanego mechanizmu SSO w przeglądarce internetowej, użytkownik jest od razu uwierzytelniany do serwera Exchange.

2.    Konfiguracja krok po kroku

Przed przystąpieniem do konfiguracji, należy upewnić się, że wszyscy użytkownicy posiadają zsynchronizowane konta do Office 365 z lokalnego AD. W innym przypadku, użytkownik nie będzie mógł zalogować się do lokalnego OWA za pomocą swojego konta.

2.1.     Dodanie konfiguracji KEMP w Azure

Pierwszym krokiem, jest dodanie aplikacji KEMP w panelu administracyjnym Azure w zakładce Aplikacje dla przedsiębiorstw. Jest to aplikacja bezpośrednio dostępna do wyszukania z listy dostępnych aplikacji Azure.

2.1.1   Konfiguracja Azure SSO

W aplikacji KEMP, w zakładce SSO należy wybrać metodę SAML.

W pierwszym kroku Podstawowa konfiguracja protokołu SAML, należy wpisać adres pod jakim ma być dostępna OWA. W tym przykładzie jest to wcześniej wspomniany adres mail2.apn365demo.pl i taki też musi zostać wprowadzony w dwa pola: Identyfikator oraz Adres URL odpowiedzi.

W kroku 3 Certyfikat podpisywannia SAML należy pobrać Certyfikat (base64) oraz Kod XML metadanych federacji.

W kroku 4 podane są adresy URL, które będą w następnych krokach wykorzystane w konfiguracji KEMP.

2.2.     Konfiguracja KEMP

Po skonfigurowaniu aplikacji w Azure, przechodzimy do konfiguracji serwera KEMP.

2.2.1.   Konfiguracja wirtualnych serwisów

W wirtualnych serwisach, zależnie od aktualnej konfiguracji, powinny znajdować się serwisy odpowiedzialne za publikację serwerów Exchange.

W środowisku testowym, zostały one skonfigurowane zgodnie z poniższym rysunkiem, z czego serwis Exchange 2019 INTERNAL jest tym, który został zmodyfikowany na potrzeby logowania OWA przez Azure.

W serwisach został wykorzystany certyfikat *.apn365demo.pl i ten sam certyfikat jest głównym certyfikatem na serwerach Exchange. Jest on podłączony w opcji SSL Properties

2.2.2.   Wgranie certyfikatu z chmury

Wcześniej pobrany z aplikacji Azure certyfikat, należy wgrać w konfigurację KEMP jako Intermediate Certs w zakładce Certificates & Security. Na poniższym rysunku jest to certyfikat AzureADCert2.pem

2.2.3.   Konfiguracja SSO

Następnym krokiem jest konfiguracja uwierzytelniania do chmury, tak aby KEMP przekazywał prawidłowo komunikację do wcześniej skonfigurowanej aplikacji w Azure. W tym celu w zakładce Virtual Services w opcji Manage SSO, należy utworzyć new Client Side Configuration.

Należy zaznaczyć SAML jako Authenticationn Protocol i w MetaData File wgrać plik XML pobrany wcześniej z aplikacji Azure. Wgranie tego pliku, powinno spowodować automatyczne wypełnienie trzech adresów URL, tak jak na powyższym rysunku. Należy również ręcznie zanzaczyć w polu IdP Certificate przed chwilą wgrany certyfikat z Azure oraz upewnić się, że w polu SP Entity ID jest prawidłowo wpisany adres do OWA.

2.2.4.   Zmiana sposobu uwierzytelniania

UWAGA

W tym kroku zmieniony zostanie sposób uwierzytelniania się do serwera KEMP. Będzie to miało bezpośredni wpływ na logowanie użytkowników, więc ten krok jak i kolejne, najlepiej wykonać w zaplanowanym wcześniej oknie serwisowym.

W wirtualnym serwisie odpowiedzialnym za publikację KEMP, czyli w tym scenariuszu jest to Exchange 2019 INTERNAL, należy wykonać 2 zmiany.

1. W subVS Authentication Proxy należy usunąć Real Servers. W tym celu po wejściu do danego Virtual Services, należy w zakładce SubVSs przejść do Authentication Proxy.

Następnie należy usunąć wszystkie serwery z tego miejsca.

2. Należy w SubVSs OWA zmienić opcje ESP.

Należy włączyć opcję ESP i w Client Authentication Mode zaznaczyć SAML, w SSO Domain wybrać wcześniej utworzoną konfigurację SSO, a w Allowed Virtual Host wprowadzić adres pod którym dostępny jest Exchange (OWA), czyli w tym scenariuszu mail2.apn365demo.pl. Jeżeli adresów dostępowych jest kilka, można każdy z nich wprowadzić oddzielone spacją.

Po wykonaniu powyższych kroków, wchodząc na stronę mail2.apn365demo.pl wyświetlone zostanie okno logowania do chmury Office 365 i przekierowani zostajemy do strony login.microsoftonline.com.

2.2.5.   Konfiguracja uwierzytelniania Kerberos

Do tego momentu został skonfigurowany „przód” systemu uwierzytelniania, odpowiedzialny za przekierowanie logowania do chmury. W następnych krokach skonfigurowane zostanie uwierzytelnianie użytkowników między serwerem KEMP, a serwerami Exchange.

W tym celu, należy w AD utworzyć konto użytkownika z nigdy nie wygasającym hasłem. Konto nie musi być synchronizowane do chmury i będzie wykorzystane w konfiguracji KEMP. W tym scenariuszu, utworzone zostało konto kemp-aad z adresem UPN domeny lokalnej.

Następnie w edytorze atrybutów, należy w polu servicePrincipalName wpisać http/<nazwa konta>, czyli http/KEMP-AAD

Po wprowadzeniu i zapisaniu zmian, należy zamknąć okno z edycją użytkownika, otworzyć je ponownie i przejść do zakładki Delegation. W tym miejscu należy zaznaczyć Trust this user for delegation to specified services only i poniżej Use any authentication protocol. Następnie należy zaznaczyć przycisk Expanded i poprzez przycisk Add… należy oddać wszystkie serwery Exchange po usłudze http. W tym scenariuszu jest to jeden serwer o nazwie A3D-EX19, co jest widoczne na rysunku poniżej.

2.2.6.   Konfiguracja integracji Azure AD z KCD (Kerberos Delegation Accounts)

W zakładce Manage SSO należy dodać Server Side Single Sign On. W konfiguracji należy wybrać kolejno:

• Kerberos Constrained Delegation
• Kerberos Realm – należy wpisać domenę lokalną AD
• Kerberos Key Distribution Center – po spacji należy wpisać adresy IP kontrolerów domeny
• Kerberos Trusted User Name – login utworzonego przed chwilą użytkownika
• Kerberos Trusted User Password – hasło utworzonego przed chwilą użytkownika

Ostatnim krokiem jest wprowadzenie skonfigurowanego Server Side SSO do konfiguracji ESP. W tym celu należy wrócić do SubVSs OWA i w opcjach ESP zaznaczyć Server Authentication Mode jako KCD oraz w Server Side Configuration, przed chwilą utworzoną konfigurację SSO.

2.3.     Konfiguracja Exchange

Należy upewnić się czy serwery Exchange zezwalają w katalogu wirtualnym OWA na WindowsAuthentication. Można to zweryfikować komendą PowerShell:

Get-OwaVirtualDirectory | fl *auth*

 3. Konfiguracja przeglądarek do użycia SSO

Zależnie od wykorzystywanych przeglądarek w organizacji, konfiguracja SSO może wyglądać inaczej. W przypadku braku konfiguracji SSO do określonego typu przeglądarki, może wystąpić sytuacja w której po wejściu na mail2.apn365demo.pl użytkownik musi zalogować się dwukrotnie – raz do Azure i raz do lokalnego OWA.

Przykładowo w konfiguracji Internet Explorer, należy w ustawieniach przejść do zakładki Security, wybrać Local intranet, kliknąć przycisk Sites i Advanced. W tym miejscu należy wpisać *.apn365demo.pl.

Następnie po powrocie do głównego okna, przejść do zakładki Advanced i upewnić się, że opcja Enable Integrated Windows Authentication jest włączona.

Powyższa konfiguracja pozwala skonfigurować SSO na jednej stacji użytkownika. Istnieje możliwość wykorzystania polityk GPO do tego celu, jednak każda przeglądarka posiada oddzielne reguły GPO, która wymagają skonfigurowania do prawidłowego działania. Przykładowo dla przeglądarki Internet Explorer należy wykorzystać wbudowane w Active Directory reguły.

Należy utworzyć nową politykę i przejść do ścieżki Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Internet Explorer -> Internet Control Pane -> Security Page i wybrać politykę Site to Zone Assignment List.

Następnie w polityce w polu Value name należy wprowadzić adres mail2.apn365demo.pl lub *.apn365demo.pl, a w polu Value wartość „1”.

4.    Konfiguracja MFA

Po prawidłowej konfiguracji wszystkich powyższych kroków, użytkownicy zaczną logować się do lokalnego OWA poprzez Azure. Dzięki temu, możemy wymusić MFA przy każdym logowaniu lub w przypadku posiadania licencji Azure AD Premium P1, wykorzystać w tym celu Conditional Access.

5.    Podsumowanie

Wykonanie opisanej konfiguracji wymaga odpowiedniego zaplanowania prac, jednak większość konfiguracji może zostać wykonana bez wpływu na pracę użytkowników. Przykładowo, polityki GPO oraz weryfikacja serwera Exchange może zostać wykonana przed zmianą sposobu uwierzytelniania użytkowników.

Samo w sobie wdrożenie, może zostać też w szybki sposób wycofane, poprzez wykorzystanie kopii zapasowej konfiguracji serwera KEMP. Aplikacja Azure nie ma wpływu na działanie lokalnego środowiska do momentu zmiany „przodu” uwierzytelniania KEMP, który to przekierowuje logowanie do chmury Office 365.