Migrera dina CPV/CSP-program för att använda detaljerade delegerade administratörsbehörigheter

Lämpliga roller: Administratör för användarhantering

Viktig

Azure Active Directory (Azure AD) Graph är inaktuell från och med den 30 juni 2023. Framöver gör vi inga ytterligare investeringar i Azure AD Graph. Azure AD Graph-API:er har inget serviceavtal eller underhållsåtagande utöver säkerhetsrelaterade korrigeringar. Investeringar i nya funktioner och funktionaliteter görs endast i Microsoft Graph.

Vi drar tillbaka Azure AD Graph i stegvisa steg så att du har tillräckligt med tid för att migrera dina program till Microsoft Graph-API:er. Vid ett senare tillfälle som vi kommer att meddela kommer vi att blockera skapandet av nya program med hjälp av Azure AD Graph.

Mer information finns i Viktigt: Azure AD Graph Upphörande och PowerShell-modulens Avskrivning.

Den här artikeln visar hur du uppdaterar dina CSP-program (Control Panel Vendor) och Cloud Solution Provider för att använda detaljerade delegerade administratörsprivilegier (GDAP). GDAP-modellen hjälper till att framtvinga bästa praxis för säkerhet i säker programmodell och Microsoft identity platform-programmodell, inklusive att tillhandahålla minimirättigheter och ett tidsbundet ramverk.

Jämförelse av GDAP med DAP

GDAP-modellen ersätter dap-modellen (delegated admin privileges) och är inte bakåtkompatibel. DAP-modellen är inaktuell.

Med DAP-administratörsagentmodellen kan du ge din partnerhanterade app en uppsättning konfigurerade behörigheter för alla dina kunder i din klientorganisation utan granskning. Den här processen kallas förhandsgodkännande. Den här processen exponerar kundens hyresgäst på ett sätt som är svårt för en partner att administrera. Det eskalerar potentiellt icke-privilegierade användare och uppgifter till en privilegierad kontext.

Risken med att använda förhandsgodkännande förstärks ytterligare eftersom partnerna inte kan granska eller revidera medgivandena. Även om sidan Microsoft Entra Enterprise Application visar andra medgivanden, visar den inte program som har förhandsgodkända samtycken. Det här äldre beteendet överensstämmer inte med konceptet med minimirättigheter i Microsofts identitetsplattform.

I GDAP-modellen samtycker antingen kunden eller en administratör med en behörighet att agera för kundens räkning för att tillåta att partnerhanterade program använder kundens klientorganisation. Det här beteendet ger kunden spårbarhet och överensstämmer med Microsofts programmodell för identitetsplattform och ramverket för säker programmodell.

GDAP kräver inte att du skapar en specifik relation eller säkerhetsgrupp för applikationens tjänsthuvudnamn.

Mer information finns i Använda ramverket för säker programmodell.

Programbehörigheter och Microsoft Entra-användarroller

Du kan tilldela programbehörigheter i Microsoft Entra-ID på fliken API-behörigheter.

Med GDAP kan du inte längre lägga till Microsoft Entra-roller i ett program med hjälp av relationer eller genom inkludering i en säkerhetsgrupp. Användare har roller som tilldelas direkt via Azure-portalen eller indirekt via grupptilldelning. Användare kan inte ha programbehörigheter.

Programmedgivande är processen för en resursägare som beviljar auktorisering för ett klientprogram för åtkomst till skyddade resurser, under specifika behörigheter, för resursägarens räkning.

I följande tabell listas de applikationstjänstmodeller som fungerar med applikationssamtycke.

Programmodell	Appsamtycke	OBO
Endast program med flera klienter (endast DAP, stöds inte i GDAP)	Ja	Nej
Multitenant-applikation + användare	Ja	Nej
Multitenant-program + användare + OBO	Ja	Kräver en GDAP-relation

