Vanliga frågor och svar om GDAP

Någon med administratörsagent roll i en partnerorganisation kan skapa en GDAP-relationsbegäran.

Ja. GDAP-relationsbegäranden upphör att gälla efter 90 dagar.

Nej. Permanenta GDAP-relationer med kunder är inte möjliga av säkerhetsskäl. Den maximala varaktigheten för en GDAP-relation är två år. Du kan ange Utöka automatiskt till Aktiverad för att utöka en administratörsrelation med sex månader tills avslutad eller automatisk förlängning har angetts till Inaktiverad.

Nej. GDAP-relationen stöder inte prenumerationer som köpts via företagsavtal.

Ja. En GDAP-relation kan förlängas automatiskt med sex månader tills den avslutas eller automatiskt utökas till Inaktiverad.

• Om GDAP-relationen med kunden upphör begära en GDAP-relation igen.
• Du kan använda GDAP-relationsanalys för att spåra förfallodatum för GDAP-relationer och förbereda för förnyelse.

Om du vill utöka eller förnya en GDAP-relation måste en partner eller kund ange Utöka automatiskt till Aktiverad. Läs mer i Manage GDAP Auto extend and API.

Ja. Om GDAP är aktivt kan det utökas.

Anta att en GDAP har skapats i 365 dagar med automatisk utökning inställd på Aktiverad. Den 365:e dagen uppdateras slutdatumet effektivt med 180 dagar.

Ja. Du kan utöka alla aktiva GDAP automatiskt.

Nej. Kundens medgivande krävs inte för att ange automatisk utökning till Aktiverad mot ett befintligt aktivt GDAP.

Nej. Detaljerade behörigheter som har tilldelats till säkerhetsgrupper fortsätter as-is.

Nej. Du kan inte utöka administratörsrelationen automatiskt med en global administratörsroll.

Sidan Förfallna detaljerade relationer är endast tillgänglig för partneranvändare med rollerna Globala administratörer och Administratörsagent. Den här sidan hjälper till att filtrera GDAP:er som upphör att gälla mellan olika tidslinjer och hjälper till att uppdatera automatisk utökning (aktivera/inaktivera) för en eller flera GDAP:er.

Nej. En kunds befintliga prenumerationer ändras inte när en GDAP-relation upphör att gälla.

Se Felsöka problem med multifaktorautentisering i Microsoft Entra och Kan inte använda Microsoft Entra multifaktorautentisering för att logga in på molntjänster när du har förlorat din telefon eller telefonnumret ändras för vägledning.

En partner måste begära administratör för privilegierad autentisering Microsoft Entra-rollen när du skapar den första GDAP:n.

• Med den här rollen kan en partner återställa ett lösenord och autentiseringsmetoden för en administratör eller icke-administratörsanvändare. Administratörsrollen privilegierad autentisering är en del av de roller som konfigurerats av Microsoft Led Tool och planeras vara tillgänglig med GDAP som standard under Skapa kundflöde (planerat till september).
• Partnern kan låta kundadministratören prova Återställa lösenordet.
• Som en försiktighetsåtgärd måste partnern konfigurera SSPR (självbetjäning av lösenordsåterställning) för sina kunder. Mer information finns i Låt användarna återställa sina egna lösenord.

• I en partner organisation får personer med administratörsagenten rollen ett meddelande om uppsägning.
• Inom en kund organisation får personer med rollen global administratör en uppsägningsavisering.

Ja. Partner kan se när en kund tar bort GDAP i partnercentrets aktivitetsloggar.

Nej. GDAP är en valfri funktion för partner som vill hantera sina kunders tjänster på ett mer detaljerat och tidsbundet sätt. Du kan välja vilka kunder du vill skapa en GDAP-relation med.

Svaret beror på hur du vill hantera dina kunder.

• Om du vill att dina partneranvändare ska kunna hantera alla kunder kan du placera alla dina partneranvändare i en säkerhetsgrupp och den gruppen kan hantera alla dina kunder.
• Om du föredrar att ha olika partneranvändare som hanterar olika kunder tilldelar du dessa partneranvändare till separata säkerhetsgrupper för kundisolering.

