29/07/2012
At støde på en fejlmeddelelse kan være en frustrerende oplevelse, især når den forhindrer dig i at udføre kritiske opgaver. En af de mest almindelige fejl, som udviklere og administratorer møder, når de arbejder med Microsoft Azure Active Directory (AD) Graph API, er "odata.error": { "code": "Authorization_RequestDenied", "message": { "lang": "en", "value": "Insufficient privileges to complete the operation." }}. Denne fejl indikerer, at den applikation eller service, du bruger til at foretage kaldet, ikke har de nødvendige tilladelser til at udføre den ønskede handling. Selvom det kan virke som en uoverstigelig barriere, er løsningen ofte ligetil og kræver en systematisk gennemgang af dine applikationstilladelser. I denne omfattende artikel vil vi dykke ned i årsagerne til denne fejl og præsentere to detaljerede løsningsmetoder, der dækker alt fra simple læsehandlinger til mere komplekse operationer som sletning eller nulstilling af adgangskoder.

Forståelse af 'Insufficient Privileges'-fejlen
Kernen i problemet er Azure AD's robuste sikkerhedsmodel. Hver handling, der udføres via Graph API'en – uanset om det er at læse brugerdata, opdatere en gruppe eller nulstille en adgangskode – kræver et specifikt sæt af tilladelser. Disse tilladelser gives ikke som standard. Du skal eksplicit konfigurere din registrerede Azure AD-applikation til at anmode om og modtage disse tilladelser. Fejlen opstår, når der er et misforhold mellem den handling, din applikation forsøger at udføre, og de tilladelser, den er blevet tildelt. For eksempel, hvis din applikation kun har tilladelse til at læse brugerprofiler (User.Read.All), vil et forsøg på at opdatere en brugers profil (User.ReadWrite.All) uundgåeligt resultere i denne fejl.
To Typer af Tilladelser: Delegerede vs. Applikation
Det er afgørende at forstå forskellen mellem to hovedtyper af tilladelser i Azure AD:
- Delegerede tilladelser: Bruges når en bruger er logget ind i applikationen. Applikationen handler på vegne af brugeren, og dens effektive tilladelser er en kombination af appens tilladelser og den indloggede brugers egne rettigheder. Dette er typisk for web- eller desktop-applikationer med brugerinteraktion.
- Applikationstilladelser: Bruges når applikationen kører som en baggrundstjeneste eller dæmon uden en indlogget bruger. Applikationen har sine egne tilladelser, og der kræves administrativt samtykke for at tildele dem. Dette er typisk for server-til-server-kald.
Fejlen kan opstå i begge scenarier, og løsningen afhænger af, hvilken type tilladelse der er påkrævet for din operation.
Løsning 1: Konfiguration af Tilladelser i Azure Management Portal
Denne metode er den mest almindelige og er typisk tilstrækkelig for operationer, der involverer læsning af data eller mindre opdateringer. Hvis din API-kald kun kræver læserettigheder, men du stadig modtager fejlen, er det næsten sikkert her, problemet ligger.
Trin-for-trin Vejledning
- Naviger til Azure Management Portal: Log ind på portal.azure.com med en administratorkonto.
- Find dit Active Directory: I menuen til venstre, eller via søgefeltet, skal du finde og klikke på 'Azure Active Directory'.
- Vælg dit Directory: Hvis du har adgang til flere directories, skal du sørge for at vælge det korrekte, hvor din applikation er registreret.
- Gå til 'App registrations' (App-registreringer): I menuen under dit directory's navn, skal du finde og klikke på 'App registrations'.
- Vælg din Applikation: Find den specifikke applikation, du bruger til at foretage Graph API-kaldene, og klik på den.
- Gå til API-tilladelser: I menuen for din applikation, klik på 'API permissions' (API-tilladelser).
- Tilføj de Nødvendige Tilladelser:
- Klik på knappen '+ Add a permission'.
- Vælg 'Microsoft Graph' (eller 'Azure Active Directory Graph' for den ældre API).
- Vælg den type tilladelse, din applikation kræver: 'Delegated permissions' eller 'Application permissions'.
- Gennemse listen og marker afkrydsningsfelterne for de specifikke tilladelser, du har brug for. For eksempel, for at opdatere en bruger, skal du muligvis have `User.ReadWrite.All`.
- Klik på 'Add permissions' nederst.
- Giv Administrativt Samtykke: For mange tilladelser, især applikationstilladelser, er det ikke nok blot at tilføje dem. En administrator skal give samtykke på vegne af hele organisationen. Du vil se en knap mærket 'Grant admin consent for [Your Directory Name]'. Klik på denne og bekræft. Statuskolonnen bør nu vise et grønt flueben for de tildelte tilladelser.
Efter at have fulgt disse trin, kan der gå et par minutter, før ændringerne træder i kraft. Prøv dit API-kald igen for at se, om problemet er løst.
Løsning 2: Tildeling af Administratorrolle via PowerShell
For visse højt privilegerede operationer, såsom at nulstille en anden brugers adgangskode eller slette en bruger, er det ikke nok med almindelige API-tilladelser. Disse handlinger kræver, at den applikation (dens App-hovednavn eller Service Principal) er tildelt en administrativ rolle i directory'et, typisk 'Company Administrator' (også kendt som Global Administrator).

