Dlaczego warto włączyć Self-Service Password Reset (SSPR)

Pewnie nie raz zdarzyło Ci się zresetować hasło do swojego konta lub konta kogoś z Twojej firmy. Choć na pierwszy rzut oka taka zmiana wydaje się błahostką, to w rzeczywistości wiąże się z pewnego rodzaju ryzykiem oraz jest… wielką stratą czasu. Dziś przedstawię Ci kilka argumentów przemawiających za wdrożeniem Self-Service Password Reset (SSPR) – rozwiązania, które może usprawnić proces zmiany haseł w Twojej firmie. Pokażę Ci także, jak to skonfigurować, tak aby wszyscy byli zadowoleni :winking_face:

Czym jest Self-Service Password Reset (SSPR)?

Self-Service Password Reset (SSPR), a po polsku samoobsługowe resetowanie haseł, to jedna z funkcjonalności Entra ID, która umożliwia Ci zresetowanie Twojego hasła w przypadku jego zapomnienia lub zapicia (smutków i hasła). Jeśli jesteś introwertykiem tak jak ja, to na pewno nienawidzisz dzwonić do innych ludzi. Dzięki SSPR możesz zresetować swoje hasło bez konieczności telefonu do działu IT. Naprawdę wygodna funkcjonalność! Liczyłeś/aś na dłuższy opis? Muszę Cię rozczarować, bo wyjątkowo Self-Service Password Reset robi dokładnie to, na co wskazuje nazwa usługi.

Dlaczego warto włączyć SSPR?

No więc Panie Damianie, dlaczego warto włączyć Self-Service Password Reset? Słuchaj, mam dla Ciebie dwa dobre argumenty, dzięki którym polubisz SSPR:

Redukcja kosztów i zbędnej pracy IT

Każda operacja zmiany hasła pracownika, którą przeprowadza dział IT jest czasochłonna. W zależności od liczby pracowników, koszt tej zmiany może być naprawdę przerażający. Z drugiej strony, kolejna zmiana hasła tego samego pracownika po raz n-ty nie jest czynnością, którą szczególnie lubimy wykonywać. Dlatego wdrażając SSPR, możemy rozwiązać dwa problemy naraz 🙂

Naprawdę warto otworzyć Excela, zsumować liczbę ticketów i sprawdzić jako poważnym problemem jest w naszej firmie “ten problematyczny proces”.

Zwiększenie bezpieczeństwa

Jak coś tak prostego, jak możliwość samodzielnego zresetowania hasła przez pracowników może wpłynąć na bezpieczeństwo organizacji?

Powód nr1

Zacznijmy od tego, że zmiana hasła to proces bardzo podatny na inżynierię społeczną. Jak bezpiecznie potwierdzić tożsamość osoby, która właśnie straciła dostęp do swojego firmowego konta i dzwoni do nas telefonicznie? Przecież osoba odpowiedzialna za resetowanie haseł nie zna głosu każdego pracownika w firmie. Co więcej, narzędzia takie jak VALL-E od Microsoftu są w stanie imitować głosy innych ludzi, dysponując zaledwie kilkoma sekundami nagrania zwykłej rozmowy swojej “ofiary”. Pojawiają się kolejne pytania: w jakiej formie przekazać tymczasowe hasło?, jak upewnić się, że nasz pracownik od razu zmieni hasło po otrzymaniu tymczasowego? To tylko kilka z wielu zagadnień związanych z procesem resetu hasła. Nieprawidłowo zaprojektowany proces może prowadzić do katastrofy, a warto również zaznaczyć, że często taki proces po prostu nie istnieje lub nie jest nigdzie spisany…

Powód nr2

Nie wszyscy pracownicy obsługujący zgłoszenia powinni mieć możliwość zmiany haseł kont użytkowników. Wdrażając SSPR, możemy ograniczyć nadmiarowe uprawnienia oraz zminimalizować ryzyko przekupienia naszych pracowników działu wsparcia (można też im więcej płacić 🙃).

Powód nr3

Bo to rekomendacja Microsoftu, za którą otrzymujemy punkty w Secure Score. To tak jak z punktami lojalnościowymi, każdy lubi je zbierać.

