mordęga z MgGraph (get-eNAuditorBasicSecurityInfo, show-eNAuditorScopes)

dziś dwie malutkie funkcje, które dodałem ostatnio, żeby pomóc sobie w wykonywanym zadaniu oraz w pracy z GraphAPI. o ile działanie samych skryptów jest średnio ciekawe i robią stosunkowo niewiele, posłużą do komentarza na temat pracy z Graph.

funkcja 'get-eNAuditorBasicSecurityInfo’ miała pomóc mi zebranie informacji z ok. 3o tenantów, dotyczących tego jak są w tej chwili zabezpieczane, poprzez sprawdzenie czy jest licencja EID P1/P2 oraz czy włączone są Security Defaults. tylko tyle, ale z punktu widzenia zapytania 'aż tyle’ – ze względu na to ile dwa proste commandlety wymagają zakresów (scopes) podczas autoryzacji. ilość jest absurdalna, ale o tym za chwilę. skrypt po prostu zwraca np coś takiego:

C:\temp :))o- get-eNAuditorBasicSecurityInfo
Tenant name: W-Files
deault domain: W-Files.pl
EID Plan: AAD_PREMIUM_P2, AAD_PREMIUM
Get-MgPolicyIdentitySecurityDefaultEnforcementPolicy_Get: You cannot perform the requested operation, required scopes are missing in the token. Status: 403 (Forbidden)
ErrorCode: AccessDenied Date: 2025-05-19T17:26:18 Headers: Cache-Control : no-cache Vary
: Accept-Encoding Strict-Transport-Security : max-age=31536000 request-id :
23232323-2155-40bb-8b55-73dd81b18a15 client-request-id : 23232323-0f82-457a-b671-ce55695f552f
x-ms-ags-diagnostic : {"ServerInfo":{"DataCenter":"Canada
Central","Slice":"E","Ring":"3","ScaleUnit":"000","RoleInstance":"TO1PEPF00009BE7"}} Date :
Mon, 19 May 2025 17:26:17 GMT

Recommendation: See service error codes: https://learn.microsoft.com/graph/errors
Security defaults are DISABLED
done.

skąd ten błąd? ano dla tego, że w obecnym kontekście nie mam odpowiedniego zakresu. a skąd mam wiedzieć, przed połączeniem się do tenanta, o jakie zakresy mam prosić?

scopes

zakresy to prawdziwe piekło. ciekawą propozycję odpowiedzi można znaleźć w artykule Get started with the Microsoft Graph PowerShell SDK gdzie wykorzystuje się Find-MgGraphCommand. Każdy commadlet Graph potrafi pokazać jakie uprawnienia są mu potrzebne… teoretycznie. tutaj będę korzystał ze swojej funkcji:

show-eNAuditorScopes -FunctionName Get-MgSubscribedSku

Name IsAdmin Description FullDescription
---- ------- ----------- ---------------
Organization.Read.All False Read organization information Allows the app to read the organization and…
Organization.ReadWrite.All False Read and write organization information Allows the app to read and write the organi…
Directory.ReadWrite.All False Read and write directory data Allows the app to read and write data in yo…
Directory.Read.All False Read directory data Allows the app to read data in your organiz…

super. tylko:

  • Read jest podzbiorem ReadWrite. a więc czy mam zażądać obu czy wystarczy RW?
  • dlaczego w poleceniu Get, które nic nie zapisuje, wymagane jest RW?

po sprawdzeniu w praktyce:

C:\_ScriptZ :))o-  connect-mggraph -scopes "Organization.Read.All" -NoWelcome

C:\_ScriptZ :))o- Get-MgSubscribedSku -all

Id AccountId AccountName
-- --------- --------
23232323-4563-43cf-ad1e-232323232323_1e615a51-59db-4807-9957-232323232323 8fc43c60-4563-43cf-ad1e-232323232323 w-files
[...]

działa. czyli stawiam tymczasową tezę:

  • wcale nie jest potrzebny Write, wystarczy Read
  • nie potrzebne są wszystkie – z wymienionych wystarczył jeden zakresy

…ale to jeszcze nie koniec. w odkrywaniu od strony praktycznej jest jeszcze kilak innych utrudnień, zniekształcających obraz – cache oraz zgody (consents) wydane w przeszłości. zróbmy taki test, zaraz po wydaniu tego polecenia:

C:\temp :))o- (get-mgcontext).Scopes
AuditLog.Read.All
Directory.AccessAsUser.All
Directory.Read.All
Directory.ReadWrite.All
Domain.Read.All
email
Group.ReadWrite.All
openid
Organization.Read.All
Policy.ReadWrite.AuthenticationMethod
profile
RoleManagement.Read.Directory
User.Read.All
User.ReadWrite.All
UserAuthenticationMethod.Read.All

hmmm.. co tu się zadziało? poprosiłem o jednego Read a dostaję cały kubeł uprawnień, również ReadWrite? skąd to? wedle artykułu na Practical365 podczas zapytania, automatyczne są dodawane uprawnienia, na które daliśmy consent w przeszłości. ile jeszcze jest takich króczków i niuansów – nie wiem, ale jest to potwornie trudne w ustalaniu.

drugi sposób ustalania wymaganych scope jaki stosuję, to podejrzenie jakie są wysyłane w zapytaniu, i utrwalam to w skrypcie. dla tego funkcja 'show-eNAuditorScopes’ posiada parametr 'url’, żeby szybko dokonać ekstrakcji zakresów z zapytania URL wywoływanego podczas wykonania polecenia (copy-paste z paska URL wyszukiwarki):

show-eNAuditorScopes -URL "https://login.microsoftonline.com/common/oauth2/v2.0/authorize?scope=User.Read.All+UserAuthenticationMethod.Read.All+Directory.Read.All+Policy.Read.All+Policy.ReadWrite.ConditionalAccess+AuditLog.Read.All+Domain.Read.All+RoleManagement.Read.Directory+openid+profile+offline_access&response_type=code&client_id=23232323-204b-4c2f-b7e8-232323232323&redirect_uri=http%3A%2F%2Flocalhost%3A51987&client-request-id=32323232-54e5-4393-a5a5-323232323232&x-client-SKU=MSAL.NetCore&x-client-Ver=4.61.3.0&x-client-OS=Microsoft+Windows+10.0.26100&prompt=select_account&code_challenge=8wSisaiudhfjrL6PnMTM09kEAfe8Ae4Khywl63cwBlQ&code_challenge_method=S256&state=23232323-2aaa-4d27-912a-45a92b9fa45bbf42bcaf-7727-48e5-b528-232323232323&client_info=1"

User.Read.All
UserAuthenticationMethod.Read.All
Directory.Read.All
Policy.Read.All
Policy.ReadWrite.ConditionalAccess
AuditLog.Read.All
Domain.Read.All
RoleManagement.Read.Directory
openid
profile
offline_access

fajnie, tylko temu też nie można wierzyć chyba, że wyczyści się najpierw lokalny cache i wszystkie przeszłe zgody dla aplikacji Grpah w tenancie… i nie wiadomo czy nie ma jeszcze jakiś innych, automagicznych usprawnień – np. ciasteczka w przeglądarce. a to jeszcze nie koniec!

artykuł zacząłem od pokazania skryptu, który pokazał błąd 'Access Denied’ – wynikający właśnie z braku jakiegoś zakresu. i tutaj kolejna karuzela z zachowaniem, zależna od nieokreślonej ilości zmiennych takich jak cache, historia poprzednich działań i licho wie co jeszcze. obserwowane zachowania to:

  • skrypt wysypie się z Acc Denied
  • jeśli brakuje jakiegoś zakresu, automatycznie pokaże się okno przeglądarki pozwalające potwierdzić uprawnienie
  • w przeźroczysty sposób odświeżony zostanie token i uzupełniony o brakujące uprawnienie
  • …i jeszcze jedno zachowanie, do którego nie znalazłem dokumentacji więc nie mogę potwierdzić – ale jeśli poprosimy podczas połączenia o wiele zakresów, to będziemy mieli dwa ekrany zgód…

to ostatnie stwierdzenie to trochę strzał na ślepo. dokumentacja mówi o tym, że zapytanie może zostać podzielone na token OID i OAuth, albo że jeśli żąda się uprawnień zarówno delegowanych i aplikacyjnych – wtedy będą oddzielne żądania zgód. porobiłem trochę testów i to się nie spina –  czasem to prawda, a czasem nie. mam nadzieję udaje mi się przekonać, że ilość zmiennych jest spora i nie do końca wiadomo czego się jeszcze nie wie ze względu na ilość elementów biorących udział w procesie i to, w jaki sposób 'pomagają’.

