ROPC – czy polisa 'Block Legacy Authentication’ ma sens?

Cloud, exchange, w-files

ROPC, czyli „Resource Owner Password Credentials”- jest częścią OAuth 2.o i daje możliwość logowania aplikacji bezpośrednio podając hasło. zgodnie z opisem na stronie „it’s incompatible with multifactor authentication (MFA)„.

do tego wpisu usiadłem po śledztwie – jak to jest, że niektóre konta logują się bez MFA pomimo, że jest ustawiona polityka Conditional Access zarówno wymuszająca MFA jak i wyłączająca legacy authentication. pomimo to urządzenia nadal mogą logować się do Exchange, bez MFA, korzystając z czystego SMTP…

w EID wygląda to tak:

w tym scenariuszu, to konto reprezentujące skaner, do realizacji scan-to-email – MFD (Multi-Function Device) nadal spokojnie wysyła skany przez EXO. to wzbudziło moją ciekawość – czemu żadna z polityk nie zadziałała, i czemu legacy authentication nadal jest możliwe – a koniec końców: w jaki sposób można omijać CA wyznaczającą politykę bezpieczeństwa? co tak na prawdę blokuje 'block legacy authentication’, skoro nie zablokował tego połączenia?

jak to się dzieje?

odpowiedź na część problemu już jest, ze wspomnianego artykułu:

  • ROPC nie jest zgodne z MFA – mówiąc inaczej, omija je
  • przykładem kiedy jest wykorzystywane – jest użycie ’hasła aplikacji’ dla konta

a co z 'legacy authentication’? jak zwykle chodzi o semantykę i prawidłowe zrozumienie modelu ISO/OSI albo 4/5 warstwowego modelu Internetowego. najpierw ciekawe spojrzenie któreż to protokoły mają status 'legacy’:

  • Autodiscover
  • Exchange ActiveSync
  • Exchange Online PowerShell
  • Exchange Web Services
  • IMAP
  • MAPI over HTTP
  • Offline Address Book
  • Other Clients
  • Outlook Anywhere (RPC over HTTP)
  • POP
  • Reporting Web Services
  • SMTP
  • Universal Outlook