Ja. Indirekta återförsäljare (och indirekta leverantörer och direktfaktureringspartner) kan skapa GDAP-relationsbegäranden i Partnercenter.

Som en del av GDAP-konfigurationen kontrollerar du att säkerhetsgrupper som skapats i partnerklientorganisationen med partneranvändare har valts. Kontrollera också att önskade Microsoft Entra-roller har tilldelats till säkerhetsgruppen. Läs Tilldela Microsoft Entra-roller.

Kunder kan nu exkludera CSP:er från principen för villkorsstyrd åtkomst så att partner kan övergå till GDAP utan att blockeras.

• Inkludera användare – Den här listan över användare innehåller vanligtvis alla användare som en organisation riktar in sig på i en princip för villkorsstyrd åtkomst.
• Följande alternativ är tillgängliga när du skapar en princip för villkorsstyrd åtkomst:
• Välj användare och grupper
• Gästanvändare eller externa användare (förhandsversion)
• Det här valet innehåller flera alternativ som kan användas för att rikta principer för villkorsstyrd åtkomst till specifika gäst- eller externa användartyper och specifika klientorganisationer som innehåller dessa typer av användare. Det finns flera olika typer av gästanvändare eller externa användare som kan väljas och flera val kan göras:
• Tjänstleverantörsanvändare, till exempel en molnlösningsleverantör (CSP).
• Du kan ange en eller flera klienter för de valda användartyperna, eller så kan du ange alla klienter.
• extern partneråtkomst – Principer för villkorsstyrd åtkomst som riktar sig till externa användare kan störa tjänstleverantörens åtkomst, till exempel detaljerade delegerade administratörsbehörigheter. Mer information finns i Introduktion till detaljerade delegerade administratörsprivilegier (GDAP). För principer som är avsedda att rikta in sig på klientorganisationer för tjänstleverantörer använder du -tjänstleverantörens användare externa användartyp som är tillgänglig i gäst eller externa användare alternativ för val.
• Exkludera användare – När organisationer både inkluderar och exkluderar en användare eller grupp undantas användaren eller gruppen från principen, eftersom en exkluderingsåtgärd åsidosätter en inkluderingsåtgärd i principen.
• Följande alternativ är tillgängliga att undanta när du skapar en princip för villkorsstyrd åtkomst:
• Gästanvändare eller externa användare
• Det här valet innehåller flera alternativ som kan användas för att rikta principer för villkorsstyrd åtkomst till specifika gäst- eller externa användartyper och specifika klientorganisationer som innehåller dessa typer av användare. Det finns flera olika typer av gästanvändare eller externa användare som kan väljasoch flera val kan göras:
• Tjänstleverantörsanvändare, till exempel en molnlösningsleverantör (CSP)
• En eller flera klienter kan anges för de valda användartyperna, eller så kan du ange alla klienter. Mer information finns i:
• Graph API Experience: Beta-API:et med den nya externa användartypsinformationen
• princip för villkorlig åtkomst
• externa användare med villkorlig åtkomst

Ja. Oavsett vilken supportplan du har är den minst privilegierade rollen för partneranvändare att kunna skapa supportärenden för sin kund tjänstsupportadministratör.

Nej. Partnern kan för närvarande inte avsluta en GDAP i Godkännande väntar på status. Den upphör att gälla om 90 dagar om kunden inte vidtar några åtgärder.

Först efter 365 dagar (rensning) efter att GDAP-relationen har avslutats eller upphör att gälla kan du återanvända samma namn för att skapa en ny GDAP-relation.

Ja. En partner kan hantera sina kunder i flera regioner utan att skapa nya partnerklienter per kundregion. Den gäller endast för den kundhanteringsroll som tillhandahålls av GDAP (Admin Relationships). Transaktionsrollen och funktionerna är fortfarande begränsade till ditt auktoriserade område.

Nej. En tjänstleverantör kan inte ingå i flera klientorganisationer, utan de är ömsesidigt uteslutande.

