„per-user MFA” czyli najstarsza z metod MFA, jest coraz bardziej odstawiana na bok. nie ma póki co mowy o tym, żeby była zupełnie wyłączona, ale od 3o Października na pewno będzie jeszcze mniej przydatna, ponieważ pierwotne polisy SSPR oraz MFA zostają wycofane.
po wykonaniu migracji per-user MFA jest oczywiście cały czas dostępny, jednak metody MFA zarządzane są już (w końcu!) z jednego miejsca:
z SSPR nadal jest pewien babol, związany z hasłami i mailem… ale to oddzielny temat.
czy należy się bać migracji do nowego MFA?
raczej nie. jeśli po prostu zaakceptuje się kolejne ekrany procesu, włączone zostaną wszystkie metody MFA, cały proces pozostanie przeźroczysty dla użytkownika końcowego.
ALE…
jest to IMHO świetny moment, aby zrobić trochę więcej niż tylko przeklikać się przez kilka stron wizarda na standardowych ustawieniach. warto faktycznie opracować polityki metod MFA, pozbyć się wszystkich per-user MFA oraz wymusić rejestrację. „kampania rejestracji” jest mniej znaną funkcją, z obserwacji większość firm zostawia te polityki nieskonfigurowane, a to ma ciekawe zastosowanie. i konsekwencje.
wyłączanie per-user MFA
jednym z dość częstych błędów, które widzę, to mieszanie per-user MFA z Conditional Access, wynikający głównie z braku zrozumienia że są różne metody MFA (do niedawna było ich więcej, pow0li zaczyna się unifikować). oczywiście aby wyłączyć per-user MFA zupełnie, należy w pierwszej kolejności upewnić się, że mamy odpowiedni poziom licencjonowania. choć wystarczy pojedyncza licencja aby móc zacząć korzystać z Conditional Access, każde konto powinno mieć licencję. jeśli ktoś korzysta z Security Defaults, to tworzona polityka CA obejmuje wyłącznie konta posiadające odpowiednią licencję, a w takim przypadku model mieszany jest niezbędny.
w dużej ogólności należy pamiętać, iż
per-user MFA ma priorytet i nawet dla osób z licencją i objętych Conditional Access, jeśli skonfigurowane jest per-user MFA, będzie wygrywało
co prowadzi do dziwnych zachowań, może wydawać się, że polityki nie działają.
w module eNAuditor jest funkcja, która pozwala wyłączyć per-user MFA dla pojedynczego obiektu lub dla całego tenanta – wygodne przy przejściu na model CA, np. po zakupie większej ilości licencji:
#disable for a single user with <userID> disable-eNAuditorperUserMFA -userId <userID> -forceReconnect #disable for a whole tenant disable-eNAuditorperUserMFA
flaga 'forceReconnect’ przydaje się do wyczyszczenia kontekstu lub uzupełnienia go o odpowiednie uprawenienia.
kampania rejestracji
fajna funkcja pozwalająca na uzupełnienie CA. możemy pozwolić użytkownikom na korzystanie z różnych metod – np. aplikacja oraz SMS, ale chcemy aby każdy miał aplikację skonfgurowaną obowiązkowo oraz jako podstawową metodę. wtedy możemy uruchomić kampanię rejestracyjną oraz wymuszenie:
standardowe ustawienie to „Microsoft Managed” czyli „nie znasz dnia ani godziny”… osobiście nie lubię takich ustawień. włączenie kampanii wymusi wizarda MFA na wszystkich użytkownikach – nawet tych, którzy mają odpowiednią metodę skonfigurowaną. po prostu będą musieli przejść „pustego” wizarda.
należy jednak przy tym ustawieniu uważać, ponieważ może doprowadzić do pętli na kontach, które wymagają nietypowego ustawienia. np: mamy konta administracyjne czy breakglass, konta usług etc – takie, które są do użytku kilku osób, a zatem mają nie aplikację, tylko kod z password managera (konto breakglass nie powinno mieć MFA w ogóle, dłuuuuugie, złożone hasło). w takim przypadku można wpaść w pętlę. long story short – nie zapomnij zrobić odpowiednich wyjątków od rejestracji, żeby nie zrobić sobie krzywdy.
ogólnie jest to ustawienie bardzo przydatne i pozwala na wymuszenie minimum, ale bądź ostrożny! przypomnę jeszcze, że jeśli korzystasz z EAM, to masz problem.
eN.