..dodajmy (a może raczej pomnóżmy) jeszcze fakt tego jak zmienna jest Chmura – jutro może wyjść nowa wersja MgGraph i wszystko będzie inaczej.

jak obejść problem?

w dużym skrócie można stwierdzić, że temat jest nie-do-ogarnięcia z poziomu skryptów. trzeba się pogodzić z tym, że czasem będzie kilka żądań (consent request). albo skorzystać z Service Principal.

wykorzystanie aplikacji omija wszystkie wymienione problemy:

  • wszelkie niezbędne zgody wydane są 'z góry’, przed użyciem skryptu
  • potem można łączyć się np. za pomocą Secret

przykładem jest moduł PnP.PowerShell, którego twórcy postanowili przestać walczyć z wiatrakami i uprościć sobie życie, wymagając zarejestrowanej aplikacji.

czemu zatem ja tak nie robię w skryptach? ano ze względu na pewien paradygmat tego do jakiego scenariusza skrypt jest robiony. konkretnie podstawowa różnica pomiędzy 'administracją’ a 'pojedyncze zadanie’. jeśli tenantem zarządzamy (administrujemy) i potrzebujemy uruchomić skrypt regularnie – metoda z aplikacją jest jedyną sensowną. gorzej, jeśli logujemy się po wielu tentach (że zacytuję siebie samego: „zebranie informacji z ok. 3o tenantów„) – wtedy jest to dodatkowe przygotowanie a potem posprzątanie, co mocno redukuje ideę 'skryptu’ jako szybkiego wsparcia.

na zakończenie

słowo komentarza na temat zakresów – bo widać wyraźnie dwa typy zakresów – jedne określane są krótkim słowem (np. email), inne są złożone (np. Something.ReadWrite.All). to właśnie złożenie dwóch tokenów – OID, który zawiera informacje

  • openid, profile oraz email to elementy tekenu OID
  • offline_access choć również jest zakresem OID, występuje niejawnie – jeśli zażądasz go, to dostaniesz błąd. dodawany jest automatycznie.

This permission currently appears on all consent pages, even for flows that don’t provide a refresh token (such as the implicit flow). This setup addresses scenarios where a client can begin within the implicit flow and then move to the code flow where a refresh token is expected.

Scopes and permissions in the Microsoft identity platform

do samej pracy/zabawy z tokenami można skorzystać z modułu MSAL.PS, co pozwala trochę lepiej kontrolować proces.

…kiedyś życie skryptera było prostsze /:

eN.

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

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

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)

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

  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.

Classic Administrator – porządki i źle wyświetlane przypisanie

intro

kolejny brzegowy przypadek. tym razem mógł mnie kosztować usunięcie istniejących subskrypcji – a więc 'niuans, który może zabić’.

scenariusz to clean up subskrypcji. jest ich kilkaset, więc trzeba podejść do tematu systemowo. najpierw zajmę się omówieniem scenariusza i moim podejściem do sprzątania, a jak kogoś interesuje sam bug w Azure – to będzie na końcu.

clean up process

w pierwszej kolejności trzeba wyizolować osierocone i puste subskrypcje. o tym jak znaleźć te puste szybko, czyli KQLem – za niedługo, wraz z małym qrsem KQL. dziś o tych 'osieroconych’.

duża część subskrypcji zakładana jest na chwilę, głównie przez developerów, którzy przychodzą i odchodzą…. a subskrypcje zostają. warto więc znaleźć te, których właściciele już nie istnieją w AAD.

nie żeby i tu nie było problemów, bo okazuje się, że zadanie pod tytułem 'jaki to typ subskrypcji’ również okazało się zadaniem nietrywialnym. przez typ, mam na myśli offering. to, co widać w portalu jest trudno wyciągnąć z commandline – potrzeba do tego gimnastyki z REST API do API billingowego… ale to również na inny dzień. krótko mówiąc – tradycyjnie, PowerShellowo, nie da się tego wyłuskać. a jeśli ktoś chciałby mi przedstawić atrybut 'SubscriptionId’ to powiem, że nie tędy droga… ale to również leży w backlogu do opisania.