1. Kontrollera att GDAP har konfigurerats korrekt, inklusive hur du beviljar behörigheter för säkerhetsgrupper.
2. Kontrollera att dina detaljerade behörigheter för säkerhetsgrupper är korrekta.
3. Mer information finns i vanliga frågor och svar om Security Copilot.

Mer information om API:er och GDAP finns i utvecklardokumentationen för PartnerCenter.

Ja. Vi rekommenderar att partner använder BETA GDAP-API:er för produktion och senare växlar till API:er v.1 när de blir tillgängliga. Även om det finns en varning om att "Användning av dessa API:er i produktionsprogram inte stöds" är den allmänna vägledningen för beta-API:et under Graph och inte tillämpligt för BETA GDAP Graph-API:er.

Ja. Du kan skapa GDAP-relationer med hjälp av API:er, vilket gör det möjligt för partner att skala den här processen. Men att skapa flera GDAP-relationer är inte tillgängligt i Partnercenter. Information om API:er och GDAP finns i utvecklardokumentationen för PartnerCenter.

API:et fungerar för en säkerhetsgrupp i taget, men du kan mappa flera säkerhetsgrupper till flera roller i Partnercenter.

Gör enskilda anrop för varje resurs. När du gör en enda POST-begäran skickar du bara en resurs och dess motsvarande omfång. Om du till exempel vill begära behörigheter för både https://graph.windows.net/Directory.AccessAsUser.All och https://graph.microsoft.com/Organization.Read.Allgör du två olika begäranden, en för var och en.

Använd den angivna länken för att söka efter resursnamnet: Verifiera Microsoft-program från första part i inloggningsrapporter – Active Directory. Om du till exempel vill hitta resurs-ID 00000003-0000-0000-c000-0000000000000 för graph.microsoft.com:

Det här felet uppstår vanligtvis när en felaktig identifierare används i frågefiltret. Lös problemet genom att kontrollera att du använder egenskapen enterpriseApplicationId med rätt resurs-ID, inte resursnamnet.

• Felaktig begäran För enterpriseApplicationIdska du inte använda ett resursnamn som graph.microsoft.com.
• Korrekt begäran Använd i stället resurs-ID för enterpriseApplicationId, till exempel 00000003-0000-0000-c000-000000000000000.

Tidigare i graph.microsoft.com resursen godkändes till exempel endast "profilomfånget". Nu måste vi lägga till profil och user.read också. Så här lägger du till nya omfång i ett tidigare godkänt program:

1. Använd metoden DELETE för att återkalla det befintliga programmedgivandet från kundens klientorganisation.
2. Använd POST-metoden för att skapa ett nytt programmedgivande med de extra omfången.

Sammanfoga de nödvändiga omfången med hjälp av ett kommatecken följt av ett blanksteg. Till exempel "scope": "profile, User.Read"

1. Bekräfta att egenskaperna "displayName" och "applicationId" i begärandetexten är korrekta och matchar det program som du försöker godkänna i kundens klientorganisation.
2. Se till att du använder samma program för att generera den åtkomsttoken som du försöker godkänna i kundens klientorganisation. Exempel: Om program-ID:t är "12341234-1234-12341234" ska "appId"-anspråket i åtkomsttoken också vara "12341234-1234-1234-12341234".
3. Kontrollera att något av följande villkor är uppfyllt:

• Du har ett aktivt delegerat administratörsprivilegier (DAP) och användaren är också medlem i säkerhetsgruppen Administratörsagenter i partnerklientorganisationen.
• Du har en aktiv GDAP-relation (Granular Delegated Admin Privilege) med kundklientorganisationen med minst en av följande tre GDAP-roller och du har slutfört åtkomsttilldelningen:
  • Global administratör, programadministratör eller molnprogramadministratörsroll.
  • Partneranvändaren är medlem i säkerhetsgruppen som anges i åtkomsttilldelningen.

• Om du vill hantera Azure med åtkomstpartitionering per kund (vilket är den rekommenderade bästa praxisen) skapar du en säkerhetsgrupp (till exempel Azure Managers) och kapsla den under Administratörsagenter.
• För att få åtkomst till en Azure-prenumeration som ägare för en kund kan du tilldela alla inbyggda Microsoft Entra-roll (till exempel Directory-läsare, den minst privilegierade rollen) till Azure Managers säkerhetsgrupp. Stegen för att konfigurera Azure GDAP finns i arbetsbelastningar som stöds av detaljerade delegerade administratörsprivilegier (GDAP).

