co oznacza 'sign-ins’ w EntraID

Cloud, w-files

niemal dokładnie rok temu cieszyłem się, że w końcu EID udostępnia atrybut pozwalający na weryfikację kiedy dane konto się ostatnio logowało. Co prawda dla wybrańców (min. EID P1) – ale umówmy się, EID P1 jest w zasadzie obowiązkiem w obecnych czasach. Chodzi o atrybut 'SignInActivity’, który widać również w GUI dla widoku konta:

jak mawiają – człowiek uczy się całe życie, o czym miałem okazję przekonać przy ostatnim śledztwie potencjalnego włamania na konto.

Okazuje się bowiem, że wbrew (mojej?) intuicji, atrybut ten nie wskazuje 'ostatniego udanego logowania’ podobnie, jak ma to miejsce w Active Directory, a oznacza 'ostatnią próbę uwierzytelnienia’ – bez względu na jej efekt. mówiąc inaczej – data ostatniego wpisu w logach 'sign-in logs’.

w tym przypadku to była dobra informacja – ponieważ po wstępnej panice okazało się, że to tylko były próby logowania, zakończone fiaskiem, a nie jak wskazywałby atrybut 'SignInActivity’ – realne logowania. jednak dla zapewnienia podstawowej informacji jaką jest wiedza o tym, kiedy użytkownik był aktywny, to informacja fatalna – ponieważ okazuje się, że przez blisko 15 lat istnienia EntraID/AAD nie udostępnia tej informacji. nawet klienci, którzy raczą zapłacić za dodatkowe licencje, będą mogli co najwyżej zobaczyć cokiedy nastąpiła ostatnia próba logowania, pozostawiając audyt aktywności zadaniem wykonalnym tylko przez drogie narzędzia firm 3cich, po ich odpowiedniej adaptacji.

o ile ten atrybut jest nadal pomocny – właśnie przy śledztwach typu 'czy ktoś próbuje’ (co oczywiście jest istotne), ale równocześnie odbiera narzędzia audytów higieny. jeśli administruje się pojedynczym środowiskiem można to sobie jakoś oprogramować, zaimplementować dodatkowe narzędzia czy to SIEM czy dedykowane do zarządzania M365, które agregują logi i pozwalają na podobne zapytania. jednak w przypadku audytów zewnętrznych, ad-hoc, gdzie dysponujemy tym, co klient po prostu ma – pozostajemy bez dość podstawowego narzędzia. w większości środowisk będzie to 3o dni – bo taka jest retencja z licencją, więc nawet jeśli napisze się skrypt który będzie czesał KQLem aktywność konta szukając 'SUCCESS’… co realnie daje 3o dni przy pytaniu o aktywność? takie zapytania powinny mieć możliwość odpytania o lata, a nie o dni…

ciekawostki

  • link do artykułu opisującego logowanie nie wyjaśnia tak istotnego szczegółu. biorąc pod uwagę, jak działa atrybut AD, wydaje mi się, że warto byłoby to podkreślić że w EID to zupełnie inna bajka, bo różnica jest znacząca
  • myślałem, że atrybut 'SignInActivity’ nie jest zapisywany kiedy nie ma się licencji. trochę się więc zdziwiłem kiedy po dodaniu EID P1 nagle objawiły się te atrybuty, pokazujące dawne daty. a więc licencja nie tyle powoduje, że zaczyna być zapisywany, co nie blokuje dostępu do jego odczytu. co pokazuje jak wredny jest Microsoft. to nie jest jakiś wysoce zaawansowana funkcjonalność dla której warto kupić licencję, a bardzo podstawowa informacja, którą powinien móc odczytać każdy – zwłaszcza w związku z tym jak istotne jest bezpieczeństwo w Chmurze Publicznej. o ile EID P1 uważam za obowiązek, nadal uważam, że to bardzo małostkowe ze strony giganta.
  • na ile jestem w stanie sprawdzić – ta informacja nie dotyczy retencji logów. te są faktycznie 7-dni, a więc po dodaniu licencji EID P* nie pojawią się magicznie logi starsze niż 7 dni.
  • jeśli chce się pobrać aktywność logu 'Sign-in’, okazuje się, że jest więcej typów logowania niż Interactive oraz non-Interactive – pojawia się również Application oraz MSI. zazwyczaj powinny być puste dla 'użytkownika’ ale warto wiedzieć i pamiętać przy audycie Service Principals oraz Managed Identities. wygląda na to, że te rodzaje logowania nie będą uaktualniać atrybutu SignInActivity – kolejne utrudnienie. i niech mi ktoś wyjaśni czemu tak podstawowa informacja jest tak trudna do wydobycia?
  • pamiętam w latach 9o’ korzystałem Novell Netware dopiero potem usiadłem do Windows NT. Novell pięknie pokazywał informacje o aktywności kont, natomiast Windows NT nawet po przesiadce na Windows 2ooo długo miał z tym problem. trzeba było czekać na którąś tam wersję, żeby w końcu atrybut lastLogonDate był atrybutem synchronizowanym i pokazywał wartość z lepszym przybliżeniem. z jakiegoś powodu Microsoft zawsze miał z tym problem…
  • najciekawsze jest ze skrzynkami pocztowymi – tak atrybutów czasu jest naście. ciekawy artykuł dotyczący ich znaczenia można znaleźć tutaj.