Uttryckligt medgivande endast för program till en kundklient stöds inte för programutvecklare från tredje part som använder GDAP. Applikationsspecifikt medgivande är inte kompatibelt med det tidsbegränsade kontrakt med minimala rättigheter som GDAP hanterar.

Partner Center tillhandahåller ett API som möjliggör för en CPV eller CSP att ge sin applikation medgivande genom automatisering i kundens hyresgästkonto. Uttryckligt app- och användarsamtycke krävs för varje kund.

Appen + användarmönstret respekterar det tidsbegränsade minimirättskontrakt som GDAP hanterar. Mer information finns i:

Det här API:et kräver att den anropande partneranvändaren är medlem i en säkerhetsgrupp som har en GDAP-relation med målkund/klientorganisation. GDAP-relationen och den associerade säkerhetsgruppen måste innehålla minst en av dessa bekräftade roller:

Programadministratör (ersatt privilegierad rolladministratör)
Molnprogramadministratör

Not

Användning av privilegierad rolladministratör rekommenderas inte längre.

Partneranvändaren måste också vara medlem i säkerhetsgruppen AdminAgents, vilket krävs för att anropa API:erna för Partnercenter.

Partner kan automatiskt ge medgivande till ett program genom att konfigurera ett OBO-administratörskonto, ange behörigheter, generera en tillfällig token och associera kontot med användaren.

Skapa ett nytt användarkonto eller välj ett befintligt användarkonto som ska användas som CPV/CSP OBO-konto (till exempel AdminOnBehalfOf@contoso.onmicrosoft.com).
Skapa en säkerhetsgrupp som ska associeras med kundens GDAP-relation (till exempel AdminOnBehalfOfSG).
Lägg till din OBO-användare (AdminOnBehalfOf@contoso.onmicrosoft.com) i kundens GDAP-säkerhetsgrupp (AdminOnBehalfOfSG).
Definiera följande GDAP-relationsparametrar. Du kommer att använda dessa senare.
- Varaktighet i dagar.
- Begärda Microsoft Entra-roller som behövs för OBO.
- När du vill automatisera applikationens samtycke enligt beskrivningen i föregående avsnitt. GDAP-relationen bör innehålla minst något av följande: Molnprogramadministratör, Programadministratör för att utföra medgivandeåtgärden med hjälp av API:et.
CPV eller CSP skapar antingen en ny programregistrering för flera klienter eller använder en befintlig registrering i partnerklientorganisationen.

Registrera program-ID :t (till exempel 00001111-aaaa-2222-bbbb-3333cccc4444).
Generera och förnya OBO-uppdateringstoken med hjälp av multitenantprogrammet + AdminOnBehalfOf användaridentitet som genererades i steg 1.

I följande exempel visas hur du skapar respektive token med hjälp av interaktiv inloggning en gång. Kontrollera att inloggningen använder multifaktorautentisering (MFA), eftersom uppdateringstoken måste skapas via MFA för att fungera för OBO-scenarier.
Lagra OBO-användarens uppdateringstoken på en säker plats som kan nås från ditt program för flera klientorganisationer. Azure Key Vault kan vara ett alternativ men krävs inte. Mer information finns i översikten över Azure Key Vault och dokumentationen Key Vault API.

Se till att den lagrade uppdateringstoken förnyas minst var 90:e dag för att undvika förfallodatum. Du kan göra detta i din automationskod eller genom att utveckla en fristående app eller ett skript som förnyar token. När en ny åtkomsttoken skapas från den lagrade uppdateringstoken genereras en ny uppdateringstoken med en livslängd på 90 dagar.

