Problemet

Hvis du har brugt mere end fem minutter inde i Microsoft Entra ID,
så har du sikkert set disse to menuer:

• App registrations
• Enterprise applications

Og på et tidspunkt har du nok spurgt dig selv:

Hvorfor er der to ting der ligner det samme?

Du opretter en app.
Så ser du pludselig en anden app med samme navn et andet sted.

Duplikerede Azure den?
Clonede nogen den?
Har du brækket noget?

Nej.

Du kigger bare på to forskellige perspektiver af den samme applikation.

Den korte forklaring

I Entra ID-terminologi:

Mental-model

• App Registration → hvad appen er
• Enterprise Application → hvor appen eksisterer

Én applikation kan leve i mange tenants.
Hvert tenant får sin egen Enterprise Application.

Hvordan de hænger sammen

  graph LR

    A[App Registration
Application Object]
    B[Enterprise Application
Service Principal
Tenant A]
    C[Enterprise Application
Service Principal
Tenant B]
    D[Enterprise Application
Service Principal
Tenant C]

    A --> B
    A --> C
    A --> D

    style A fill:#DF6155,stroke:#333,stroke-width:2px,color:#fff

En enkelt App Registration kan skabe flere Service Principals.

Det er derfor den samme applikation kan optræde på tværs af tenants.

Hvad der sker når du opretter en app

  graph LR

    A[Create App Registration]
    B[Application Object]
    C[Service Principal]
    D[Enterprise Application]

    A --> B --> C --> D

    style B fill:#DF6155,stroke:#333,color:#fff

Hver App Registration opretter automatisk en Service Principal i det samme tenant.

Den Service Principal er det du ser som Enterprise Application.

Hvorfor Microsoft har delt det op

• Udviklere styrer App Registrations
• Administratorer styrer Enterprise Applications

Det giver én fælles definition med tenant-specifik kontrol.

Hvor folk bliver forvirrede

"Hvorfor ser jeg appen to gange?"
Fordi det er to forskellige objekter.

"Hvor tildeler jeg brugere?"
Enterprise Application.

"Hvor konfigurerer jeg Conditional Access?"
Enterprise Application.

"Hvor konfigurerer jeg API-permissions?"
App Registration.

Tommelfingerregel

• Tenant-specifikt → Enterprise Application
• App-definition → App Registration

Analogi fra den virkelige verden

Ét blueprint.
Mange installationer.

Arbejde uden App Registration

Nogle gange ejer du ikke appen.

Typiske scenarier:

• Multi-tenant-applikationer
• Managed Identities
• Tredjeparts-integrationer

Men du har stadig brug for at tildele permissions.

Vigtigt

Permissions tildeles til Service Principal (Enterprise Application) — ikke til App Registration.

Tildel permissions direkte til en Enterprise Application

Nogle gange ejer du ikke App Registration'en.

Det sker typisk ved:

• Multi-tenant-applikationer
• Managed Identities
• Tredjeparts-integrationer

Men du har stadig brug for at tildele permissions.

Her er det de fleste overser:

Permissions tildeles til Service Principal (Enterprise Application) — ikke til App Registration.

Så selv uden adgang til App Registration kan du stadig give permissions.

Eksempel

Nedenfor er et simpelt eksempel hvor vi tildeler en Microsoft Graph-permission direkte til en Enterprise Application.

$graphScopes er bare et eksempel — brug en hvilken som helst gyldig Graph-permission.

Connect-MgGraph -Scopes "Application.Read.All","AppRoleAssignment.ReadWrite.All","RoleManagement.ReadWrite.Directory"

Select-MgProfile Beta

$managedIdentityId = "Enterprise app Object ID "

# Microsoft Graph Service Principal
$graphApp = Get-MgServicePrincipal -Filter "AppId eq '00000003-0000-0000-c000-000000000000'"

$graphScopes = @(
  'ReportSettings.Read.All'
)

foreach($scope in $graphScopes){
  $appRole = $graphApp.AppRoles | Where-Object {$_.Value -eq $scope}

  New-MgServicePrincipalAppRoleAssignment `
    -PrincipalId $managedIdentityId `
    -ServicePrincipalId $managedIdentityId `
    -ResourceId $graphApp.Id `
    -AppRoleId $appRole.Id
}

Hvad scriptet rent faktisk gør

Lad os tage det skridt for skridt.

1. Connect til Microsoft Graph

Connect-MgGraph -Scopes "Application.Read.All","AppRoleAssignment.ReadWrite.All","RoleManagement.ReadWrite.Directory"

Giver din session tilladelse til at:

• læse applikationer
• tildele app roles
• ændre directory roles

2. Vælg beta-profilen

Select-MgProfile Beta

Nogle endpoints (fx app role assignments) er mere fleksible i beta.

3. Identificér din Enterprise Application

$managedIdentityId = "GUID"

Det er den Service Principal du vil tildele permissions til.

4. Hent Microsoft Graph

$graphApp = Get-MgServicePrincipal -Filter "AppId eq '00000003-0000-0000-c000-000000000000'"

Dette ID:

00000003-0000-0000-c000-000000000000

er det well-known AppId for Microsoft Graph.

Du targeter altså ikke din egen app —
du targeter Microsoft Graph Enterprise Application'en.

5. Definér permission'en

$graphScopes = @(
  'ReportSettings.Read.All'
)

Det er bare et eksempel.

Du kan udskifte den med en hvilken som helst gyldig application permission som Graph eksponerer.

6. Find den matchende App Role

$appRole = $graphApp.AppRoles | Where-Object {$_.Value -eq $scope}

Dette slår permission'ens interne ID op.

7. Tildel permission'en

New-MgServicePrincipalAppRoleAssignment

Det her er det vigtige.

Du siger reelt:

"Giv denne Service Principal adgang til denne permission på Microsoft Graph"

Hvad det betyder i praksis

Efter scriptet er kørt:

• Enterprise Application har nu permission'en
• App Registration (hvis den eksisterer et andet sted) er uændret
• Du har givet adgang lokalt i dit tenant

Mental-model

App Registration = Hvad appen kan spørge om
Enterprise Application = Hvad appen rent faktisk har

Scriptet opererer udelukkende på den anden del.

Det er derfor det virker — selv når du ikke styrer appen.