Ja. Information om hur du begränsar en användares administratörsbehörigheter genom att tilldela minst privilegierade roller i Microsoft Entra finns i Minst privilegierade roller efter uppgift i Microsoft Entra.

Vi rekommenderar att du tilldelar -tjänstens supportadministratör rollen. Mer information finns i Minst privilegierade roller efter uppgift i Microsoft Entra.

• För att minska klyftan mellan Microsoft Entra-roller som är tillgängliga i Partnercenter-API:et jämfört med användargränssnittet finns en lista med nio roller tillgängliga i Partnercenter-användargränssnittet i juli 2024.
• Under Samarbete:
  • Microsoft Edge-administratör
  • Administratör för virtuella besök
  • Viva-måladministratör
  • Viva Pulse-administratör
  • Yammer-administratör
• Under Identitet:
  • Administratör för behörighetshantering
  • Administratör för livscykelarbetsflöden
• Under Övrigt:
  • Organisationsanpassningsadministratör
  • Godkännare för organisationsmeddelanden

• För att minska klyftan mellan Microsoft Entra-roller som är tillgängliga i Partnercenter-API:et jämfört med användargränssnittet gjordes en lista med 17 roller tillgängliga i Partnercenter-användargränssnittet i december 2024.
• Under Samarbete:
  • Insights-analytiker
  • Microsoft 365-migreringsadministratör
  • Författare av organisationsmeddelanden
  • SharePoint Embedded-administratör
  • Teams telefoniadministratör
  • Hanteraren för användarupplevelse
• Under Enheter:
  • Microsofts administratör för maskinvarugaranti
  • Microsoft Hardware Warranty Specialist
• Under Identitet:
  • Attributtilldelningsadministratör
  • Attributtilldelningsläsare
  • Attributdefinitionsadministratör
  • Attributdefinitionsläsare
  • Administratör för attributlogg
  • Attributloggläsare
  • Utökningsbarhetsadministratör för autentisering
  • Global administratör för säker åtkomst
  • Skapare av klientorganisation

Nej. Den minst privilegierade rollen för partneranvändare att kunna skapa supportärenden för sina kunder är supportadministratören för tjänsten. För att kunna skapa supportärenden för kunden måste en partneranvändare därför vara i en säkerhetsgrupp och tilldelas den kunden med den rollen.

Information om alla roller finns i inbyggda Microsoft Entra-roller. Information om arbetsbelastningar finns i Arbetsbelastningar som stöds av detaljerade delegerade administratörsprivilegier (GDAP).

Många roller används för Administrationscenter för Microsoft 365. Mer information finns i Roller i administrationscenter för Microsoft 365 som används ofta.

Ja. Skapa en säkerhetsgrupp, tilldela godkända roller och tilldela sedan partnerklientanvändare till den säkerhetsgruppen.

Skrivskyddad åtkomst till kundens prenumerationer tillhandahålls av Global läsare, Directory-läsareoch partnernivå 2 stöder roller.

Vi rekommenderar att du tar bort partneragenterna från administratörsagenten roll och lägger endast till dem i en GDAP-säkerhetsgrupp. På så sätt kan de administrera tjänster (t.ex. tjänsthantering och loggtjänstbegäranden), men de kan inte köpa och hantera prenumerationer (ändra kvantitet, avbryta, schemalägga ändringar och så vidare).

De säkerhetsgrupper som tilldelats relationen förlorar åtkomsten till kunden. Samma sak händer om en kund avslutar en DAP-relation.

Ja. Om du tar bort GDAP-relationerna med en kund avslutas inte partnerns återförsäljarrelation med kunden. Partner kan fortfarande köpa produkter för kunden och hantera Azure-budget och andra relaterade aktiviteter.

Nej. Alla roller i en GDAP-relation har samma tid till förfallodatum: den varaktighet som valdes när relationen skapades.