Secure Score to narzędzie, które zawiera listę działań i rekomendacji mających na celu podniesienie poziomu bezpieczeństwa Twoich usług, takich jak Microsoft 365 lub Entra ID. Wykonanie tych zaleceń jest automatycznie mierzone i wyrażane punktowo, dzięki czemu możesz monitorować stan bezpieczeństwa swojej firmy i reagować na anomalie, takie jak użytkownicy bez włączonego MFA lub SSPR.

Gratulacje, właśnie zdobyłeś kolejny miernik bezpieczeństwa do swojej kolekcji. Pamiętaj, im więcej produktów Microsoftu wykorzystujesz, tym więcej zaleceń znajduje się w Secure Score!

Powód nr4

Wdrożenie innych produktów security od Microsoftu będzie znacznie prostsze. W portfolio Microsoftu znajduje się między innymi usługa Entra ID Protection, która w połączeniu z Conditional Access potrafi wymusić zmianę hasła użytkownika w przypadku, gdy jego działania lub parametry logowania (np. korzystanie z przeglądarki TOR) zostaną zaklasyfikowane jako ryzyko. Taka wymuszona zmiana hasła traktowana jest przez usługę jako środek obniżający zagrożenie związane z danym kontem. Jeśli nie korzystamy z SSPR, pracownik zobaczy smutny komunikat z informacją o blokadzie konta i pozostaje mu jedynie telefon do przyjaciela (działu IT).

Więcej informacji na temat Entra ID Protection znajdziesz w tym wpisie.

Dlaczego obawiasz się SSPR?

Gdyby SSPR nie miało wad, prawdopodobnie większość firm by je już wdrożyła. Poniżej znajdziesz kilka typowych “zarzutów” wobec SSPR, które usłyszałem w przeszłości wraz z moimi komentarzami.

Zarzut nr1

SSPR wymaga podania od użytkownika prywatnego adresu e-mail lub pytań bezpieczeństwa. Te metody wydają się ryzykowne, zwłaszcza w przypadku “mało rozgarniętych” pracowników.

Odpowiedź: Nie jesteśmy zmuszeni do korzystania z powyższych metod. To od nas zależy, z jakich metod SSPR będą mogli korzystać nasi pracownicy. Jeśli obawiasz się wykorzystania słabo zabezpieczonych prywatnych adresów e-mail, które są w pełni poza Twoją kontrolą, to zrezygnuj z tej opcji, albo wymagaj dwóch różnych metod potwierdzenia tożsamości podczas resetu hasła. Przykładowo wymagaj korzystania z aplikacji Microsoft Authenticator oraz z pytań bezpieczeństwa lub e-mail.

Zarzut nr2

Część naszych pracowników nie ma aplikacji Microsoft Authenticator, dlatego wdrożenie SSPR będzie uciążliwe.

Odpowiedź: W takim przypadku możesz rozważyć stosowanie wyłącznie jednej obowiązkowej metody wymaganej do resetu hasła, jednocześnie pozostawiając pracownikowi wybór spośród tych opcji, z których obecnie korzystasz.

Zarzut nr3

Proces rejestracji SSPR jest skomplikowany…

Odpowiedź: Proces rejestracji SSPR jest identyczny jak konfiguracja MFA. A przecież z MFA korzystasz, czyż nie?

Zarzut nr4

Mam środowisko hybrydowe, a tam SSPR nie działa!

Odpowiedź: Nieprawda, działa bardzo dobrze! Hybryda, mimo że brzmi strasznie, wymaga jedynie kilku dodatkowych kliknięć, o czym możesz przeczytać w dalszej części wpisu.

Jeśli Twojego pytania nie było na liście, to niestety, ale musisz samodzielnie przekonać Twojego “bezpiecznika”, zarząd, czy przełożonego. Trzymam za Ciebie kciuki 🤞

Wymagania techniczne SSPR

Nasze wymagania wdrożeniowe będą głównie zależne od dwóch elementów: posiadanych licencji oraz tego, czy mamy uruchomioną synchronizację tożsamości z lokalnym AD.

Licencje

Chyba nie zaskoczę Cię drogi czytelniku / czytelniczko tym, że Microsoft każe płacić nam 💲 za wygodny proces resetowania hasła. Jakich licencji potrzebujemy?

Tak więc, jeśli masz lokalną domenę, to musisz posiadać licencję Azure AD Premium Entra ID P1 lub P2, aby uruchomić SSPR. Na szczęście nie jest tak źle, ponieważ wystarczy nam tańsza licencja P1. Jeśli jesteś 100% cloud-first, to wystarczy Ci Microsoft 365 Business Standard.