eN.

Authentication Methods – wymuszenie telefonu dla ról uprzywilejowanych (MSP)

Cloud, security, w-files

Authentication Methods pozwalają w granularny sposób skonfigurować, które metody uwierzytelnienia działają, a które nie. Dobrze jest, zgodnie z zaleceniami, wyłączyć uwierzytelnienie przez telefon – zarówno połączenie głosowe jak SMS, ponieważ te metody są stosunkowo łatwe do złamania

Najlepiej więc te metody wyłączyć. Przy okazji przypomnę, że warto zmigrować do nowego modelu MFA, z procesu którego pochodzi poniższy obrazek:

Tutaj pojawia się ciekawostka, której nie znalazłem w żadnym artykule:

  • Konta należące do rol uprzywilejowanych mają te metody włączone bez względu na ustawienia

Czyli nawet jeśli wykona się wszystkie kroki – pełną migracją do nowego modelu, wyłączy SMS i voice, konto należące np. do roli Global Administrator czy choćby User Administrator, nadal będą mieli ekrany zmuszające do ustawienia telefonu… jest opcja 'choose another method’ – i tutaj też lekkie zaskoczenie – dostępny jest hardware token, phone oraz email.

A więc te najważniejsze konta mają zakodowane najmniej bezpieczne metody. Oczywiście – jeśli jest to konto:

  • dla konkretnego administratora, w konkretnej firmie
  • break glass account

fizyczny klucz FIDO2 rozwiązuje temat. powinien wręcz być podstawową sugestią wizarda konfiguracji konta.

problem pojawia się w środowisku gdzie pojedyncze konto używane jest przez wielu operatorów – myślę głównie o środowiskach MSP… „HEREZJA!” chciałoby się krzyknąć. sytuacja niedopuszczalna – żeby jedno konto było współdzielone przez kilku użytkowników. zasadniczo tak właśnie jest – nie powinno się współdzielić kont, ponieważ łamie to podstawowe zasady bezpieczeństwa, choćby 'Accounting’ z AAA principle, nie pozwalając na jednoznaczną identyfikację 'kto wykonał operację’. są inne, prawidłowe metody zarządzania:

  • indywidualne konta i PIM. perfekcyjne dla dużych firm ale dla małych koszty EID P2 są duże, a w przypadku MSP posiadanie wielu kont dla całej obsługi, w każdym zarządzanym tenancie jest nierealne
  • GDAP dla MSP. świetna idea, ale niestety Microsoft nigdy nie potrafił wdrożyć jest dobrze. portal partnerski był kupą i nią pozostał nawet po pełnym liftingu. jak ktoś raz na miesiąc potrzebuje coś sprawdzić to pewnie zbierze się na cierpliwość żeby skorzystać z tego narzędzia, ale do codziennej administracji potrzeba byłoby zatrudniać mistrzów ZEN. poza prędkością działania, to się po prostu sypie i nie wszystkie operacje są obsługiwane, część po prostu wymaga bezpośrednio zalogowania się jako GA.
  • różne aplikacje firm 3-cich, które mają pełny dostęp i własny model bezpieczeństwa. wprowadzają dodatkową warstwę abstrakcji, dając możliwość uwierzytelnienia z centralnego, zintegrowanego tenanta MSP czyli zapewniają audyt zmian, pod spodem działając przez GraphAPI. brzmi nieźle – i to kolejne fajne rozwiązanie dla większych, ale ze względu na koszty (głównie związane z utrzymaniem i wprowadzaniem dodatkowej złożoności) – znów sprawia problemy mniejszym firmom.
  • można też oczywiście przygotować wiele kluczy FIDO2 tak, żeby każdy miał swój. to chyba w miarę najprostsza metoda. choć niezbyt tania, to jest to jednorazowy koszt w przeciwieństwie do comiesięcznych subskrypcji i utrzymania…

Microsoft zawsze przede wszystkim patrzył na Enterprise, pozostawiając mniejszych trochę na pastwę nieprawidłowych praktyk. to w sumie niuans, ale w czasach, w których codziennie padają kolejne firmy i co chwilę pada kolejny rekord w kwestii tego ile danych udało się wydobyć czy co złamać, takie niuanse nie pozostają bez znaczenia.

eN.

MFA a w szczególności EAM

office365, w-files

  MFA Overhaul