Nej. Du behöver inte GDAP för att uppfylla order för nya och befintliga kunder. Du kan fortsätta att använda samma process för att uppfylla kundbeställningar i Partnercenter.

GDAP-relationer är per kund. Du kan ha flera relationer per kund. Varje GDAP-relation kan ha olika roller och använda olika Microsoft Entra-grupper i din CSP-klientorganisation. I Partnercenter fungerar rolltilldelning på relationsnivå från kund till GDAP. Om du vill tilldela fleranpassade roller kan du automatisera med HJÄLP av API:er.

GDAP-gästadministratörer kan inte hantera sin egen säkerhetsinformation på My Security-Info. I stället behöver de hjälp av klientadministratören som de är gäst i för registrering, uppdatering eller borttagning av säkerhetsinformation. Organisationer kan konfigurera åtkomstprinciper mellan klientorganisationer för att lita på MFA från den betrodda CSP-klientorganisationen. Annars är GDAP-gästadministratörer begränsade till endast metoder som kan registreras av klientorganisationens administratör (som är SMS eller Röst). Mer information finns i åtkomstprinciper mellan klientorganisationer.

Anpassa till principen Guiding för Noll förtroende: Använd åtkomst med minst behörighet:

• Vi rekommenderar att du använder en minst privilegierad roll efter aktivitet- och arbetsbelastningsuppgifter arbetsbelastningar som stöds av detaljerade delegerade administratörsprivilegier (GDAP) som stöds av GDAP.
• När det är nödvändigt att kringgå kända problem kan du kontakta kunden för att begära en tidsbunden global administratörsroll.
• Vi inte rekommenderar att du ersätter rollen Global administratör med alla möjliga Microsoft Entra-roller.

Ja. Under övergångsperioden samexisterar DAP och GDAP, med GDAP-behörigheter som har företräde framför DAP-behörigheter för Microsoft 365, Dynamics 365och Azure arbetsbelastningar.

DAP och GDAP samexisterar under övergångsperioden. Men så småningom ersätter GDAP DAP för att säkerställa att vi tillhandahåller en säkrare lösning för våra partners och kunder. Vi rekommenderar att du övergår till GDAP så snart som möjligt för att säkerställa kontinuitet.

Det finns inga ändringar i det befintliga DAP-relationsflödet medan DAP och GDAP samexisterar.

DAP beviljas för närvarande när en ny kundklientorganisation skapas. Den 25 september 2023 beviljar Microsoft inte längre DAP för att skapa nya kunder och beviljar i stället GDAP-standard med specifika roller. Standardrollerna varierar beroende på partnertyp, enligt följande tabell:

Partner kan implementera Privileged Identity Management (PIM) på en GDAP-säkerhetsgrupp i partnerns klientorganisation för att öka åtkomsten för några användare med hög behörighet, precis i tid (JIT) för att ge dem högprivilegier som lösenordsadministratörer med automatisk borttagning av åtkomst. Fram till januari 2023krävdes att varje Privileged Access Group (tidigare namn på funktionen PIM för grupper) måste finnas i en rolltilldelningsbar grupp. Den här begränsningen har nu tagits bort. Med tanke på den här ändringen är det möjligt att aktivera fler än 500 grupper per klientorganisation i PIM, men endast upp till 500 grupper kan vara rolltilldelningsbara. Sammanfattning:

• Partner kan använda både rolltilldelningsbara och icke-rolltilldelningsbara grupper i PIM. Det här alternativet tar effektivt bort gränsen för 500 grupper/klientorganisation i PIM.
• Med de senaste uppdateringarna finns det två sätt att registrera grupp till PIM (UX-vis): från menyn PIM eller från menyn Grupper. Oavsett hur du väljer är nettoresultatet detsamma.
  • Det finns redan möjlighet att registrera rolltilldelningsbara/icke-rolltilldelningsbara grupper via PIM-menyn.
  • Det finns redan möjlighet att registrera rolltilldelningsbara/icke-rolltilldelningsbara grupper via menyn Grupper.