Denne tildeling kan ikke foretages direkte gennem Azure-portalens grafiske brugerflade for en Service Principal. Derfor skal vi bruge Windows Azure Active Directory PowerShell-modulet.
Forudsætninger
- Installer Azure AD PowerShell-modulet. Åbn en PowerShell-prompt som administrator og kør: `Install-Module -Name MSOnline`
- Forbind til din Azure AD-tenant: Kør `Connect-MsolService` og log ind med dine administratoroplysninger.
Trin-for-trin Vejledning med PowerShell
- Find din Applikations AppPrincipalId (Client ID): Først skal du identificere din applikation. Du kan finde dens Client ID (også kaldet Application ID) i Azure-portalen under 'Overview'-sektionen for din app-registrering. Alternativt kan du finde den i PowerShell ved at køre:
Get-MsolServicePrincipal | ft DisplayName, AppPrincipalId -AutoSize
Find din applikation på listen og noter dens `AppPrincipalId`. - Tildel Rollen 'Company Administrator': Nu skal du bruge dette ID til at tildele rollen. Erstat `'din-app-principal-id-her'` med det ID, du fandt i forrige trin.
# 1. Definer din applikations Client ID (AppPrincipalId) $clientIdApp = 'din-app-principal-id-her' # 2. Hent Service Principal objektet for din applikation $webApp = Get-MsolServicePrincipal –AppPrincipalId $clientIdApp # 3. Tildel rollen 'Company Administrator' til din applikations Service Principal Add-MsolRoleMember -RoleName "Company Administrator" -RoleMemberType ServicePrincipal -RoleMemberObjectId $webApp.ObjectId # 4. Bekræft tildelingen (valgfrit) Write-Host "Rollen 'Company Administrator' er blevet tildelt til applikationen:" $webApp.DisplayNameNår scriptet er kørt succesfuldt, har din applikations Service Principal nu de højeste rettigheder i dit Azure AD. Dette giver den mulighed for at udføre selv de mest restriktive handlinger via Graph API. Vær yderst forsigtig med at tildele denne rolle, da den giver fuld kontrol over dit directory.
Sammenligning af Løsningsmetoder
| Metode | Anvendelsesscenarie | Kompleksitet | Krævede Værktøjer |
|---|---|---|---|
| Azure Management Portal | Læse-, skrive- og opdateringshandlinger (f.eks. læse brugerprofiler, opdatere grupper). | Lav | Webbrowser |
| PowerShell | Højt privilegerede handlinger (f.eks. nulstilling af adgangskode, sletning af brugere). | Mellem | PowerShell med MSOnline-modul |
Ofte Stillede Spørgsmål (FAQ)
Hvorfor er PowerShell nødvendigt for at tildele rollen 'Company Administrator'?
Af sikkerhedsmæssige årsager har Microsoft begrænset muligheden for at tildele de mest magtfulde roller til ikke-menneskelige identiteter (Service Principals) via den grafiske brugerflade. Brugen af PowerShell sikrer, at en administrator bevidst og eksplicit udfører denne højt privilegerede handling, hvilket reducerer risikoen for utilsigtede konfigurationsfejl.
Jeg har tildelt de korrekte tilladelser i portalen, men fejlen fortsætter. Hvad kan være galt?
Der kan være flere årsager:
- Propagation Delay: Det kan tage et par minutter, før ændringer i tilladelser er fuldt ud effektive i hele Azure-infrastrukturen. Vent 5-10 minutter og prøv igen.
- Token Cache: Hvis din applikation genbruger et adgangstoken (access token), kan det være, at tokenet blev udstedt, *før* du tildelte de nye tilladelser. Sørg for, at din applikation anmoder om et nyt token.
- Forkert samtykke: Dobbelttjek, at du har givet administrativt samtykke, hvis det er påkrævet for tilladelsen.
Er det sikkert at give en applikation rollen 'Company Administrator'?
Nej, det er en betydelig sikkerhedsrisiko. Denne rolle giver fuld kontrol over dit Azure AD. Du bør kun tildele denne rolle, hvis det er absolut nødvendigt, og du bør implementere stærke sikkerhedsforanstaltninger omkring den applikation, der bruger den, f.eks. ved at beskytte dens legitimationsoplysninger (secrets/certificates) i Azure Key Vault. Følg altid princippet om mindst privilegium (Principle of Least Privilege) og tildel kun de absolut nødvendige tilladelser og roller.
Konklusion
Fejlen 'Insufficient privileges to complete the operation' i Azure AD Graph API er en fundamental del af platformens sikkerhedsdesign. Ved at forstå, at problemet ligger i de tildelte tilladelser, kan du systematisk løse det. For de fleste standardoperationer er en justering i Azure Management Portal tilstrækkelig. For mere krævende og administrative opgaver er PowerShell-værktøjet uundværligt for at tildele de nødvendige roller som Virksomhedsadministrator. Ved at følge de detaljerede trin i denne vejledning kan du hurtigt diagnosticere og rette fejlen, så du kan komme videre med din udvikling og administration i Azure-økosystemet.
Hvis du vil læse andre artikler, der ligner Løs 'Insufficient privileges'-fejl i Azure AD, kan du besøge kategorien Sundhed.
