W poprzednim artykule wspomniałem o możliwości całkowitego wyłączenia polityk wygasania haseł pod warunkiem posiadania dodatkowych środków technicznych, które zapewnią ochronę organizacji przed słabymi hasłami, ich nowymi kombinacjami oraz takimi, które już wyciekły. Wśród cytowanych rekomendacji pojawiła się enigmatyczna usługa Azure AD Microsoft Entra Password Protection, która według Microsoftu ma być “lekarstwem” na te problemy. Czy rzeczywiście jest skuteczna? Przekonajmy się!
Czym jest Azure AD Microsoft Entra Password Protection?
Najprościej rzecz ujmując Azure AD Microsoft Entra Password Protection to po prostu lista zakazanych haseł (globalna oraz nasza własna), która jest sprawdzana za każdym razem, gdy użytkownik ustawia lub resetuje hasło. Jeśli Microsoft wykryje, że pracownik próbuje użyć słabego hasła lub takiego, które było już wcześniej częścią wycieku danych, operacja zostanie zablokowana, a firma ochroni się przed własnymi pracownikami 🙂
Architektura rozwiązania
Microsoft Entra
Jeśli używasz tylko kont w chmurze (cloud-only), to sprawa jest prosta. Rozwiązanie Azure AD Microsoft Entra Password Protection domyślnie już chroni Twoje konta, nie musisz nic robić. Sprawdź jednak, czy domyślne ustawienia są dla Ciebie wystarczające. Możesz na przykład dodać swoje własne niestandardowe frazy do globalnej listy haseł Microsoftu.
Active Directory Domain Services (AD DS)
W tym konkretnym scenariuszu, aby uruchomić Azure AD Microsoft Entra Password Protection, będziemy potrzebować dodatkowych agentów na kontrolerach domeny oraz co najmniej jednego serwera proxy. Serwer Proxy odpowiedzialny jest za pobranie polityk w tym bazy zakazanych haseł z Azure AD Microsoft Entra ID. Z kolei Agent pobiera ustawienia z serwera proxy lokalnie, co jest dość istotne z punktu bezpieczeństwa kontrolerów domeny, ponieważ eliminuje potrzebę ich bezpośredniego dostępu do Internetu.
Wymagania i ogólne uwagi
Podczas wdrożenia Azure AD Microsoft Entra Password Protection warto wziąć pod uwagę następujące kwestie:
- Na każdym kontrolerze domeny, które nie jest Read Only Domain Controller (RODC) musimy zainstalować agenta usługi. Na dodatek instalator będzie wymagał restartu maszyny, więc warto dobrze to zaplanować.
- Komponent Proxy może być zainstalowany na kilku serwerach w celu zapewnienia wysokiej dostępności (High Availability). Zgodnie z zaleceniami Microsoftu, dwie maszyny powinny nam wystarczyć.
- Jeśli nastąpi kataklizm i wszystkie serwery proxy przestaną działać to… Nic się nie stanie, ponieważ kontrolery domeny z zainstalowanym agentem Password Protection przechowują lokalnie kopie chmurowej polityki haseł. Oczywiście naszym priorytetem jest niedopuszczenie do takiej sytuacji, ale mała niedostępność serwera nie sparaliżuje nam środowiska :winking_face:
- Agent nie wymaga połączenia z Internetem, więc nie musimy więc otwierać komunikacji kontrolerów domeny na świat.
- Komponent Proxy wymaga połączenia z Internetem, ale możemy je ograniczyć tylko do niezbędnej komunikacji serwera z
AzureEntra. - Jeśli szukasz odpowiedniego serwera na dodatkową rolę, to nie instaluj komponentu proxy na serwerze z
Azure ADMicrosoft Entra Application Proxy. - Proxy posiada opcję auto-upgrade, więc nie musimy martwić się o jego aktualność. Z kolei za aktualność agentów na kontrolerach domeny musimy zatroszczyć się sami.
- Upewnij się, że posiadasz Windows Server 2012 R2 lub nowszy, bo inaczej to nie zadziała :winking_face:
Wszystkie wymagania techniczne dostępne są na Microsoft Docs. Znajdziesz tam również listę portów, protokołów i endpointów, o które z pewnością zapyta Twój Network Administrator.
Wymagania licencyjne
Dlaczego wymagania licencyjne mają oddzielny akapit? Bo łatwo je przeoczyć 🙂
Wychodzi na to, że jeśli chcemy wdrożyć Azure AD Microsoft Entra Password Protection dla kont on-premises to powinniśmy posiadać Azure AD Premium Microsoft Entra ID przynajmniej w planie P1.
Interesujący jest również zapisek pod tabelką:
On-premises AD DS users that aren’t synchronized to Azure AD also benefit from
Azure ADMicrosoft Entra Password Protection based on existing licensing for synchronized users.
Oznacza to, że jeśli duża część naszych pracowników nie korzysta z Microsoft 365, to i tak będą potrzebować licencji Azure AD Microsoft Entra ID P1/P2. Ma to sens, ponieważ Azure AD Microsoft Entra Password Protection działa dla całej domeny bez możliwości tworzenia wyjątków.
Konfiguracja
Przed instalacją agenta i proxy warto upewnić się, że serwery, na których pracujemy, mają zainstalowane najnowsze aktualizacje (Universal C Runtime) oraz .NET Framework 4.7.2. Oba te składniki są wymagane do prawidłowego działania usługi Azure AD Microsoft Entra Password Protection.
Dodatkowo warto również sprawdzić, czy niezbędna komunuikacja sieciowa została wcześniej przygotowana i nie jest blokowana. Tak na wszelki wypadek, aby nie było niespodzanek podczas konfiguracji. Po więcej informacji raz jeszcze odsyłam do wymagań technicznych.
Azure AD Microsoft Entra Password Protection proxy service
Konfigurację rozpoczynamy od instalacji usługi proxy. Pobieramy instalator z Microsoft Download Center i przeprowadzamy instalację oprogramowania.
Po pełnym emocji procesie instalacji, na naszym serwerze powinien być dostępny nowy moduł PowerShell AzureADPasswordProtection. Warto sprawdzić, czy moduł importuje się bez błędów, a usługa proxy została poprawnie uruchomiona na serwerze.
| |
Teraz możemy zarejestrować nasz serwer proxy w Azure AD Microsoft Entra ID przy użyciu polecenia Register-AzureADPasswordProtectionProxy. Operację wykonujemy z uprawnieniami Global Administrator.
| |
Po poprawnym logowaniu na konto administratora nasz serwer zostanie zarejestrowany w Azure AD Microsoft Entra. Niestety nie otrzymamy żadnego ładnego komunikatu z informacją o sukcesie, ale możemy podejrzeć stan usługi proxy za pomocą kolejnego polecenia.
| |
Jak widać, usługa została poprawnie zarejestrowana i jest gotowa do działania. No prawie… Potrzebujemy jeszcze jednorazowo zarejestrować nasz las Active Directory w Azure Entra. Proces rejestracji jest taki sam jak poprzednio, różni się tylko polecenie.
| |
Teraz możemy przejść do instalacji agenta na kontrolerze domeny.
Azure AD Microsoft Entra Password Protection DC agent
Instalacja agenta na kontrolerze domeny jest znacznie prostsza. Pobieramy instalator DC Agent i uruchamiamy plik.
Po standardowym procesie instalacji otrzymamy komunikat o konieczności zrestartowania serwera.
To tyle? Tak, po restarcie nasz agent jest już w pełni funkcjonalny i nie wymaga żadnej dodatkowej konfiguracji 🙂
Stan agenta możemy też zweryfikować poleceniem Test-AzureADPasswordProtectionDCAgentHealth
| |
Domyślnie Azure AD Microsoft Entra Password Protection po zainstalowaniu agentów i proxy nie wymusza ochrony. Możemy to zmienić w portalu Azure Entra. Przejdźmy zatem do ustawień usługi i zobaczmy co możemy skonfigurować.
Microsoft Azure Entra admin center
Ustawienia Azure AD Microsoft Entra Password Protection znajdziemy w zakładce Security -> Authentication methods -> Password protection w Azure AD Microsoft Entra.
Aby przetestować usługę, zaznaczamy opcję Enforce custom list oraz dodajemy własne “zakazane frazy”. Domyślnie Azure AD Microsoft Entra Password Protection działa w trybie audytu, co oznacza, że nie blokuje “zakazanych haseł”, ale rejestruje takie operacje w dzienniku zdarzeń. Zmieniamy to konfiguracją wartości Mode na Enforced.
Zapisujemy i gotowe. Od teraz, gdy tylko ustawienia zostaną rozpropagowane w domenie słabe hasła będą automatycznie blokowane.
Testy Azure AD Microsoft Entra Password Protection
Wymuszenie aktualizacji polityk
Jeśli nie chcemy czekać na automatyczne odświeżenie polityk to możemy zmusić nasze serwery do pobrania najnowszych polityk. Oczywiście możemy poczekać kilka minut lub godzin, ale kto ma na to czas? 🙂
Logujemy się na nasz testowy kontroler domeny, uruchamiamy CMD i restartujemy agenta Password Protection poniższym poleceniem:
| |
Następnie przeszukujemy dziennik zdarzeń i szukamy zdarzenia o ID 30006.
Applications and Services Log > Microsoft > AzureADPasswordProtection > DCAgent > Admin
Jak widać nasza polityka opuściła tryb AuditOnly i jest gotowa do testów.
Test zbanowaych haseł
Zanim rozpoczniemy testy, warto zastanowić się, w jaki sposób Microsoft blokuje “słabe” hasła. Zrozumienie systemu oceny haseł może mieć drastyczny wpływ na wyniki Twoich testów oraz może zaoszczędzić Ci godzin troubleshooting-u ustawień 🙂
Procedura oceny dostępna jest pod linkiem How are passwords evaluated.
Przy krótkich słowach takich jak moje, testy mogą być naprawdę trudne, ponieważ dokładając nowe słowo do “zakazanego” algorytm może uznać hasło za dozwolone.
Even if a user’s password contains a banned password, the password may be accepted if the overall password is otherwise strong enough. A newly configured password goes through the following steps to assess its overall strength to determine if it should be accepted or rejected
— Microsoft Docs - Eliminate bad passwords using Azure Active Directory Password Protection
Wyświetlane komunikaty o blokadzie hasła również nie ułatwiają sprawy. Microsoft poszedł tutaj na łatwiznę i wykorzystał dotychczasowe komunikaty, przez co nie wiadomo czy nasze hasło jest blokowane przez wbudowane polityki, czy przez Azure AD Microsoft Entra Password Protection…
Jak wyglądają takie komunikaty?
Perspektywa administratora
Perspektywa użytkownika
Jak sprawdzić czy nasze hasło zostało zablokowane przez Azure AD Microsoft Entra Password Protection?
Nie wyciągamy zbyt wiele z komunikatów, dlatego potrzebujemy lepszej metody weryfikacji, co zablokowalo nasze hasło.
Jak się okazuje najlepszą metodą jest… dziennik zdarzeń na kontrolerze domeny z agentem Azure AD Microsoft Entra Password Protection.
Pełna lista interesujących nas identyfikatorów dostępna na Microsoft Docs.
Alternatywnie możemy wygenerować ogólne statystyki usługi przez PowerShell.
| |
Rozwiązanie bez wad?
Testy zakończone, więc czas trochę ponarzekać. Generalnie do usługi mam dwa zastrzeżenia.
Po pierwsze, nie znamy treści Global banned password list, więc musimy zaufać Microsoftowi, że jego autorska lista jest na bieżąco aktualizowana i rzeczywiście zapewnia nam ochronę. Nie każdemu może się to podobać.
…Cyber-criminals also use similar strategies in their attacks to identify common weak passwords and variations. To improve security, Microsoft doesn’t publish the contents of the global banned password list…
…The global banned password list isn’t based on any third-party data sources, including compromised password lists…
— Microsoft Docs - Eliminate bad passwords using Azure Active Directory Password Protection
Po drugie, Azure AD Microsoft Entra Password Protection nie zablokuje haseł, które zostały już ustawione w domenie. Działa wyłącznie w przypadku zmiany lub resetu hasła po uruchomieniu usługi. Jeśli pracownikowi udało się wcześniej ustawić hasło dupa123, to będzie ono działało dalej, aż do następnej zmiany.
Psst!… Jeśli szukasz sposobu na audyt wyciekniętych haseł w Twojej domenie, to opisałem go w tym wpisie.
Podsumowanie
Dzisiaj dowiedzieliśmy się nieco więcej o usłudze Azure Active Directory Microsoft Entra Password Protection. Pozostała jedynie kwestia, czy warto ją wdrożyć w Twojej firmie? Moim zdaniem, jak zwykle to zależy.
Jeśli posiadasz środowisko lokalne i licencjonujesz wszystkich pracowników AAD Premium, dlaczego by nie skorzystać z tej usługi? Przecież to coś, co już masz od dawna w swoich licencjach, co może zwiększyć bezpieczeństwo Twojej firmy.
Natomiast, jeśli wdrożenie wymaga dodatkowych zakupów, może warto rozważyć moje narzekania jako argument do przeprowadzenia research rynku i poszukania rozwiązań third-party?
Wybór zależy od Ciebie lub Twojego IT Managera 🙂
Dodatkowe materiały
- Microsoft Docs - Plan and deploy on-premises Azure Active Directory Password Protection
- Microsoft Docs - Eliminate bad passwords using Azure Active Directory Password Protection
- Microsoft Docs -Monitor and review logs for on-premises Azure AD Password Protection environments
- Microsoft Docs - Azure AD Password Protection on-premises FAQ