• Mer information finns i Privileged Identity Management (PIM) för grupper (förhandsversion) – Microsoft Entra.

GDAP är allmänt tillgängligt med stöd för alla microsofts kommersiella molntjänster (Microsoft 365, Dynamics 365, Microsoft Azureoch Microsoft Power Platform arbetsbelastningar). Om du vill ha mer information om hur DAP och GDAP kan samexistera och hur GDAP prioriteras kan du söka efter Hur har GDAP-behörigheter företräde framför DAP-behörigheter medan DAP och GDAP samexisterar? fråga.

Du kan utföra den här åtgärden med API:er.

Nej. Dina PEC-intäkter påverkas inte när du övergår till GDAP. Det finns inga ändringar i PAL med övergången, vilket säkerställer att du fortsätter att tjäna PEC.

• Om en partners kund endast har DAP och DAP tas bort går inte PEC förlorad.
• Om en partners kund har DAP och de flyttar till GDAP för Microsoft 365 och Azure samtidigt, och DAP tas bort, går PEC inte förlorat.
• Om partnerns kund har DAP och de flyttar till GDAP för Microsoft 365 men behåller Azure as-is (de flyttar inte till GDAP) och DAP tas bort går PEC inte förlorad, men åtkomsten till Azure-prenumerationen går förlorad.
• Om en RBAC-roll tas bort går PEC förlorad, men om du tar bort GDAP tas inte RBAC bort.

När användaren ingår i både GDAP-säkerhetsgruppen och GRUPPEN DAP-administratörsagenter och kunden har både DAP- och GDAP-relationer har GDAP-åtkomst företräde på partner-, kund- och arbetsbelastningsnivå.

Om en partneranvändare till exempel loggar in för en arbetsbelastning och det finns DAP för rollen Global administratör och GDAP för rollen Global läsare, får partneranvändaren endast behörigheter för global läsare.

Om det finns tre kunder med GDAP-rolltilldelningar till endast GDAP-säkerhetsgruppen (inte administratörsagenter):

I följande tabell beskrivs vad som händer när en användare loggar in på en annan kundklientorganisation.

DAP och GDAP är inte berättigade associationstyper för Solutions Partner-beteckningar. aDisabling eller övergång från DAP till GDAP påverkar inte uppnåendet av Solutions Partner-beteckningar. Dessutom påverkas inte förnyelse av äldre kompetensfördelar eller Solutions Partner-förmåner. Om du vill visa de andra partnerassociationstyperna som är berättigade till lösningspartnerbeteckningen kan du läsa Partner Center Solutions Partnerbeteckningar.

När det gäller relationen mellan Azure Lighthouse och DAP/GDAP kan du betrakta dem som frikopplade parallella sökvägar till Azure-resurser. Att skära av den ena borde inte påverka den andra.

• I Azure Lighthouse-scenariot loggar användare från partnerklientorganisationen aldrig in på kundklientorganisationen och har inga Microsoft Entra-behörigheter i kundklientorganisationen. Deras Azure RBAC-rolltilldelningar behålls också i partnerklientorganisationen.
• I GDAP-scenariot loggar användare från partnerklientorganisationen in på kundklientorganisationen. Azure RBAC-rolltilldelningen till gruppen Administratörsagenter finns också i kundklientorganisationen. Du kan blockera GDAP-sökvägen (användarna kan inte längre logga in) medan Azure Lighthouse-sökvägen inte påverkas. Däremot kan du bryta Lighthouse-relationen (projektion) utan att påverka GDAP. Mer information finns i dokumentationen Azure Lighthouse.

