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.
MFA Overhaul
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?
Classic Administrator – porządki i źle wyświetlane przypisanie
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.
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)$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’:
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…
eN.