När du behöver autentisera mot kundens klientorganisation för åtgärder, hämtar du den senaste uppdateringstoken från ditt säkra arkiv och använder den för att generera en åtkomsttoken (och en ny uppdateringstoken) för autentisering.
För varje kund som ska använda ditt program för flera klientorganisationer och för vilka du vill köra aktiviteter via delegerad administration vidtar du följande steg:
1. Skapa en GDAP-relation med hjälp av den information som definieras i steg 4.
2. Skicka GDAP-relationen för godkännande.
3. När GDAP-relationen är aktiv tilldelar du säkerhetsgruppen som definierats i steg 2 med lämpliga Microsoft Entra-roller som definierats i steg 4.
4. Kontrollera att en administratör har gett sitt samtycke för din applikation i kundens klientorganisation. För metoden för automatiskt medgivande kan du göra detta när GDAP har upprättats. För manuellt medgivande kan en kunds administratör göra detta innan GDAP konfigureras.

Not

Du kan använda uppdateringstoken som genererades i steg 6 för autentisering mot varje kund. Du behöver inte ta steg 6 för varje kund separat. När du genomför åtgärder i en kundklient tar du den ursprungligen genererade tokenen och byter ut den mot en token som genereras mot kundens tenant. Detta är möjligt på grund av GDAP-relationen/rollerna och ansökans godkännande.

För att konfigurera flera kunder i stor skala rekommenderar vi följande process:

För nya kunder där det inte finns någon delegeringsprivilegier inkluderar du en av de nödvändiga medgivanderollerna i din första GDAP-relationsbegäran (till exempel molnprogramadministratör).

Om du föredrar kortsiktig delegering av privilegier kan du också utvärdera om du kan använda en andra GDAP-relationsbegäran med kort varaktighet (till exempel en dag) med hjälp av en behörighet som tillåter medgivandedelegering (till exempel molnprogramadministratör). Med den här metoden kan du ta bort den mer privilegierade rollen när du har verifierat medgivandefunktionen. Du kan när som helst ta bort den här andra GDAP-begäran manuellt.
För kundfall där det finns en delegeringsprivilegier och partnern har DAP utför du det automatiserade medgivandet i bulk (till exempel med hjälp av PowerShell-skriptet new-PartnerCustomerApplicationConsent).

När du migrerar från DAP till GDAP med hjälp av det partnerledda massmigreringsverktyget konfigurerar du respektive roller som gör det möjligt för partnern att samtycka till migrerade kunder. För kunder som bara har partiella GDAP-rolldelegeringar begär partnern rollen Molnprogramadministratör (eller en liknande roll från listan över rollkrav) för kunden att godkänna manuellt.

I det här avsnittet diskuteras applikationen för API CPV/CSP och användarens medgivande i kundens klientorganisation i större detalj.

Identifiera företagsprogram och omfång (kallas även behörigheter)

För varje program som du planerar att ge medgivande för mappar du program-API:erna och behörigheterna till JSON-nyttolasten. Du hittar din programinformation i Azure-portalen genom att välja Microsoft Entra-ID: Appregistreringar "din app" och sedan välja fliken API-behörigheter.

Följ stegen i Verifiera Microsoft-program från första part i inloggningsrapporter i Microsoft Entra-ID för att filtrera på Microsoft-appar. Leta upp de API:er för företagsprogram som refereras av ditt program och hämta deras specifika program-ID:n. Dessa program-ID:er tilldelas till enterpriseApplicationId i följande JSON-exempel.

Följande ID:t kommer från exempelprogrambehörigheter:

Programnamn	Applikations-ID == enterpriseApplicationId
Microsoft Entra-ID	00000002-0000-0000-c000-00000000000000
Microsoft Graph	00000003-0000-0000-c000-0000000000000

Inkludera de behörigheter som krävs för varje API i omfångsegenskapen. Omfångsegenskapen kan innehålla alla behörigheter (kommaavgränsade) eller en delmängd behörigheter som konfigurerats för programmet som du vill ge medgivande för.

Exempel på JSON-nyttolast:

{
    "applicationId": "11112222-bbbb-3333-cccc-4444dddd5555",
    "applicationGrants": [
        {
            "enterpriseApplicationId":"00000002-0000-0000-c000-000000000000",
            "scope":"Directory.ReadWrite.All"
        },
        {
            "enterpriseApplicationId":"00000003-0000-0000-c000-000000000000",
            "scope":"Directory.ReadWrite.All"
        }
    ]
}

Not

Innan du anropar API:et kontrollerar du att den skapade autentiseringstoken använder samma program-ID som du vill ge medgivande för i kundens klientorganisation. Du kan använda en populär webbplats som jwt.ms för att avkoda din bearertoken och försäkra dig om att dina program-ID:n stämmer överens. I bärartoken ska "appID":"11112222-bbbb-3333-cccc-4444dddd5555" matcha applicationID-värdet i JSON-nyttolasten.

Hämta vänliga namn för behörigheter och omfång

Följande information är användbar om du önskar upptäcka de vänliga namnen för API-behörigheter för applikationer som visas i avsnittet Azure-portalenMicrosoft Entra-programregistrering för en specifik applikation.

Hämta en lista över dina applikationer

Kör graph api get application.

Hämta en lista över program-ID:er och visningsnamn. Värdet id är programobjektets ID.

https://graph.microsoft.com/v1.0/applications?$select=id,displayName

Hämta en applikations requiredResourceAccess-värde, som innehåller API och behörigheter för applikationen som visas i Azure-portalen. Ersätt {applicationObjectId} med program-ID från föregående steg.

https://graph.microsoft.com/v1.0/applications/{applicationObjectId}?$select=requiredResourceAccess](https://graph.microsoft.com/v1.0/applications/{applicationObjectId}?$select=requiredResourceAccess)

Exempelsvar:

"requiredResourceAccess": [
    {
        "resourceAppId": "00000003-0000-0000-c000-000000000000",
        "resourceAccess": [
            {
                "id": "885f682f-a990-4bad-a642-36736a74b0c7",
                "type": "Scope"
            },
            {
                "id": "e1fe6dd8-ba31-4d61-89e7-88639da4683d",
                "type": "Scope"
            },
            {
                "id": "06da0dbc-49e2-44d2-8312-53f166ab848a",
                "type": "Scope"
            },
            {
                "id": "c5366453-9fb0-48a5-a156-24f0c49a4b84",
                "type": "Scope"
            }
        ]
    }
]

Hämta tjänstens huvudnamn

Kör Graph API get servicePrincipal.

Hämta ett specifikt oauth2PermissionScopes-värde för tjänstehuvudman. Ersätt {resourceAppId} med värdet som returneras i matrisen requiredResourceAccess. (Det kan finnas fler än en.)

https://graph.microsoft.com/v1.0/servicePrincipals?$filter=appid eq '{resourceAppId}'&$select=oauth2PermissionScopes

Hitta omfångsdefinitionerna efter ID i svaret och det användarvänliga namnet som lagras i egenskapen value.

Exempel på redigerat svar (reducerat för tydlighetens skull):

{
    "adminConsentDisplayName": "Manage Delegated Admin relationships with customers",
    "id": "885f682f-a990-4bad-a642-36736a74b0c7",
    "isEnabled": true,
     "type": "Admin",
    "value": "DelegatedAdminRelationship.ReadWrite.All"
},
{
    "adminConsentDisplayName": "Sign in and read user profile",
    "id": "e1fe6dd8-ba31-4d61-89e7-88639da4683d",
    "isEnabled": true,
    "type": "User",
    "value": "User.Read"
},
{
    "adminConsentDisplayName": "Read directory data",
    "id": "06da0dbc-49e2-44d2-8312-53f166ab848a",
    "isEnabled": true,
    "type": "Admin",
    "value": "Directory.Read.All"
},
{
    "adminConsentDisplayName": "Read and write directory data",
    "id": "c5366453-9fb0-48a5-a156-24f0c49a4b84",
    "isEnabled": true,
    "type": "Admin",
    "value": "Directory.ReadWrite.All"
},