…w zasadzie cały Exchange do niedawna… (czym jest 'Universal Outlook’ wie chyba tylko developer który implementował filtr protokołów w EID), co ciekawe 'legacy’ są tylko protokoły związane z Exchange, co pokazuje równocześnie priorytetowy obszar do zaadresowania elementów bezpieczeństwa. o ile ’łamie się ludzi a nie systemy’, co pokazują statystyki najpopularniejszych metod włamania, to SMTP pozostaje cały czas najłatwiejsze dla bruteforce.  Microsoft

to z czego w końcu korzysta Exchange Online, skoro wszystko jest poblokowane? jak wymienia się z innymi serwerami, skoro nawet SMTP jest na liście?

po pierwsze, trzeba przyjąć do wiadomości, że chodzi o uwierzytelnienie. nie została wyłączona obsługa całego protokołu, również Conditional Access nie pełni roli firewalla – używany jest do weryfikacji uwierzytelnienia (trochę kłamię, bo obsługa sesji to w sumie sporo więcej, ale to advanced feature więc pomijam tutaj). nie chodzi więc np. o SMTP jako protokół wymiany informacji a o SMTP AUTH – i wyłączenie tych starych, jak PLAIN czy LOGIN.

podobnie Outlook – nadal używa jakiejś tam wersji MAPI do komunikacji. problem z ogarnięciem jak zwykle ma naturę semantyczno-marketingową:

  • MAPI jest protokołem aplikacji, językiem jakim rozmawia Outlook z Exchange
  • do tego jest warstwa transportowa – i ta mocno się zmieniła powolnie transformując od paskudnego RPC, przez zamknięcie w HTTP, potem silniejszą integrację z MAPI… na dziś dzień te warstwy nie są już tak oczywiste bo zbyt to jest wymieszane, stąd twory nazewnicze
  • i do tego dochodzi uwierzytelnienie. które jest jakby obok, albo bardziej dosłownie – na froncie. stosuje swoje własne protokoły, które również operują w kilku warstwach, a po zakończonym procesie uwierzytelnienia przekazują pałeczkę do części operującej transportem i aplikacją.

kiedy dokona się analizy i porozkłada się pojedyncze nazwy na ich składowe – zaczyna powoli być jasne które elementy podlegają, a które nie podelagają polityce Conditional Access. CA zajmuje się wyłącznie ostatnim z wymienionych – uwierzytelnieniem i nie dotyka warstw transportu ani aplikacji wykorzystywanych do komunikacji.

kiedy jeszcze używany jest ROPC, poza scenariuszem z EXO? przez developerów/adminów tworzących zapytania przez SPN aplikacji.

w-files

niby szczegół. ale nadal pozostaje wiele niedomówień w kwestii tego kiedy i co de facto zadziała, co ma bezpośrednie przełożenie na bezpieczeństwo. w jaki sposób mechanizmy CA wiedzą żeby nie przetwarzać polityki MFA ale uznać inną?

wszystko jasne z ROPC, tak? ot, przykład z innego tenanta, skonfigurowanego zasadniczo tak samo:

i tutaj ROPC, który wedle dokumentacji nie obsługuje MFA – nagle magicznie zaczyna je obsługiwać i żądać. co więcej – nagle został zaliczony do 'legacy’ – ale jak, skoro ROPC nie jest 'legacy’, bo jest częścią oAuth2?

albo np. Microsoft zaznacza, że basic authentication jest wyłączony. skoro został wyłączony.. to czemu nadal wszędzie jest włączony i po co polisa na coś, co niby od dawna nie powinno działać? pojawiła się polityka 'block legacy authentication’ ale to nie jest wyłącznie. kolejne zdanie, z tego samego artykułu, również idiotyczne:

„We also disabled SMTP AUTH in all tenants where it wasn’t being used.”

nie chce mi się teraz rozkodowywać ruchu i sprawdzać, ale w sumie nie muszę, bo standardy 'starego internetu’ są opisywane w RFC  i SMTP AUTH jest podstawową komendą. skróty myślowe w dokumentacji technicznej prowadzą do zamieszania i dezorientacji. generyczny log pokazujący negocjację protokołu z Outlook (modern auth):

2024-02-19 10:12:45 SMTP AUTH connection started from [192.168.1.100] (client.w-files.pl)
2024-02-19 10:12:46 EHLO client.w-files.pl
2024-02-19 10:12:46 250-server.w-files.pl Hello [192.168.1.100]
2024-02-19 10:12:46 250-AUTH LOGIN PLAIN XOAUTH2 OAUTHBEARER
2024-02-19 10:12:46 250-SIZE 15728640
2024-02-19 10:12:46 250 STARTTLS
2024-02-19 10:12:47 STARTTLS
2024-02-19 10:12:47 220 2.0.0 Ready to start TLS
2024-02-19 10:12:48 TLS negotiation successful (TLSv1.2, ECDHE-RSA-AES256-GCM-SHA384)
2024-02-19 10:12:49 EHLO client.w-files.pl
2024-02-19 10:12:49 250-server.w-files.pl Hello [192.168.1.100]
2024-02-19 10:12:49 250-AUTH LOGIN PLAIN XOAUTH2 OAUTHBEARER
2024-02-19 10:12:50 AUTH XOAUTH2 dXNlcj1hbGljZUBleGFtcGxlLmNvbQFhdXRoPUJlYXJlciB5YTI5LkEwQWY2eHplN…
2024-02-19 10:12:51 235 2.7.0 Authentication successful
2024-02-19 10:12:52 MAIL FROM:<nexor@w-files.pl>
2024-02-19 10:12:52 250 2.1.0 Sender OK
2024-02-19 10:12:53 RCPT TO:<b0b@w-files.pl>
2024-02-19 10:12:53 250 2.1.5 Recipient OK
2024-02-19 10:12:54 DATA 2024-02-19 10:12:54 354 Start mail input; end with <CRLF>.<CRLF>
2024-02-19 10:12:56 Message content sent successfully
2024-02-19 10:12:56 250 2.0.0 OK 2024-02-19 10:12:57 QUIT
2024-02-19 10:12:57 221 2.0.0 server.w-files.pl closing connection

czyli jednym sensownym wyjaśnieniem byłoby 'wyłączyliśmy SMTP AUTH w tenantach gdzie nie ma Exchange’. co za ściema.

nie lubię niejasności. ciężko się zabezpieczać a wśród niejasności rodzą się potencjalne furtki. a po wszystkich tych testach niby wiem więcej a czuję się tak samo bezradny.

eN.

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…

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.

raportowanie kont hybrydowych

DevOps/Scripting

Raportowanie kont (hybrydowych)

raporty dotyczące kont i skrzynek są niezbędne podczas wielu różnych sytuacji – czy to codzienna administracja, porządki czy przygotowania do migracji. problem polega na tym, że sposób w jaki prezentowane są dane przez portale jest nieznośny – informacje rozbite pomiędzy usługami, ograniczone filtry i widoki, niektóre informacje ukryte gdzieś i niedostępne przez GUI. dla tego skrypty raportujące pojawiały się tutaj nie raz i teraz pracuję nad kolejnym 'mini-projektem’ który ma proces usprawnić. ponieważ dojrzał już do jakiejś sensownie działającej wersji, trochę informacji i ciekawostek.

scenariuszy jest zaiste wiele:

  • aktywność i nieużywane konta
  • informacje na temat licencji użytkowników
  • status MFA
  • informacje o skrzykach exchange – zajętość, status, aktywność
  • przygotowanie do synchronizacji
  • wszelkiego rodzaju migracje – pomiędzy tenantami, onprem-to-Cloud etc.

o ile zadanie dotyczy pojedynczego systemu, można sobie poradzić standardowymi narzędziami… zazwyczaj. ale kiedy trzeba popatrzeć holistycznie na 'konto’ jako całość – zaczyna się robić trudniej.

Skrypty raportujące

same skrypty dostępne są na github ale warto wiedzieć jaka jest ogólna logika.

najwygodniejszym formatem do obróbki danych jest CSV z dwóch powodów.. czy też raczej sumy dwóch powodów – PowerShell świetnie sobie z tym formatem radzi oraz to, że Microsoft Excel jest najbardziej rozpowszechnionym narzędziem do prezentowania danych tabelarycznych – a w końcu o to nam chodzi, żeby zbudować zestawienie danych, czyli tablę. dość złożoną, ale nadal tylko tabelę.

o ile przygotowanie eksportu z poszczególnych systemów jest stosunkowo proste, o tyle największym problemem jest ich połączenie. to, czego PowerShell nie posiada, to zmienna typu 'tabela’. oh, nie chodzi o zwykłą tablicę, hashtable czy podobną zmienną, chodzi mi bardziej o coś bliższego tabeli w rozumieniu bazy danych – tak, żeby można było wyszukać informację/rekord, zrobić aktualizację, powiązać ze sobą rekordy. pisałem już kilkukrotnie różne synchronizatory i to, ile problemów jest z takim systemem wie tylko ten, kto kiedyś spróbował coś takiego napisać – wyjątki, duplikaty, łączenie rekordów… o ile połączenie dwóch źródeł jest trywialne – przy trzech i więcej zaczyna się prawdziwe wyzwanie. dla tego wzorem dla mnie była lekcja z MIIS (Microsoft Identity Integration Server) na którym zbudowany został AD Sync. nie żeby moje skrypty były choćby blisko, ale zrozumienie metaverse (tego z MIIS, nie w tym dzisiejszym rozumieniu) jest kluczowe do napisania sensownej synchronizacji.

logika skryptów jest w założeniu prosta:

  • zrobić zrzut danych z EntraID do csv
  • zrobić zrzut danych z Active Directory do csv
  • zrobić zrzut danych z Exchange Online do csv
  • połączyć dane i skonwertować do xlsx gdzie już ręcznie można zacząć bawić się wynikami

jak już wspomniałem, to ten ostatni krok jest największym wyzwaniem – żeby pisać kod tak, aby mógł potem być użyty przy innych podobnych zadaniach, gdzie jest potrzeba połączenia danych z kilku źródeł. stąd w skrypcie join-eNReportHybridUsersInfo pojawiają się trzy funkcje:

  • search-MetaverseData
  • add-MetaverseData
  • update-MetaverseData

kiedy mamy już zrzut z poszczególnych systemów w postaci CSV (nie muszą być wszystkie trzy, wystarczą dowolne dwa – EID/EXO/AD), 'join’ sprawdza czy da się dane jakoś powiązać.

ostatnio mam sporo sytuacji gdzie nie ma wdrożonej synchronizacji (Cloud Sync) albo jeszcze gorzej – jest częściowa. środowiska w których część kont jest synchronizowana, część z jakiegoś powodu nie, ale mają … lub nie mają swojego bliźniaka w EID. niestety ale z mojego doświadczenia to bałagan jest normą a porządek wyjątkiem – więc znalezienie par nie jest trywialne i często wymaga poszukiwania na podstawie różnych atrybutów – czasem to, co jest w stanie powiązać dane to UPN, email, a czasem displayname. nie można liczyć na żaden konkretny atrybut? skrypt pozwala spróbować powiązać na dowolnym istniejącym. i chociaż funkcja nadal jest dość prymitywna to działa świetnie i pomaga mi szybko odpowiedzieć na bardzo wiele pytań… :

  • wyłapać konta, które dawno powinny być zablokowane
  • dziwne skrzynki pocztowe o których nawet diabeł zapomniał
  • konta bez skonfigurowanego MFA, żeby nie zabić firmy po konfiguracji Conditional Access
  • wszystkie panie, które pomiędzy kontem AD a EID zdążyły zmienić nazwiska
  • … i masę innych dziwnych sytuacji, literówek i wszelakiego innego bałaganu, z którego da się wyłowić obraz, jeśli się na niego spojrzy z odpowiedniej perspektywy

co do samych operacji na CSV, funkcje do ich obsługi to najczęściej wykorzystywane funkcje z biblioteki eNLib:

load-CSV

  • automatyczne wykrywanie znaku – ratuje jak się pracuje w środowiskach z różnymi ustawieniami regionalnymi
  • możliwość wymuszenia nagłówka w skrypcie, żeby nie zassać jakiegoś przypadkowego śmietnika
  • możliwość dodawania prefiksów, suffiksów czy podania tabeli transformacji nazw kolumn podczas importu

convert-CSV2XLS

  • konwersja do xlsx
  • utworzenie tabeli
  • automatyczne uruchomienie

..i kilka innych przydatnych zabiegów, które czynią pracę z csv prostą i przyjemną.

eN.

 

 

 

MS Tech summit 2o24

news, social

MS Tech Summit to jedna z niewielu w Polsce konferencji poświęconych w pełni na technologiom Microsoft. Już 6.06 Online oraz 7.06 fizycznie, w Warszawie w ADN Centrum Konferencyjne (Browary Warszawskie) zapraszam na kolejną edycję MS Tech Summit. Organizatorzy oraz Członkowie Rady Programowej przygotowali dla Was ponad 50 wystąpień z obszaru technologii Microsoft, 5 ścieżek tematycznych, networking, afterparty i wiele więcej…

Niestety nie mogę pojawić fizycznie, czego żałuję, ale dokładam swoją prezentację dotyczącą nieaktywnych kont w AD i Entra ID. W założeniu prezentacja będzie miała część teoretyczną i praktyczną tak, żeby przedstawić temat całościowo.

Do 06.06.2024, ze specjalnym kodem rabatowym od Rady Programowej: MSTS24SP20 możecie kupić bilet Standard lub PRO 20% taniej. Więcej informacji i rejestracja na: https://mstechsummit.pl/

eN.

KB5034441 0x80070643 fix

DevOps/Scripting, tips'n'tricks

Microsoft zapowiedział, że nie wyda poprawki do poprawki KB5034441, która w większości wypadków wysypuje się błędem 0x80070643. w takim razie pół-automatyczne rozwiązanie do zassania tutaj, a poniżej informacje o co chodzi i jak to działa.

czemu to się sypie

niby opis naprawy można znaleźć na stronie Microsoft. ale po pierwsze, nie każdy jest na tyle odważny, żeby grzebać na żywych partycjach. po drugie w całym tym opisie brakuje bardzo ważnej informacji: potrzebny jest plik w winRE. teoretycznie wykonanie komendy 'reagentc /disable’ powinno skopiować plik winRE, ale tego nie robi. a więc po zmianie wielkości partycji, próbujemy włączyć… i nie działa.

w związku z tym ogólne kroki do wykonania to:

  1. przygotowanie pliku winRM.wim i umieszczenie go w katalogu 'recovery’.
  2. wyłaczenie winRM
  3. znalezienie partycji recovery
  4. zmniejszenie partycji systemowej, żeby zrobić miejsce na winRM
  5. zwiększenie partycji recovery
  6. właczenie winRM

Skrypt

na github

skrypt wymaga uruchomienia jako administrator. co robi:

  • pobiera plik winRM.wim do katalogu 'recovery’
  • próbuje znaleźć partycję recovery i jak mu się uda:
  • przygotowuje plik wsadowy dla diskpart
  • wypluwa instrukcje do robić dalej

jeśli skrypt się nie wysypał – to prawie na pewno wszystko jest ok. jeśli się wysypał przed końcem – cóż, może masz pecha i Twoja konfiguracja jest niestandardowa.

nie działa w 1oo% oczywiście – dla tego nie jest w pełni automatyczny. są różne dziwne scenariusze, ale w większości, na komputerach firmowych sytuacja jest dość prosta. skrypt odpaliłem na wielu serwerach i stacjach roboczych i skuteczność jest na poziomie 95%, oszczędzając mojemu zespołowi godzin pracy i dziargania w diskpart.

Przypadki, które sprawiały problemy to:

  • kilka przypadków z bitlocker, dziwnym układem partycji
  • trudne do wyjaśnienia przypadki w których winRE nie było włączone a patch i tak chciał się instalować. partycja recovery była w 'dziwnym’ stanie [chyba ktoś przy niej wcześniej grzebał (; ]
  • w kilku przypadkach, kiedy zabrało miejsca na dysku systemowym, chociaż było go dużo – pomogła defragmentacja.

w sumie nie dziwię się, że Microsoft nie wydaje automatu, bo nie chce potem odpowiadać za utracone dane. i ja również dodam: USE ON YOUR OWN RISK.

powodzenia

eN.

Locked Shield 2o24

news, security, social

Po raz trzeci miałem zaszczyt uczestniczyć w największych ćwiczeniach (zawodach?) niebezpieczeństwa, organizowanych przez CCDCOE (NATO Cooperative Cyber Defence Centre of Excellence) i po raz kolejny skończyliśmy na podium. przez zamieszanie z punktami ciężko powiedzieć czy na 1 czy na 2 miejscu ale jedno jest pewne – co roku Polska drużyna jest wśród najlepszych!

od zeszłego roku dodatkowym celem ćwiczenia jest wymiana wiedzy i nauka koordynacji zadań między krajami, występuje się w parach – w tym roku walczyliśmy ramię-w-ramię z Finami.

i choć ćwiczenia odbywały się w strefie czasowej CET, co oznaczało dla mnie przestawienie dnia i olbrzymi wysiłek – nie żałuję. to świetne doświadczenie i jestem dumny z naszego wyniku. „dywizja AD” (; trzymała się świetnie przez cały czas pozostając all-green w zasadzie od początku do końca. trochę nas postraszyli w ostatniej fazie, ale daliśmy radę i to rozwiązać szybko i sprawnie.

szczególne podziękowania dla naszego leadera – Grześka i pozostałych członków teamu AD – Roberta, Tomka i Marka.

eN.

nieaktywni użytkownicy EntraID

Cloud, DevOps/Scripting, tips'n'tricks

w AD sprawa była prosta… no może nie tak bardzo prosta, bo historia atrybutów lastLogon i lastLogonTimeStamp też ma swoje drugie dno, ale od wielu lat wiadomo jak aktywność użytkownika zbadać… i pojawiła się Chmura i hybryda, która całość skomplikowała…

przez wiele lat nie było prostego sposobu na zapytanie 'wyszukaj nieużywane konta’, ponieważ nie było w EntraID odpowiednika lastLogonTimeStamp i trzeba było każdy system badać na dziwne sposoby. wedle Microsoft, należało odpytać logu audytu, który miał standardowo 3o dni.. wielce przydatne. nie drążąc dalej historii, od kwietnia 2o2o GraphAPI produkcyjnie obsługuje ’signInActivity’ – w końcu atrybut/zasób, który jest automatycznie aktualizowany ostatnią datą uwierzytelnienia.

uwaga. atrybut może mieć do 6h opóźnienia w aktualizacji

UWAGA – to nie jest atrybut 'ostatniego UDANEGO uwierzytelnienia’ a 'ostatniej PRÓBY uwierzytelnienia’

jak odpytać

kilka przykładów jak przygotować sobie raport, korzystając z commandletów Microsoft.Graph

wyświetlenie wszystkich użytkowników, wraz z ich mailem oraz datą ostatniej aktywności:

Get-MgUser -Property displayname,mail,signInActivity -all|
    select displayname,mail,@{L='signin';E={$_.SignInActivity.LastSignInDateTime}}

korzystanie z commandletów graphowych nie jest przyjemne i wymaga cierpliwości. większość operacji, ze względu na optymalizację, nie wyświetla prawie żadnych atrybutów – dla tego trzeba wyraźnie zaznaczyć w 'property’ czego będzie się potrzebowało.

trochę bardziej złożony raport, wyrzucany na csv, zawierający dodatkowo informacje o licencjach:

Get-MgUser -Property id,displayname,givenname,surname,accountenabled,userprincipalname,mail,signInActivity,userType -all|
    select id,displayname,givenname,surname,accountenabled,userprincipalname,userType,mail,`
    @{L='signin';E={$_.SignInActivity.LastSignInDateTime}},`
    @{L='licenses';E={(Get-MgUserLicenseDetail -UserId $_.id).SkuPartNumber -join ','}}|
        export-csv -nti c:\temp\EntraUsers.csv -Encoding utf8

co mnie denerwuje w tych commandletach, to że nie są przyjmują w prosty sposób obiektów, np to nie zadziała:

get-mgUser -all|get-mgUserLicenseDetail

to było abecadło PS, ale wzięli się za to developerzy webowi i taki efekt… trzeba też zawsze pamiętać o dodaniu 'all’ bo standardowo jest paging na 1oo obiektów.

i jeszcze drobny przykład na użycie filtra. nie jest co prawda widoczne w helpie od get-mgUser ale to jest filtr OData – z którego ogólnie korzysta cały Graph. tutaj prosty filtr, żeby wyświetlić tylko konta typu guest. nie podjąłem się filtrowania po dacie w OData bo to by kosztowało mnie za dużo czasu na rozkminkę – operacje na datach nie są oczywiste, a PowerShell sobie świetnie z tym radzi:

Get-MgUser -Filter "userType eq 'guest'" -Property displayname,usertype,signinactivity|
    ?{$_.SignInActivity.LastSignInDateTime -lt (get-date).AddMonths(-2)}|
    select displayname,usertype,@{L='activity';E={($_|select -ExpandProperty SignInActivity).LastSignInDateTime}}

connect

oczywiście żeby korzystać z commandletów graph trzeba się połaczyć z odpowiednim zakresem (scope). jeśli to jest dla ciebie nadal problemem to koniecznie wrzuć do bookmarków ten link, który opisuje jak użyć Find-MgGraphCommand żeby sprawdzić niezbędne zakresy.

jak Microsoft potrafi strzelić klientom w kolano

ciekawostką jest, że żeby być w stanie odczytać ten atrybut, trzeba mieć minimum EntraID P1 – inaczej wyskoczy błąd:

Get-MgUser_List: Neither tenant is B2C or tenant doesn't have premium license

Status: 403 (Forbidden)
ErrorCode: Authentication_RequestFromNonPremiumTenantOrB2CTenant

…dlaczego? nie chodzi mi o techniczne wyjaśnienie, ale to krzyk w stronę MS – dla czego tak podstawowa funkcjonalność, jak wyszukiwanie nieaktywnych kont, wymaga dodatkowej licencji?

eN.

’touch me’ – nieoczywista oczywistość

4 komentarzecuriosity

czemu tokeny FIDO chcą żeby je dotknąć?

ktoś zadał mi takie pytanie i w sumie ja też sobie je kiedyś zadawałem…

kiedyś

jako dinozaur, bardziej naturalnym [czy też tradycyjnym] sposobem uwierzytelnienia są dla mnie karty karty inteligentne. nie do końca rozumiem, czemu nigdy nie zdobyły popularności na rynku małych i średnich firm oraz prywatnie:

  • są super tanie!! pojedyncza karta to koszt ok. $1-2
  • łatwo dostępna technologia – przez długi czas dużo laptopów wychodziło z wbudowanymi czytnikami
  • fajnie integrowały się z systemami bezpieczeństwa dostępu fizycznego – ta sama karta do bramki przy wejściu i potem odpowiednie poziomy dostępu do pomieszczeń.
  • ta sama karta do logowania do systemu co do drzwi

taki klasyczny 'żarcik edukacyjny’ w niektórych firmach w jakich pracowałem, to szybka podmiana pulpitu na jakieś złośliwe zdjęcie, albo wysłanie maila do całego teamu 'stawiam wszystkim pączki!’, kiedy ktoś odszedł od kompa nie blokując pulpitu… dodatkowa zaleta smartcard jest taka, że kiedy osoba odchodzi od komputera – np. do toalety – musi użyć tej samej karty, a wyjmując ją z kompa automatycznie blokowana jest stacja.

a jednak to tokeny FIDO2, ze wszystkimi swoimi wadami, od ceny zaczynając, rozpychają się na obecnym rynku…

dodatkowo przez jakiś czas zastanawiałem się po co trzeba je dotknąć? spodziewałem się że to małe coś na tokenach, to czytnik linii papilarnych – to by miało sens. ale nie – to zwykłe zwarcie jest. niektóre 'nowoczesne’ modele są tak zaprojektowane, żeby były malutkie i 'nie przeszkadzały’ podobnie do nadajników radiowych, i żeby nie trzeba było ich w ogóle wyciągać – a więc co to za zabezpieczenie? to tak jakby zostawiać klucz w zamku – wystarczy przyjść i przekręcić.

odpowiedź

odpowiedź jest prosta – te klucze nie mają chronić przed próbą dostępu fizycznego. konieczność dotyku powoduje, że przy próbie uwierzytelnienia zdalnego, kiedy wymagany jest 2FA, potencjalny atakujący nie będzie w stanie go użyć… bo jest zdalnie, czyli nie może dotknąć tokenu. statystycznie patrząc, nie bronimy się raczej przed kolegami z pracy, dość rzadkim scenariuszem są również sytuacje, w których atakujący ma fizyczny dostęp do naszego komputera.

dodatkowo, bardziej prawidłową odpowiedzią będzie – „wygoda”. bo przecież konieczność wpisania PINu daje ten sam poziom [ba! wyższy! bo ktoś musi go znać], tylko jest bardziej upierdliwa. zresztą do tokenów też trzeba często podać PIN.

no to czemu nie smart card?

Pozostaje pytanie – czemu jednak nie karty inteligentne, skoro mają tyle zalet? w końcu to, że tokeny są tak ładnie obsługiwane przez przeglądarki i urządzenia to kwestia tego, że powstały standardy, które zostały zaimplementowane przez dostawców. są takie, ale mogły być inne. czego zatem brakuje kartom inteligentnym i czemu nie dostosowano tej technologii do protokołów Chmurowych WebAuthn/CTAP? co przełamało prawo konwergencji, forkując technologię, która wydawała się wygodniejsza [i tańsza] – pozostawiając karty inteligentne w niszy dostępu fizycznego, a stworzono Fast IDentity Online [FIDO]?

podstawowym powodem jest cały model uwierzytelnienia, tzw. authentication workflow. obsługa certyfikatu zorientowana jest na zcentralizowanym modelu. FIDO z założenia jest zdecentralizowane, oparte na szybkiej weryfikacji, bez konieczności dodatkowego sięgania do jakiegoś centralnego serwera. niepotrzebna jest Infrastruktura Klucza Publicznego [PKI] – która ma swoją własną złożoność, problemy, podatności etc…

można z tym wszystkim niby polemizować – że certyfikaty nie muszą być drogie, że wdrożenia PKI to wcale nie musi być nie-wiadomo-jak-skomplikowane… ale jak to wszystko zebrać razem, to po prostu nie tędy droga. tak na prawdę FIDO powinno być ewolucyjnie porównywane z tokenami OTP – np. RSA SecureID – a nie z kartami inteligentnymi. elektronika, która jest w tokenach pozwala na wiele więcej, niż pasywne przechowywanie certyfikatów:

  • generowanie tokenów jednorazowych TOTP/HOTP
  • izolację procesu generacji klucza publicznego bezpośrednio na urządzeniu, dodanie TPM, a więc nie ma praktycznie możliwości przechwycenia części prywatnej. przy klasycznym PKI mamy architekturę serwer-klient, a więc dodatkowy punkt potencjalnej słabości
  • proces uwierzytelniania WebAuthN nie jest trywialny… dodatkowa komplikacja w postaci weryfikacji certyfikatów na serwerach CA zabiła by Internet. kto przepalił godziny na rozwiązywaniu problemów uwierzytelnienia ten wie, że w
  • i w końcu wszystkie te bajery, które nie są bez znaczenia typu możliwość dodania biometrii – np. czytnika odcisków palców [jasne… cena jest kosmiczna, ale są],
  • self-service … [well… można polemizować z tym self-service. nie wszystkie scenariusze pozwalają na self-service…]

w skrócie – wymagana była aktywna elektronika.

pisząc ten art zadałem sobie pytanie – czemu nie połączy się tych dwóch technologii tworząc FIDO2 smart card… i jak to zwykle bywa – ktoś już odpowiedział na to pytanie – a czemu by nie? mam nadzieję kiedyś pracować przy wdrożeniu takiego cuda, jako część Integrated Security System, bo wygląda smacznie.

Exit

jednym z drażniących ograniczeń FIDO jest brak jego natywnej obsługi przez Windows logon. do tego celu można oczywiście wykorzystać system innych firm – jak np. Duo. problemem są koszty rozwiązania – same tokeny FIDO do najtańszych nie należą, a i subskrypcja Duo kosztuje… dochodzi dodatkowy poziom integracji, wybór IdP i tak dalej…

…nie podejmuję się odpowiedzi na pytanie 'dlaczego?’… a w każdym razie nie dzisiaj…

eN.