Hanterade tjänstleverantörer (MSP) som registrerats i CSP-programmet (Cloud Solution Provider) som indirekta återförsäljare eller direktfaktura partner nu kan använda Microsoft 365 Lighthouse för att konfigurera GDAP för alla kundklientorganisationer. Eftersom det redan finns några sätt för partner att hantera övergången till GDAP låter den här guiden Lighthouse-partner anta rollrekommendationer som är specifika för deras affärsbehov. Det gör också att de kan vidta säkerhetsåtgärder som just-in-time-åtkomst (JIT). MSP:er kan också skapa GDAP-mallar via Lighthouse för att enkelt spara och tillämpa inställningar som möjliggör åtkomst till minst privilegierade kunder. Mer information och om du vill visa en demo finns i installationsguiden för Lighthouse GDAP. MSP:er kan konfigurera GDAP för alla kundklientorganisationer i Lighthouse. För att få åtkomst till kundens arbetsbelastningsdata i Lighthouse krävs en GDAP- eller DAP-relation. Om GDAP och DAP samexisterar i en kundklientorganisation har GDAP-behörigheter företräde för MSP-tekniker i GDAP-aktiverade säkerhetsgrupper. Mer information om kraven för Microsoft 365 Lighthouse finns i Krav för Microsoft 365 Lighthouse.

Rätt sekvens att följa för det här scenariot är:

1. Skapa en GDAP-relation för både Microsoft 365 och Azure.
2. Tilldela Microsoft Entra-roller till säkerhetsgrupper för både Microsoft 365 och Azure.
3. Konfigurera GDAP att ha företräde framför DAP.
4. Ta bort DAP.

Följande sekvens kan leda till att förlorar åtkomst till Azure-prenumerationer:

1. Ta bort DAP. Du förlorar inte nödvändigtvis åtkomsten till en Azure-prenumeration genom att ta bort DAP. Men just nu kan du inte bläddra i kundens katalog för att utföra några Azure RBAC-rolltilldelningar (till exempel tilldela en ny kundanvändare som prenumerations-RBAC-deltagare).
2. Skapa en GDAP-relation för både Microsoft 365 och Azure tillsammans. Du kan förlora åtkomsten till Azure-prenumerationen i det här steget så snart GDAP har konfigurerats.
3. Tilldela Microsoft Entra-roller till säkerhetsgrupper för både Microsoft 365 och Azure

Du får åtkomst till Azure-prenumerationer igen när Azure GDAP-installationen har slutförts.

Om du har Azure-prenumerationer utan DAP- som du hanterar som ägare kan du förlora åtkomsten till Azure-prenumerationerna när du lägger till GDAP för Microsoft 365 till kunden. För att undvika förlorad åtkomst flyttar du kunden till Azure GDAP samtidigt att du flyttar kunden till Microsoft 365 GDAP.

Nej. Relationer, när de har accepterats, kan inte återanvändas.

Om du har en befintlig återförsäljarrelation med kunden måste du fortfarande upprätta en GDAP-relation för att hantera deras Azure-prenumerationer.

1. Skapa en säkerhetsgrupp (till exempel Azure Managers) i Microsoft Entra.
2. Skapa en GDAP-relation med katalogläsare roll.
3. Gör säkerhetsgruppen till medlem i gruppen Admin Agent. När du har slutfört de här stegen kan du hantera kundens Azure-prenumeration via AOBO. Du kan inte hantera prenumerationen via CLI/PowerShell.

Ja. Du kan skapa en Azure-plan även om det inte finns någon DAP- eller GDAP-relation med en befintlig återförsäljare. Men för att kunna hantera den prenumerationen behöver du DAP eller GDAP.

När partner övergår från DAP till GDAP måste de se till att följande finns på plats för att se företagsinformation:

• En aktiv GDAP-relation.
• Någon av följande Microsoft Entra-roller tilldelas: Global administratör, Katalogläsare, Global läsare. Se bevilja detaljerade behörigheter till säkerhetsgrupper.

När en CSP loggar in på kundens Azure-portal (portal.azure.come) med sina CSP-autentiseringsuppgifter och det finns en GDAP-relation, märker CSP att deras användarnamn är "user_" följt av ett visst nummer. Det visar inte deras faktiska användarnamn som i DAP. Det är avsiktligt.

Partner måste uttryckligen bevilja detaljerade behörigheter till säkerhetsgrupper i STANDARD-GDAP.
Från och med den 10 oktober 2023 är DAP inte längre tillgängligt med återförsäljarrelationer. Den uppdaterade länken Förfrågningsåterförsäljarrelation är tillgänglig i Partnercenter-användargränssnittet, och API-kontraktets egenskaps-URL :en "/v1/customers/relationship requests" returnerar inbjudnings-URL:en som ska skickas till administratören för kundklientorganisationen.

