raportowanie kont hybrydowych
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.
’touch me’ – nieoczywista oczywistość
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:
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:
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.