Zawsze mogłoby być lepiej, ale biorąc pod uwagę fakt, że w Entra ID P1 mamy również Conditional Access, to zakładam, że większość firm spełnia powyższe wymagania.

Środowisko cloud-only

Jeśli nie posiadasz lokalnej domeny i operujesz wyłącznie na kontach cloud-only, to w zasadzie wystarczy, że włączysz SSPR w portalu Microsoft Entra admin center. Oczywiście przed uruchomieniem funkcjonalności, koniecznie przejrzyj domyślne ustawienia usługi!

Środowisko hybrydowe

Domyślnie hasła użytkowników Entra ID są zawsze zsynchronizowane “z dołu”, czyli z Active Directory. Musimy więc zmienić to zachowanie za pomocą opcji password writeback narzędzia Entra Connect. Po włączeniu password writeback zmiana hasła z poziomu chmury zostanie zsynchronizowana “z góry” do naszej lokalnej domeny. Dodatkowo konfiguracja może wymagać od Ciebie rozszerzenia uprawnień konta serwisowego Entra Connect o uprawnienia związane z resetem haseł.

Zrób to przed uruchomieniem SSPR

Konfiguracja Self-Service Password Reset to nie tylko opcje w panelach administracyjnych, ale także ludzie, którzy będą z nich korzystać. Przed uruchomieniem SSPR warto rozesłać “propagandę firmową”, czyli informacje o nowych możliwościach resetu haseł, jak również zaktualizować wszelkie procedury i instrukcje.

Nie masz pomysłu na własną kampanię reklamową? Skorzystaj z gotowców Microsoftu!

Konfiguracja - Jak uruchomić SSPR?

Panel konfiguracyjny Self-Service Password Reset znajduje się w Microsoft Entra admin center.

Dokładna ścieżka to: Protection -> Password reset

Sprawdźmy, jakie opcje są dla nas dostępne w poszczególnych zakładkach.

Metody uwierzytelniania (Authentication methods)

W zakładce Authentication methods ustawiamy dostępne metody potwierdzania tożsamości pracownika podczas resetu hasła oraz ich wymaganą ilość (1 lub 2 z nich).

Dostępne metody uwierzytelniania w portalu to:

• Mobile app notification - podczas zmiany hasła, pracownikowi wyświetli się alert w aplikacji Microsoft Authenticator, który będzie musiał potwierdzić lub odrzucić. Ta opcja nie jest dostępna w przypadku korzystania jedynie z jednej metody uwierzytelniania.
• Mobile app code - pracownik musi przepisać “kod hasła jednorazowego” z aplikacji Microsoft Authenticator (lub innej aplikacji, jeśli nie lubicie tej od Microsoftu), aby dokonać zmiany hasła. Kod w aplikacji zmienia się co 30 sekund.
• Email - podczas resetowania hasła użytkownik zostanie poproszony o podanie kodu jednorazowego, który zostanie wysłany na prywatny adres e-mail zarejestrowany wcześniej w SSPR.
• Mobile Phone - uwierzytelnianie poprzez jednorazowy kod z wiadomości SMS lub połączenie telefoniczne. W przypadku połączenia telefonicznego otrzymamy połączenie od automatu Microsoftu, który poprosi nas o naciśnięcie wskazanego klawisza na klawiaturze (lub ekranie, jeśli Twój telefon nie posiada fizycznej klawiatury :mobile_phone:).
• Office Phone - To samo co Mobile Phone, jednak bez opcji SMS.
• Security Questions - pracownik zostanie poproszony o udzielenie odpowiedzi na pytania bezpieczeństwa, które wcześniej samodzielnie ustawił. Ilość pytań zależy od konfiguracji SSPR. Możemy stworzyć własną listę pytań, na którą pracownik będzie musiał odpowiedzieć, ale nie mamy kontroli nad treścią odpowiedzi.

Komentarz na temat metod uwierzytelniania:

Osobiście staram się unikać opcji Security Questions oraz Office Phone. W przypadku pierwszej z nich gwarantem bezpieczeństwa jest nasz pracownik, który nie wpisze bezmyślnych odpowiedzi dla pytań bezpieczeństwa, czego wymusić się nie da, a co niesie ze sobą pewne ryzyko. Jeśli chodzi o opcję Office Phone, to wystarczy, że ktoś “z rozpędu” zatwierdziłby zmianę hasła. Ta metoda jest często używana przez pracowników, którzy nie posiadają prywatnego lub firmowego telefonu, a numer Office Phone kontrolowany jest przez osobę inną niż ta, która dokonuje resetu hasła. Warto również wspomnieć, że automat nie podaje nazwy konta, dla którego wykonywany jest reset. Akceptujemy więc zmianę w ciemno :face_with_diagonal_mouth:

Jeśli rozważasz opcję Email, polecam skonfigurować obowiązkowe dwie metody uwierzytelniania, aby zabezpieczyć się przed potencjalnym przejęciem prywatnego konta e-mailowego pracownika.

Polityka rejestracji składników SSPR (Registration)

W zakładce Registration możemy skonfigurować powiadomienie dla pracowników, które poprosi ich o rejestrację brakujących metod uwierzytelniania dla SSPR. Powiadomienie to pojawi się przy następnym logowaniu na konto. Jeśli go nie włączymy, to pracownik może być zaskoczony, gdy będzie chciał zresetować hasło, a okaże się, że funkcja jest dla niego niedostępna (brak skonfigurowanych metod resetu hasła).

Dodatkowo możemy wymusić okresową kontrolę aktualności skonfigurowanych metod uwierzytelniania, aby sprawdzić, czy przypadkiem się one nie zdezaktualizowały. Maksymalny czas, jaki możemy ustawić to 730 dni. Jeśli nie chcemy, aby nasi pracownicy byli bombardowani takimi alertami (a moim zdaniem warto), to możemy wyłączyć powiadomienia poprzez wprowadzenie 0 jako wartości tego ustawienia.

Powiadomienia o zmianie hasła (Notifications)

Kolejna zakładka to Notifications, gdzie możemy skonfigurować ustawienia dotyczące powiadomień wysyłanych przez SSPR po wykonanej zmianie hasła.

Dostępne są dwa rodzaje powiadomień:

• dla użytkowników (Notify users on password resets?) - użytkownik otrzyma powiadomienie na swój adres e-mail, że ktoś (lub on sam) dokonał zmiany hasła na jego koncie.
• dla kont administratorów (Notify all admins when other admins reset their password?) - każdy użytkownik posiadający rolę Azure administrator otrzyma powiadomienie, jeśli inny Azure administrator zmieni swoje hasło. Zapomnienie hasła przez admina jest rzadkim zjawiskiem, dlatego zawsze warto podpytać się kolegę, czy to na pewno on wykonywał reset :smiling_face_with_halo:

Jacy “Ażurowi Administratorzy” otrzymają powiadomienie? W opisie ustawienia nie jest to sprecyzowane, ale najprawdopodobniej będą to wszyscy, których obejmuje domyślna polityka SSPR dla administratorów.

Dostosowanie brandingu SSPR (Customization)

Jeśli chodzi o możliwości dostosowania wyglądu SSPR, to w zakładce Customization mamy opcję dodania własnego niestandardowego linku lub adresu e-mail. Oczywiście, jeśli czujemy taką potrzebę. Zostanie on wyświetlony w trakcie resetu hasła pracownikowi.

Uruchomienie SSPR (Properties)

W końcu czas na pierwszą, a jednocześnie ostatnią i najważniejszą zakładkę, a mianowicie Properties. To tutaj aktywujemy Self-Service Password Reset (SSPR).

Jeśli zależy nam na pełnej kontroli, możemy aktywować SSPR wyłącznie dla wybranej grupy użytkowników. To również dobry pomysł, jeśli planujemy przeprowadzić pilotaż usługi. Z przyczyn technicznych mamy możliwość wybrania wyłącznie jednej grupy, jednak możemy wykorzystać tzw. nested groups, czyli grupy zagnieżdżone - “grupy w grupach”.

W efekcie nasza grupa zabezpieczeń będzie obejmować zarówno konta tylko w chmurze (cloud-only), jak i grupę z lokalnego Active Directory, która zawiera użytkowników hybrydowych.

Gotowe. Za kilka minut SSPR powinno być dostępne dla Twoich pracowników.

Konfiguracja - Jak uruchomić SSPR dla środowisk hybrydowych?

Aby uruchomić SSPR dla użytkowników z lokalnego Active Directory (AD), będziemy potrzebowali trzech rzeczy:

1. włączenia opcji Password writeback w Entra Connect,
2. nadania dodatkowych uprawnień dla konta serwisowego Entra Connect,
3. uruchomienia integracji SSPR z lokalnym AD w Microsoft Entra admin center.

Oczywiście możesz spróbować zignorować dwa pierwsze punkty z listy, jednak Microsoft Entra admin center nie przepuści Cię dalej i wyświetli piękny komunikat No agents that are capable of performing password writeback have been detected.

Włączenie password writeback

Aby aktywować password writeback, połącz się z serwerem AD Connect (Entra Connect), uruchom kreator Azure AD Connect, a następnie kliknij opcję Configure.

Z dostępnych opcji Additional tasks wybierz Customize synchronization options i przejdź dalej.

Zaloguj się na konto z uprawnieniami Global Administratora i potwierdź logowanie (MFA).

Upewnij się, że zmieniasz ustawienia dla dobrego lasu Active Directory i przejdź dalej.

Sprawdź, czy zakres synchronizacji (domena/konkretne OU) jest prawidłowy i przejdź dalej.

W końcu zaznacz funkcję Password writeback i przejdź dalej.

Potwierdź wprowadzone zmiany i przejdź dalej. Kreator będzie potrzebował chwilę na rekonfigurację ustawień synchronizacji.

Gotowe! Zamknij kreator przyciskiem Exit. Po kilku minutach menu On-premises integration w Microsoft Entra admin center powinno zostać w pełni odblokowane!

Weryfikacja uprawnień do resetu haseł

Jakich uprawnień potrzebuje konto AD Connect Entra Connect do resetu haseł? Lista wygląda następująco:

1. Reset password
2. Change password
3. Write permissions on lockoutTime
4. Write permissions on pwdLastSet
5. Extended rights for “Unexpire Password” on the root object of each domain in that forest, if not already set.

Jeśli korzystasz z domyślnego konta serwisowego utworzonego podczas pierwszej konfiguracji AD Connect, mam dla Ciebie dobrą wiadomość - nie musisz podejmować żadnych dodatkowych działań. To konto powinno automatycznie mieć odpowiednie uprawnienia.

Jak sprawdzić, z jakiego konta korzysta AD Connect?

Otwórz ponownie kreator AD Connect i tym razem wybierz z listy Additional tasks opcję View or export current configuration.

Twoje konto serwisowe powinno być widoczne w sekcji Synchronized Directories:

Po weryfikacji pamiętaj, aby zamknąć kreator!

Jak sprawdzić uprawnienia dla danego obiektu?

Teraz gdy już znamy nazwę naszego konta serwisowego, możemy sprawdzić, czy posiada ono wszystkie niezbędne uprawnienia.

Otwórz narzędzie Active Directory Users and Computers, wybierz dowolnego testowego użytkownika, kliknij Properties i przejdź do zakładki Security.

Na liście powinienieś/aś widzieć między innymi konto usługi AD Connect. Ten widok jest jednak zbyt uproszczony, dlatego wybierz opcję Advanced i przejdź do zakładki Effective Access.

Teraz możesz wskazać swoje konto serwisowe i sprawdzić, czy wszystkie uprawnienia z listy powyżej są poprawnie nadane.

Jeżeli Twoje konto serwisowe nie ma nadanych uprawnień, to koniecznie sprawdź:

• czy sprawdzany obiekt ma włączone dziedziczenie uprawnień (opcja inheritance),
• czy uprawnienia są nadane dla OU/domeny wyżej w hierarchii Active Directory.

Poradnik jak nadawać uprawnienia znajdziesz w docs Microsoft.

Teraz możemy wrócić do Microsoft Entra admin center!

Włączenie integracji SSPR z lokalnym AD

Zalogujmy się ponownie do Microsoft Entra admin center i przejdźmy do ustawień Self-Service Password Reset. Tym razem czas na zakładkę On-premises integration.

Jak widać, po naszym wcześniejszym błędzie nie ma już śladu! Spośród dostępnych opcji zaznacz Write back passwords with Azure AD Connect cloud sync, co umożliwi zapis zwrotny haseł z usługi SSPR do lokalnego Active Directory.

Po zapisaniu zmian możemy dodać naszych testowych/docelowych pracowników do wcześniejszej chmurowej grupy security i rozpocząć dalsze testy!

Testy - Jak wygląda proces rejestracji SSPR?