Ja, partner måste uttryckligen bevilja detaljerade behörigheter till säkerhetsgrupper i GDAP som standard för att hantera kunden.

Partner med återförsäljarrelation endast utan DAP eller GDAP kan skapa kunder, placera och hantera beställningar, ladda ned programvarunycklar, hantera Azure RI. De kan inte visa kundföretagsinformation, kan inte visa användare eller tilldela licenser till användare, kan inte logga biljetter för kundernas räkning och kan inte komma åt och administrera produktspecifika administrationscenter (till exempel Administrationscenter för Teams.)

För att en partner eller CPV ska få åtkomst till och hantera en kundklient måste appens tjänsthuvudnamn godkännas i kundens klientorganisation. När DAP är aktivt måste de lägga till appens tjänsthuvudnamn i administrationsagenternas SG i partnerklientorganisationen. Med GDAP måste partnern se till att deras app godkänns i kundens klientorganisation. Om appen använder delegerade behörigheter (App + Användare) och det finns en aktiv GDAP med någon av de tre rollerna (molnprogramadministratör, programadministratör, global administratör) api för medgivande kan användas. Om appen endast använder programbehörigheter måste den godkännas manuellt, antingen av partnern eller kunden som har någon av de tre rollerna (molnprogramadministratör, programadministratör, global administratör) med hjälp av url för administratörsmedgivande för hela klientorganisationen.

Om du ser följande fel:

"Vi kan inte verifiera din begäran om att skapa en ny GDAP-relation just nu. Observera att anonyma anslutningar inte tillåts för den här tjänsten. Om du tror att du har fått det här meddelandet i fel kan du prova din begäran igen. Välj om du vill veta mer om åtgärder som du kan vidta. Om problemet kvarstår kontaktar du supporten och referensmeddelandekoden 715-123220 och transaktions-ID: guid."

Ändra hur du ansluter till Microsoft så att identitetsverifieringstjänsten kan köras korrekt. Det hjälper till att säkerställa att ditt konto inte komprometteras och är kompatibelt med de regler som Microsoft måste följa.

Saker du kan göra:

• Rensa webbläsarens cacheminne.
• Inaktivera spårningsskydd i webbläsaren eller lägg till vår webbplats i din undantagslista/säkerhetslista.
• Inaktivera alla VPN-program (Virtual Private Network) eller tjänster som du kanske använder.
• Anslut direkt från din lokala enhet i stället för via en virtuell dator (VM).

Om du fortfarande inte kan ansluta när du har provat föregående steg rekommenderar vi att du konsulterar IT-supportavdelningen för att kontrollera inställningarna för att se om de kan hjälpa dig att identifiera vad som orsakar problemet. Ibland finns problemet i företagets nätverksinställningar. IT-administratören måste till exempel åtgärda problemet genom att ange vår webbplats på ett säkert sätt eller göra andra inställningar för nätverksinställningar.

• Begränsad (direktfaktura): Det går inte att skapa nya GDAP (administratörsrelationer). Befintliga GDAP:er och deras rolltilldelningar KAN uppdateras.
• Pausad (direktfakturering/indirekt leverantör/indirekt återförsäljare): Det går inte att skapa ny GDAP. Befintliga GDAP:er och deras rolltilldelningar KAN INTE uppdateras.
• Begränsad (direktfaktura) + Aktiv (indirekt återförsäljare): För begränsad direktfaktura: Det går inte att skapa nya GDAP (administratörsrelationer). Befintliga GDAP:er och deras rolltilldelningar KAN uppdateras. För aktiv indirekt återförsäljare: Nya GDAP KAN skapas, befintliga GDAP:er och deras rolltilldelningar KAN uppdateras. När det inte går att skapa en ny GDAP kan befintliga GDAP och deras rolltilldelningar inte uppdateras.

Ja. Den aktuella versionen av GDAP stöder alla produkter: Microsoft 365, Dynamics 365, Microsoft Power Platformoch Microsoft Azure.