zadanie wygląda więc tak – zrobić listing wszystkich subskrypcji wraz z osobami które są Ownerami w ARM IAM oraz Classic Administrators – czyli role Service Administrator oraz Co-Administrator.  posłużą zarówno jako lista kontaktowa, oraz pozwolą na kolejne odpytania, żeby wyłuskać te konta, które już nie istnieją. subskrypcje bez właścicieli to najlepsze kandydatki do podróży do śmietnika. posłuży do tego taki prosty skrypcik, napisany na kolanie:

$csvOwnerFile = "c:\temp\subsAndOwners.csv"
Get-AzSubscription |
    ? {$_.state -ne 'disabled'} |
    %{
    $subname= $_.Name
    $subID = $_.SubscriptionId
    Set-AzContext -Subscription $_|Out-Null
    write-host "processing $subname..."
    Get-AzRoleAssignment -IncludeClassicAdministrators |
        ? {
            ($_.RoleDefinitionName -eq 'owner' -or $_.RoleDefinitionName -match 'administrator') -and ([string]::IsNullOrEmpty($_.RoleAssignmentId) -or $_.RoleAssignmentId -match 'subscriptions')
        } | select  @{L='SubscriptionName';E={$subname}},@{L='subscriptionID';E={$subID}},RoleDefinitionName,DisplayName,SignInName,roleassignmentid
} | export-csv -nti -Encoding utf8 -Path $csvOwnerFile

&(convert-CSV2XLS $csvOwnerFile)
większość commandletów jest z pakietu modułów Az, a ostatni – convert-CSV2XLS z mojego modułu eNlib [WOA! przekroczył 1k downloadów! jak miło q:]. zakładam, że całość jest prosta, ale to lepiej wyjaśnić:
([string]::IsNullOrEmpty($_.RoleAssignmentId) -or $_.RoleAssignmentId -match 'subscriptions')
ten fragment filtra wyrzuca uprawnienia dziedziczone z Management Groups, żeby było trochę przejrzyściej.
można się również zastanowić nad optymalniejszą metodą… ale to znów REST API a nie mam na to opanowanych bibliotek jeszcze /: kolejny z masy wpisów na backlogu…
dobra. jest CSV i excel dla czytelności, teraz trzeba sprawdzić czy konta istnieją. w excelu czyszczę, co niepotrzebne, co wiem, co mnie interesuje, export do CSVki z tymi wpisami, które uznałem za ważne, i jedziemy:
$users = load-CSV c:\temp\subsAndOwners.csv
connect-azuread
$users.SignInName | 
    select -unique | %{
      $u=Get-AzureADUser -SearchString $_;
      if([string]::IsNullOrEmpty($u)) {write-host "$_" -ForegroundColor Red}
    }

load-CSV to kolejna funkcja z eNlib – jedna z najczęściej przeze mnie używanych. ładuje CSV z automatyczną detekcją znaq oddzielającego, co jest mega istotne jak się pracuje w różnych regionalsach. ma też kilka innych bajerów… ale nie o tym tu. dalej już z górki – wyłusqję SignInNames unikalne i odpytuję AAD o użytkownika. ponieważ brak użytkownika nie jest błędem, a nullem, więc nie można użyć try/catch a trzeba wykorzystać IFa.

i wydawałoby się że mam już to, co potrzeba – wrzucam wynik do excela, robię XLOOKUP i pięknie widać które subskrypcje należą do kont, których już wśród nas nie ma… zabrzmiało złowieszczo khekhe…

Błąd w Azure

…chyba, żeby nie. całe szczęście natchnęło mnie, żeby jednak kilka posprawdzać ręcznie. i nagle okazało się, że konta których nie ma… czasem jednak są. a wszystko rozbija się o 'Classic Administrators’, który musi wewnętrznie źle komunikować się z ARMem. wiele staje się jaśniejsze, jeśli przyjrzeć się jak takie obiekty są listowane przy 'get-AzRoleAssigment -includeClassic’:

RoleAssignmentName :
RoleAssignmentId :
Scope : /subscriptions/732d1eea-xxxx-xxxx-xxxx-6154fb40f73f
DisplayName : uname@w-files.pl
SignInName : uname@w-files.pl
RoleDefinitionName : ServiceAdministrator
RoleDefinitionId :
ObjectId :
ObjectType : Microsoft.Authorization/classicAdministrators
CanDelegate : False
Description :
ConditionVersion :
Condition :