Säkerhetsansvariga saknas i en kundtenant

API:et för applikationstillstånd kräver att applikations-API:erna (tjänstprincipalerna) finns i kundens klientorganisation. Du kan se ett felmeddelande som i följande exempel när du samtycker. Det signalerar att programmet inte finns i kundens klientorganisation.

"Appen försöker komma åt en tjänst '22223333-cccc-4444-dddd-5555eeee6666' (Office 365 Management API:er) som din organisation "contosoxyz.onmicrosoft.com" saknar tjänstens huvudnamn för. Kontakta din IT-administratör för att granska konfigurationen av dina tjänstprenumerationer eller ge samtycke till programmet för att skapa det nödvändiga tjänsthuvudnamnet.

Exempelfelet säger att Office 365 Management-API:et inte är installerat i kundens klientorganisation. För förutsättningar för att säkerställa att tjänstens huvudkonto är installerat, se Komma igång med Office 365 Management API:er.

Om du vill kontrollera att det finns ett huvudnamn för tjänsten i kundens klientorganisation kan du anropa Graph API för servicePrincipals i den klientorganisationen.

För den applikation som behöver medgivande i kundens klientorganisation kan du fråga applikationens requiredResourceAccess matris. För varje instans resourceAppId i matrisen kan du anropa API:et i målnoden. Ersätt {resourceIDvalue} med värdet resourceAppId.

https://graph.microsoft.com/v1.0/servicePrincipals?$filter=appid eq '{resourceID value}'&$select=id,appId,appDisplayName

Till exempel:

https://graph.microsoft.com/v1.0/servicePrincipals?$filter=appid eq '22223333-cccc-4444-dddd-5555eeee6666'&$select=id,appId,appDisplayName

Det här är resultatet om tjänstens principal hittas:

    "value": [
        {
            "id": "6cf71994-a896-4e8a-a7a4-6d64276bf370",
            "appId": "22223333-cccc-4444-dddd-5555eeee6666",
            "appDisplayName": "Office 365 Management APIs"
        }
    ]

Det här är resultatet om tjänstens huvudnamn inte hittas:

    "value": []

Resultatet avgör din väg framåt: utelämna tjänstens huvudnamn, avgöra varför ett huvudnamn för tjänsten saknas för en kund eller andra åtgärder som är specifika för ditt företag.

Om du har rollen Global administratör i en kunds klientorganisation kan du godkänna appen själv. I fall där kunden inte vill godkänna rollen Global administratör kan du be dem att ange URI:n i en webbläsare och manuellt samtycka själva. När medgivandet har slutförts bör din app kunna köras med den GDAP-aktiverade kunden.

Skapa en URI på följande sätt för att få medgivande för din app i kundens klientorganisation. Ersätt {customertenant} med kundens klientorganisation. Ersätt {appid} med den app som du vill ge medgivande för.

https://login.microsoftonline.com/{customertenant}.onmicrosoft.com/adminconsent?client_id={appid}

Ange den nyligen konstruerade URI:n i en webbläsare och följ instruktionerna för inloggning och medgivande.

Resurser

Följande resurslänkar är en föreslagen läsordning:

GDAP-ansökningssamtycke
- PartnerCenter-autentisering: partnermedgivande
- CPV/CSP API för ett program: kundens medgivande
Säker programmodell
Microsofts identitetsplattform

Feedback

Var den här sidan till hjälp?

Last updated on 2025-03-12

Migrera dina CPV/CSP-program för att använda detaljerade delegerade administratörsbehörigheter

Jämförelse av GDAP med DAP

Programbehörigheter och Microsoft Entra-användarroller

Applikationsmedgivande

Explicit medgivande endast för fleranvändarapplikationer

Uttalat program med flera hyresgäster + användarmedgivande

Användning av ett administratörskonto för att ge medgivande åt användare i den säkra programmodellen

API för medgivande