EntraID przechodzi obecnie duże zmiany w kwestii MFA – w końcu, po ~15 latach zniknął ostatni bastion Azure v1 – czyli konfiguracja per-user MFA. Teraz został zintegrowany z nowym interfejsem. ale największe zmiany dzieją się pod spodem – w końcu starają się uporządkować ten bałagan, w którym niewiele osób mogło się połapać – MFA Server, SSPR, per-user MFA i Authentication Methods – 4 różne twarze, trzeba sporo się naczytać i przetestować, żeby zrozumieć gdzie te mechanizmy się przecinają a gdzie są oddzielnymi bytami.

W KOŃCU! kiedyś trzeba było ten bałagan posprzątać.

Authentication Methods daje dużo bogatsze możliwości konfiguracji i zarządzania MFA, które jak nie trzeba nikogo przekonywać, stało się kluczowym elementem zabezpieczenia uwierzytelnienia użytkowników.

Pojawiła się również obsługa EAM – Extended Authentication Method, w maju 2o24, która pozwala na prawidłową integrację zewnętrznych providerów MFA z EntraID. Do tej pory trzeba było korzystać z obejść, tzw. Custom Controls, które powodowały, że informacja o dostarczeniu drugiego czynnika uwierzytelnienia nie była prawidłowo rejestrowana i przekazywana do tokena. powoduje to błędne workflow uwierzytelnienia – w sumie to osobiście nie obserwowałem problemów i wszystko prawidłowo było wykrywane, ale na obrazkach ładnie to wyjaśniają, to im wierzę. nie miałem cierpliwości samemu testować i szukać scenariuszy gdzie to przestaje działać. Z praktyki, moje odczucia są zgoła odwrotne…

Extended Authentication Methods

EAM jest w preview – co jest w Chmurze nową normą – i warto wiedzieć, że póki co więcej psuje niż naprawia. Może dodam, że moje testy były tylko z Duo Mobile, które chwali się tym wsparciem jako jedni z pierwszych i ścisłą współpracą z Microsoft, choć zachowania, które opiszę wydają mi się związane z wewnętrzną obsługą EAM w ramach EntraID a nie z jakimś konkretnym dostawcą.

  • EAM jest niewidzialny. w zasadzie ten problem jest kluczowy i chyba z niego wynika reszta problemów. co znaczy, że niewidzialny? konto skonfigurowane wyłącznie z EAM jest raportowane jako pozbawione MFA.
  • nie da się go w związku z tym ustawić jako 'default’ – bo jest niewidzialny

  • to rozbija workflow uwierzytelnienia i teraz nie da się pozbyć niektórych ekranów MFA,
  • są kłopoty z opcją wykluczenia kont gości w Conditional Access.

 

 

EAM, pomimo że opisywany jako zwiększający integrację, de facto jest 'obok’, drugi w kolejce – niby jest, ale go nie ma, więc za wszelki wypadek wrzućmy go zawsze na końcu. rozbija workflow uwierzytelnienia i ogólnie sprawia problemy. powiedziałbym, że to nie preview a wczesna beta.

Dodatkowo, w zasadzie uniemożliwia tworzenie bardziej złożonych workflow warunkowych – np. 'jeśli dostajesz się do tej aplikacji to użyj EAM a jak do innej to MS MFA’, ponieważ CA nie posiada takiej opcji. Można to było zrobić kiedy używało się starej metody – Custom Controls – ponieważ wtedy Conditional Access widzi ją:

Czyli decydując się na EAM, to trochę decyzja wszystko-albo-nic. Cała logika Conditional Access powinna zostać przeniesiona do zewnętrznego dostawcy – co w moim przypadku nie wchodzi w rachubę, ale to temat na inną rozmową.

Mam nadzieję, że Microsoft zajmie się sprawą i naprawi…

Wsparcie wymaga wsparcia

dodam na koniec, że wsparcie Microsoft z roku na rok coraz bardziej sięga dna. założyłem ticket, żeby to zgłosić i przekazać informacje: już ponad 2 miesiące, 4 różnych konsultantów, przekazywany z teamu to teamu, z każdym po kolei omawiane to samo, zadawane te same pytania, dwie zdalne sesje na których pokazywałem pełne step-by-step, tylko po to, żeby następny mnie zapytał na czym polega błąd. i nie chodzi tylko o to zgłoszenie – tak wyglądają wszystkie zgłoszenia w ciągu ostatnich kilku miesięcy. osoby ze wsparcia nie czytają historii, nie rozumieją co się do nich mówi.

rekordem był ziom, który się ocknął po miesiącu zwlekania i durnych maili w stylu 'sprawa jest analizowana’. W końcu wysłał mi 4 maile w ciągu 2o min, z linkami do różnych artykułów, po czym przysłał piątego maila… w którym zapytał na czym polega błąd, który zgłaszam O_o’ . nic dodać nic ująć: dno, żenada i muł. umiejętności komunikacji i czytania ze zrozumieniem to okazuje się zbyt wielkie oczekiwania co do obecnego poziomu wsparcia.

myślę wtedy, że powinni jeszcze szybciej i więcej inwestować w AI, bo na prawdę wolałbym być obsługiwany przez chatGPT….

eN.