na pierwszy rzut okiem może wydawać się, że jest ok… ale gdzie jest 'ObjectId’? to jednak tylko pierwsza część problemu. porządki mają to do siebie, że robi się je rzadko. a to oznacza bagaż historii. a w tym bagażu np. projekt standaryzacji nazw użytkowników i zmiana UPNów z gsurname@domain.name na givenname.surname@domain.name. okazuje się, że ten staruszek nie ma mechanizmu odświeżania i pomimo zmiany UPN, czyli de facto SignInName, tutaj pokazuje starą nazwę. a więc przy odpytaniu AAD – nie znajduje usera, pomimo, że ten istnieje.

co ciekawe, jeśli wejdzie się do uprawnień IAM w portalu Azure, każdy user jest aktywnym linkiem, pozwalającym na kliknięcie i przeniesienie do AAD, na szczegóły konta. tak z ciekawości spróbujcie to zrobić dla Classic Administrators…

całe szczęście projekt był zrobiony z głową i stare UPNy zostały jako aliasy mailowe, a więc doprecyzowałem zapytanie:

$users.SignInName |
    select -unique |%{ 
        $u=Get-AzureADUser -Filter "UserPrincipalName eq '$_' or proxyAddresses/any(p:startswith(p,'smtp:$_'))";
        if([string]::IsNullOrEmpty($u)) {write-host "$_" -ForegroundColor Red}
    }

ale co mnie to czasu i nerwów kosztowało…

możliwości filtra AzureADUser też podnoszą ciśnienie… już nie wspominając o tym, że commandlety AzureAD nie wspierają PowerShell 7, a commandlety Az nie wspierają nie działają dobrze w PowerShell 5. mam od razu w głowie 'niezły burdel tam macie, w tym swoim Archosofcie!’

eN.

 

bolesne i śmieszne

albo ilość albo jakość. Microsoft niemal zawsze wybiera to pierwsze. a im większy jest Azure/o365 – tym gorzej ze stabilnością i jakością. błędów jak ten, który zaraz opiszę, jest masa, ale ten mnie po pierwsze rozśmieszył, po drugie to śmiech przez łzy – bo straciłem półtora tygodnia… może komuś oszczędzę tej przyjemności?

kontekst: konfiguracja polityk Conditional Access dla Windows 365 Cloud PC. jeśli chcemy utworzyć dostęp warunkowy, działający 'wewnątrz’ w365CPC, ale równocześnie pozwalająca na logowanie się do niej samej to polityka musi mieć zrobiony wyjątek na aplikacje w365CPC, bo sama jest częścią 'All Cloud Apps’.  artyqł opisujący jak to zrobić można łatwo wyszukać, a kluczowy okazał się wyjątek na aplikację 'Azure Virtual Desktop’…

#1 dodajemy wyjątek na aplikację windows 365 – tu bez problemu, wyszuqję apkę i działa:

pięknie wyszuqje. więc teraz #2 – dodaję 'Azure Virtual Desktop’…

…średnio widać, ale nie ma liście tego, czego szukam. próbuję bardziej restrykcyjne słowa kluczowe – 'virtual’ a potem 'desktop’…

…apki nie ma. naszukałem się, ticket założony… a jakość wsparcia idzie w parze z samym produktem. słychać, że braqje ludzi na rynq. poziom 'dialogu’ ze wsparciem jest gorszy niż z Cyfrowym Asystentem w wersji beta – te dużo więcej rozumiały już lata temu, i odzywają się językiem, który bardziej przypomina angielski. każda rozmowa to wielo-minutowe 'przepraszam, proszę powtórzyć’ – bo albo ktoś gurgla do słuchawki, albo dzwoni z jakiegoś bazaru w słuchawkach za 5PLN, to makabra jakaś jest. i przy każdej rozmowie trzeba powtarzać wszystko co było w mailach – więc zaczynam podejrzewać, że nie umieją czytać. ale to tak na boq…

do rozwiązania doszedłem w końcu sam, przypadkiem, ponieważ słowem kluczowym do wyszukania 'Azure Virtual Desktop’ jest… 'Windows’:

jak widać, jest więcej aplikacji, których nazwy nie zawierają tego ciągu znaqw, a mimo to pojawiają się podczas wyszukiwania. pech – pewnie 99% innych osób od razu wpisuje 'windows’ i od razu widzi obie apki na ekranie… a mi się zachciało całość wpisać, razem z '365′ /:

bałagan jaki jest w tych nowych produktach jest kosmiczny. nie ma dnia, żebym nie znalazł jakiegoś glitcha – czy to w GUI czy w samych commandletach PS. zaczynamy coraz więcej płacić za tempo rozwoju i intuicja mi podpowiada, że to dopiero początek – już niedługo złożoność i wielkość systemów zje ich twórców, bo to nie jest tak, że Microsoft jakoś odstaje od innych firm. mam wrażenie że Internet jest bardzo à la mode – bo 9o-te są na fali. jak mi się czasem przypadkiem zdarzy uruchomić przeglądarkę bez ad-blockera, to nie wiem co się na ekranie dzieje. osoby z padaczką mogą dostać ataq. na początq lat 2k, jak wychodziło web2.o, były już świetne strony, które były lekkie i dynamiczne – ładowały się tylko w elementach, które się zmieniały i zawierały to, co było potrzebne. i co się z tym stało? większość Internetu to niechlujnie napisane aplikacje, przeładowane niepotrzebnymi dystraktorami, nawalone reklam albo innych elementów, a każde kliknięcie to przeładowanie… a miało być tak pięknie…

eN.

Passwordless dla Microsoft Account

niedawno Microsoft ogłosił funkcję 'passwordless’ dla kont 'Microsoft Account’ – czyli tych nie-firmowych/nie-szkolnych. wszystkie arty dot. braq haseł rozpływają się w zaletach tego rozwiązania i ah, oh [fapfap] … więc daruję sobie powtarzanie zalet braq hasła. funkcję włączyłem i … obniżyłem sobie bezpieczeństwo dostępu.

trzeba jasno odgrodzić passwordless dla firm i funkcje Windows Hello for Business, który zakłada MultiFactor Auth – z naciskiem na ’Mutli’, od passwordless dla kont MS. zastanawiałem się jak to będzie praktycznie zrealizowane, włączyłem –  i osobiście mnie to trochę przeraża – ponieważ z MFA wracamy do Single Factor Auth, którym jest nasz smartfon. nie spodziewam się, aby wiele osób miało na kontach dane warte ucięcia komuś kciuka [i przechowywania w odpowiednich warunkach], ale mimo wszystko logowanie, w którym JEDYNYM czynnikiem jest kliknięcie na ekranie telefonu, budzi u mnie alarm. jakiś czas temu, o ile pamiętam, była opcja dodatkowego zabezpieczenia apki Microsoft Authenticator PINem. dziś znajduję w opcjach jedynie 'require biometric or PIN’ ale bez możliwości wyboru – wygląda na to, że ustawienie pobierane jest z systemu (sprawdzałem na Android) – a więc czy będzie to odcisk, czy PIN – będzie to TEN SAM odcisk/PIN, co do reszty. ciekawy jestem czy ta formuła faktycznie zadziała – dowodem będzie, że przez najbliższe kilka lat będzie funkcjonować w tej postaci, będzie używana, a w prasie nie zaczną się pojawiać arty o tym jak to wypłynęła porcja danych/zdjęć/doqmentów bo ktoś zgubił smartfona. imho bardzo szybko pojawi się nowa wersja apki lub ustawienie, które doda jakiś drugi czynnik – może PIN, może kod SMS, czy choćby wybór obrazka. co ciekawe w ustawieniach konta nadal widzę 'Two-step auth ON’ – pomimo, że loguję się teraz tylko przykładając palec do ekranu.

niezależnie od mojej subiektywnej opinii, każdy powinien zrewidować swoje ustawienia haseł i upewnić się:

  • czy na pewno mamy skonfigurowane dodatkowe metody uwierzytelnienia?
  • czy je pamiętamy? [np. czy znamy odpowiedzi do pytań weryfikacyjnych]
  • czy ustawienia tych metod nie zapętlają się?