Aktualnie proces rejestracji SSPR nie różni się od procesu konfiguracji MFA. Jedyna zauważalna różnica to fakt, że jeśli usługa SSPR jest włączona i wymaga podania dwóch metod uwierzytelniania, to kreator będzie składał się z dwóch etapów rejestracji zamiast jednego.

Przykładowa rejestracja SSPR

Mamy dwie opcje rejestracji metod uwierzytelniania dla SSPR. Możemy przejść bezpośrednio pod adres: https://aka.ms/ssprsetup lub po prostu zalogować się na swoje konto, ponieważ wcześniej zmusiliśmy użytkowników do rejestracji metod dla SSPR w zakładce Registration.

Przetestujmy skonfigurowany wcześniej komunikat. Podczas testowego logowania zostaniemy powitani powiadomieniem:

Przycisk Next przeniesie nas do typowego okna rejestracji MFA. Różnica jest subtelna - zamiast pojedynczej rejestracji MFA, tym razem musimy skonfigurować dodatkowo numer telefonu jako drugi składnik SSPR.

Zgodnie z komunikatem najpierw skonfigurujmy aplikację Microsoft Authenticator…

…i drugi składnik SSPR - numer telefonu.

Gotowe! Od teraz możemy resetować hasła do woli!

Testy - Jak wygląda proces resetu hasła?

Proces resetowania hasła możemy rozpocząć, przechodząc pod link: https://aka.ms/sspr lub podczas logowania korzystając z opcji Forgot my password.

Kolejnym krokiem będzie upewnienie się przez witrynę, że nie jesteśmy częścią armii robotów walczącej nad przejęciem władzy nad światem 🤖

Nadszedł moment, aby skorzystać z metod weryfikacji tożsamości, które wcześniej zarejestrowaliśmy. W pierwszym kroku wybrałem opcję wysłania powiadomienia do mojej aplikacji Microsoft Authenticator.

Pora na kolejny etap. Tym razem opcja wykorzystania aplikacji zniknęła, więc byłem zmuszony przepisać kod jednorazowy z wiadomości SMS.

Po pomyślnej podwójnej weryfikacji, można przejść do ustawiania nowego hasła.

Gotowe. Hasło zostało zmienione i zapisane zwrotnie do lokalnej domeny, dzięki password writeback.

I to wszystko bez kontaktu z działem IT :smiling_face_with_sunglasses:

Domyślna polityka dla administratorów

Podczas Twojej wizyty w Microsoft Entra admin center mogłeś/aś napotkać informację, że administratorzy posiadają domyślne predefiniowane polityki SSPR. Rzeczywiście jest to prawda, a co więcej, te polityki są domyślnie włączone, nawet jeśli nie zrobiłeś/aś żadnych zmian.

Nie brzmi dobrze? To dodam jeszcze, że wszystkie metody uwierzytelniania są dla nich dostępne i nie ma możliwości ich modyfikacji…

Które konta są objęte polityką?

Polityką są objęci wszyscy użytkownicy posiadający następujące role:

• Application administrator
• Application proxy service administrator
• Authentication administrator
• Azure AD Joined Device Local Administrator
• Billing administrator
• Compliance administrator
• Device administrators
• Directory synchronization accounts
• Directory writers
• Dynamics 365 administrator
• Exchange administrator
• Global administrator or company administrator
• Helpdesk administrator
• Intune administrator
• Mailbox Administrator
• Partner Tier1 Support
• Partner Tier2 Support
• Password administrator
• Power BI service administrator
• Privileged Authentication administrator
• Privileged role administrator
• Security administrator
• Service support administrator
• SharePoint administrator
• Skype for Business administrator
• User administrator

Aktualną listę ról znajdziesz pod linkiem: Administrator reset policy differences

Jak wyłączyć politykę dla Administratorów?

Wbudowaną politykę dla administratorów możemy wyłączyć za pomocą polecenia Update-MgPolicyAuthorizationPolicy. Microsoft nie dał nam jednak możliwości jej wyłączenia tylko dla wybranych kont, więc zmiana tego ustawienia spowoduje wyłączenie SSPR dla wszystkich administratorów. Warto o tym wiedzieć przed zmianą ustawienia 🙂

Instrukcja

Aby skorzystaźć z polecenia Update-MgPolicyAuthorizationPolicy potrzebujemy modułu PowerShell Microsoft.Graph. Instalujemy go poleceniem:

1

Install-Module Microsoft.Graph -Scope AllUsers

Następnie łączymy się z naszą usługą Microsoft 365 za pomocą Microsoft Graph:

1
2

Connect-MgGraph -TenantId <TwójTenant>.onmicrosoft.com
Get-MgOrganization | Format-Table DisplayName, VerifiedDomains

Sprawdzamy, czy polityka na pewno jest włączona i czy Microsoft przypadkiem nie zapomniał zaktualizować dokumentacji:

1

Get-MgPolicyAuthorizationPolicy

Wygląda na to, że brakuje nam części uprawnień :face_with_diagonal_mouth: Trzeba to naprawić.

1
2
3

$RequiredScopes = @("Policy.ReadWrite.Authorization")
Connect-MgGraph -Scopes $RequiredScopes
Get-MgPolicyAuthorizationPolicy

Uprawnienia zostały naprawione, ale formatowanie pozostawia wiele do życzenia… Spróbujmy wyświetlić naszą politykę jako listę.

1

Get-MgPolicyAuthorizationPolicy | Format-List

Od razu lepiej. Nazwa i wartość parametru AllowedToUseSspr zgadzają się z dokumentacją. Pozostało nam wyłączyć SSPR dla administratorów:

1
2

Update-MgPolicyAuthorizationPolicy -AllowedToUseSspr:$false
Get-MgPolicyAuthorizationPolicy | Format-List

Gotowe teraz wystarczy poczekać, aż nasza polityka wejdzie w życie. Według dokumentacji może to potrwać nawet 60 minut.

Testy po wyłączeniu polityki

Ustawienie zostało zmienione, więc czas zobaczyć, czy nasza polityka została faktycznie wyłączona. Zacznijmy od krótkiej weryfikacji stanu ustawienia w Microsoft Entra admin center.

Świetnie, zmiana jest widoczna w portalu. Teraz spróbujmy zresetować hasło jakiegoś administratora.

Mimo skonfigurowanych metod nie możemy zresetować hasła. Sprawdźmy jeszcze, co oznacza błąd SSPR_009.

SSPR for Administrators isn’t enabled on the tenant. SSPR for Administrators (SSPR-A) was the first implementation of SSPR. After SSPR for Users (SSPR-U) was introduced, users could have two separate configurations.

— Microsoft Docs - Troubleshoot error SSPR_009

Myślę, że możemy uznać nasze testy za zakończone 🙃

Gratulacje! Właśnie z powodzeniem wyłączyłeś/aś SSPR dla administratorów.

A co gdyby…

Pewnie zastanawiasz się, co by się stało, gdyby dodać konto administratora do grupy, którą wcześniej skonfigurowałeś/aś dla zwykłych użytkowników. Czy to zadziała? Sprawdźmy!

Dodajemy użytkownika do grupy:

I po chwili próbujemy zmienić hasło…

No cóż, przynajmniej Ty nie musisz tego testować u siebie, bo już wiesz, że to nie zadziała :grinning_face:

Podsumowanie

W tym wpisie wyjaśniłem, dlaczego warto oraz jak skonfigurować Self-Service Password Reset. Przybliżyłem również, jak SSPR działa w praktyce oraz z jakimi komunikatami możesz spotkać się Ty lub Twoi pracownicy. Mam nadzieję, że mój przydługi monolog nie był zbyt nudny i przynajmniej część tego, co napisałem przypadła Ci do gustu.

Natomiast, jeśli wpadłeś tutaj wyłącznie po to, aby poprzeglądać memy, to teraz widzisz, ile rzeczy trzeba przeanalizować i sprawdzić, aby uruchomić pozornie prostą opcję taką jak reset hasła :grinning_face_with_sweat:

Dodatkowe materiały

1. Microsoft Docs - Tutorial: Enable users to unlock their account or reset passwords using Azure Active Directory self-service password reset
2. Microsoft Docs - Tutorial: Enable Azure Active Directory self-service password reset writeback to an on-premises environment
3. Microsoft Docs - Licensing requirements for Azure Active Directory self-service password reset
4. Microsoft Docs - Update-MgPolicyAuthorizationPolicy
5. Microsoft Docs - Troubleshoot error SSPR_009
6. Microsoft Download Center - SSPR rollout materials
7. Practical 365 - Connecting to the Microsoft Graph Using the PowerShell SDK