jeśli naszą drugą metodą jest adres email, który ma włączone MFA oparte o tą samą apkę – to tracąc telefon nie zalogujemy się nigdzie. powinniśmy mieć realną alternatywę inaczej czeka nas długie przebijanie się przez support. jeśli coś takiego wydarzy się gdy nie mamy czasu, będziemy w kropce. każdy powinien poświęcić czas chociaż raz, i 'na niby’ zgubić telefon. wyłączyć go i sprawdzić gdzie jest w stanie się zalogować, czego braqje, ile to trwa czasu. w firmach na podobne scenariusze powinny istnieć procedury, ale sprawę ułatwia, że zazwyczaj jest kilq administratorów, więc w większości scenariuszy są sobie w stanie pomóc na wzajem. prywatnie, nas czeka przebijanie się przez linie wsparcia – warto przynajmniej spróbować, żeby oszacować ile to może trwać czasu i jak w ogóle taka procedura wygląda.

z jednej strony firmy dwoją się i troją, żeby było bezpieczniej a zarazem łatwiej… wygoda na pewno się zwiększa – ale w momencie kiedy coś się sypnie, zaczynają się schody. i wcale nie jest łatwo wymyśleć i skonfigurować swoje konta tak, aby faktycznie odzyskać awaryjnie dostęp szybko i bezpiecznie.

ciekaw jestem opinii – bo na razie nie trafiłem na te negatywne czy krytyczne. moja jest dość mieszana – niby wygodnie, ale [w przypadku kont prywatnych] na pewno nie bezpieczniej!

eN.

 

search nie działa

hmmm… nie wiedziałem, że to problem globalny – forbes z pewnymi przymyśleniami – ale piszę bo rozwiązanie jest trywialne, zajmuje 3 min i zadziałało na razie na każdym kompie:

w kluczu HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Search trzeba założyć wartość 'BingSearchEnable’ = 0

i przelogować się.

za to z searchem ogólnie coś się ostatnio dziwnego dzieje i od razu wpływa to na pracę – zarówno zmieinone wyszukiwanie w Outlook działa fatalnie, nie jestem w stanie wyszukać tego, co potrzebuję, jak i OneNote – nie podświetla wyniqw, wyszukuje niepełne frazy… czy to ma związek? czy Bing search jest wykorzystywany pod spodem, w lokalnym wyszukiwaniu? wszystkie arty i krzyki mówią o systemowym, a ja mam takie wrażenie, że z każdym jedynym nie jest dobrze…

eN.

współdzielenie OneDrive – ciekawostki

OneDrive Sharing

na początek oczywiste oczywistości:

  • OneDrive to de facto SharePoint. główne ustawienia współdzielenia [Sharing] dziedziczy z globalnych ustawień SP
  • od jakiegoś czasu dostępny jest OneDrive Admin Center z poziomu Office365. z jego poziomu można pozornie ustawić zabezpieczenie współdzielenia na poziomie niższym, niż jest zdefiniowany w SharePoint. ale nie można [co zresztą jest opisane małym druczkiem na dole].

  • od niedawna rozbudowany został klient OneDrive – w końcu można nadawać uprawnienia 'bezpośrednio’ z Exploratora. co mnie pozytywnie zaskoczyło – okienko uprawnień jest renderowane przez OneDrive.exe a nie, tak jak się spodziewałem, iexplore.exe/edge .

Jak powstaje ACE dla osoby z zewnątrz

i tu się zaczyna robić ciekawie. standardowo, do czego przyzwyczaiły nas systemy operacyjne, flow jest taki:

  • użytkownik wybiera plik i nadaje uprawnienia
  • tworzony jest ACE – Access Control Entry – który staje się nieodłączną częścią pliq… w dużym uogólnieniu.
  • osoba próbuje się dostać
    • uwierzytelnia się
    • token uwierzytelniony porównywany jest z ACL [Access Control List] w poszukiwaniu ACE dla danego usera – rodzaj filtra
  • osoba dostaje dostęp lub nie.

wydaje się tak oczywiste… a jednak dla pliq współdzielonego z osobą z zewnątrz w OneDrive, jest inaczej. czy zastanawiałeś się po co jest poniższa opcja? skoro można uzyskać dostęp przez osobę inną niż zaproszona, to znaczy, że ACE nie może istnieć w momencie dostępu. zakładając, że wyłączone są linki anonimowe, w dużym uogólnieniu wygląda to tak:

  • użytkownik wybiera plik, uprawnienia edit/view i adres osoby z zewnątrz.
  • tworzony jest *link*, URL, zawierający token dostępu. ten link wysyłany jest mailem.
  • osoba, która otrzymała link otwiera go. zakładając, że wymuszone jest uwierzytelnienie, zostanie przekierowana na stronę logowania.
  • po pozytywnym uwierzytelnieniu, na podstawie linka generowane jest ACE, które dopiero teraz dopisywane jest do pliq
  • tworzone jest również konto [jeśli nie było wcześniej] „username_server.name#EXT#@company.onmicrosoft.com” w AAD

czemu tak i jakie to ma konsekwencje

opisywane zachowanie będzie zależne od kilq ustawień bezpieczeństwa na SP – czy włączone są linki anonimowe, oraz czy mogą być otwierane przez osoby inne, niż te, do których się je oryginalnie wysłało. współdzielenie linkiem jest znane od lat, i dość oczywiste, dla osób korzystających z usług chmurowych. po prostu w rozproszonym świecie chmury, gdzie nie ma centralnej bazy użytkowników, token jest przekazywany wraz z linkiem – w dużym skrócie posiadanie linka oznacza posiadanie dostępu. stąd powstały mechanizmy rozszerzające to rozwiązanie – np. o wymaganie uwierzytelnienia. czemu zatem link wysłany przez jedną osobę, standardowo może być otworzony przez inną? ta opcja została stworzona głównie z tego powodu, że ludzie korzystają z masy adresów, i mogą mieć konto MS Account założone z innym adresem niż my znamy – np. wysyłamy do kogoś na x@gmail.com a ktoś ma konto MS Account jako x@outlook.com. dzięki temu osoba nie jest zmuszona zakładać kolejnego konta, co było istotne zwłaszcza jakiś czas temu, kiedy nie istniał uproszony proces zakładania konta, i było to bardzo upierdliwe. ale ze względu na bezpieczeństwo, nie włączenie tej opcji, jest dość niepokojącym scenariuszem i sugerowałbym jednak, aby wymuszać weryfikację odbiorcy. w takim wypadq, nawet jeśli przekaże się linka innej osobie [lub zostanie wykradziony!], nie zostanie on obsłużony. można się przyczepić, że komunikat błędu pokazuje zdekodowany adres email osoby, która oryginalnie była w tokenie, ale nie jest to już tak wielki problem.  załóżmy, że opcja jest na 'default’, czyli może być otwarty przez inną osobę. co się stanie, jeśli roześlę link do stu osób? czy wszystkie będą miały dostęp? NIE. link zawiera 'token jednorazowego dostępu’. pierwsza osoba się dostanie i dla niej utworzony zostanie ACE, pozostałe osoby dostaną acc denied.

ciekawostki (bugs?)

nie może obyć się bez zagadek w-files. trafiłem na dwie. w porywach do trzech q:

  1. jeśli jakiś user ma wpisany alternate email z jakimś adresem zewnętrznym – np. x@gmail.com, i chcemy udostępnić plik tej osoby na tenże adres zewnętrzny… to się nie uda. AAD rozpoznaje użytkownika jako wewnętrznego i co prawda wysyła linka [zależnie od tego z jakiego interfejsu skorzystamy zachowanie może być różne], ale nie ma szansy zalogować się na kontem x@gmail.com .
  2. jak sądzicie, czy usunięcie konta #EXT# z AAD spowoduje, że osoba straci dostęp do pliq? scenariusz:
  • administrator doszedł do wniosq, że posprząta trochę, i *dla bezpieczeństwa* usunie konta #EXT# żeby zabrać dostępy.

no to się zdziwi, ponieważ usunięcie konta, nie powoduje usunięcia ACE – te systemy są rozdzielne, i nie ma 'centralnego repozytorium dostępów’. a ponieważ centrum uwierzytelnienia jest również rozłączne z naszym systemem, user zostanie poprawnie uwierzytelniony [przez Microsoft Account a nie przez nasz tenant AAD], ACE istnieje – ergo dostęp będzie. nie wierzycie – spróbujcie, podzielcie się wrażeniami. właśnie ta część pracy – odpowiedź na pytanie 'kto ma gdzie dostęp’ – jest nadal niełatwym zadaniem. 3. PS. czy zwróciliście uwagę, że w OneDrive for Business jest ’shared with me’ a w OneDrive personal jest ’Shared by me’? i żadne ze środowisk nie udostępnia mechanizmu dla pełnego rozeznania się co komu i dla nas….  

OneDrive for Business OneDrive personal

eN.