Häufig gestellte Fragen zur GDAP

Jemand mit dem Administrator-Agent Rolle in einer Partnerorganisation kann eine GDAP-Beziehungsanforderungerstellen.

Ja. GDAP-Beziehungsanforderungen laufen nach 90 Tagen ab.

Nein. Dauerhafte GDAP-Beziehungen mit Kunden sind aus Sicherheitsgründen nicht möglich. Die maximale Dauer einer GDAP-Beziehung beträgt zwei Jahre. Sie können automatische Verlängerung auf Aktivierte festlegen, um eine Administratorbeziehung um sechs Monate zu verlängern, bis sie beendet oder automatisch auf Deaktiviertfestgelegt wird.

Nein. Die GDAP-Beziehung unterstützt keine Abonnements, die über Unternehmensvereinbarungen erworben wurden.

Ja. Eine GDAP-Beziehung kann bis zur Beendigung oder automatischen Verlängerung auf "Deaktiviert" um sechs Monate verlängert werden.

• Wenn die GDAP-Beziehung mit Ihrem Kunden abläuft, eine GDAP-Beziehung erneut anfordern.
• Sie können GDAP-Beziehungsanalyse verwenden, um Ablaufdaten der GDAP-Beziehung nachzuverfolgen und sich auf ihre Verlängerung vorzubereiten.

Um eine GDAP-Beziehung zu erweitern oder zu verlängern, muss ein Partner oder Kunde auto extend auf Enabledfestlegen. Weitere Informationen finden Sie unter Manage GDAP Auto Extend und API.

Ja. Wenn GDAP aktiv ist, kann sie erweitert werden.

Angenommen, ein GDAP wird für 365 Tage erstellt, wobei die automatische Verlängerung auf "Aktiviert" festgelegt ist. Am 365. Tag aktualisiert sich das Enddatum effektiv um 180 Tage.

Ja. Sie können alle aktiven GDAP automatisch erweitern.

Nein. Die Zustimmung des Kunden ist nicht erforderlich, um die automatische Erweiterung auf "Aktiviert" für ein vorhandenes aktives GDAP festzulegen.

Nein. Granulare Berechtigungen, die Sicherheitsgruppen zugewiesen sind, setzen as-isfort.

Nein. Sie können die Administratorbeziehung nicht automatisch mit einer Rolle eines globalen Administrators erweitern.

Die Seite "Ablaufende granulare Beziehungen" Seite ist nur für Partnerbenutzer mit den Rollen "Globale Administratoren" und "Administrator-Agent" verfügbar. Diese Seite hilft beim Filtern von GDAPs, die auf verschiedenen Zeitachsen ablaufen, und hilft beim Aktualisieren der automatischen Erweiterung (Aktivieren/Deaktivieren) für einen oder mehrere GDAPs.

Nein. Es gibt keine Änderung an den vorhandenen Abonnements eines Kunden, wenn eine GDAP-Beziehung abläuft.

Weitere Informationen finden Sie unter Behandlung von Problemen mit der mehrstufigen Authentifizierung von Microsoft Entra und Können microsoft Entra nicht mehr für die mehrstufige Authentifizierung verwenden, um sich bei Clouddiensten anzumelden, nachdem Sie Ihr Telefon verloren haben oder die Telefonnummer geändert.

Ein Partner muss beim Erstellen des ersten GDAP den Privileged Authentication Administrator Microsoft Entra-Rolle anfordern.

• Mit dieser Rolle kann ein Partner ein Kennwort und die Authentifizierungsmethode für einen Administrator oder nichtadmin-Benutzer zurücksetzen. Die Rolle "Administrator für privilegierte Authentifizierung" ist Teil der Rollen, die von Microsoft Led Tool eingerichtet wurden, und ist geplant, dass sie während des Erstellungs-Kundenflusses (geplant für September) mit dem Standard-GDAP verfügbar sein soll.
• Der Partner könnte den Kundenadministrator versuchen, das Kennwortzurückzusetzen .
• Als Vorsichtsmaßnahme muss der Partner SSPR (Self-Service Password Reset) für seine Kunden einrichten. Weitere Informationen finden Sie unter Zulassen, dass Personen ihre eigenen Kennwörterzurücksetzen können.

• Innerhalb einer Partner- Organisation erhalten Personen mit dem Administrator-Agent Rolle eine Kündigungsbenachrichtigung.
• Innerhalb einer Kunden- Organisation erhalten Personen mit dem globalen Administrator Rolle eine Kündigungsbenachrichtigung.

Ja. Partner können sehen, wenn ein Kunde GDAP in den Partner Center-Aktivitätsprotokollen entfernt.

Nein. GDAP ist eine optionale Funktion für Partner, die die Dienste ihrer Kunden präziser und zeitgebundener verwalten möchten. Sie können auswählen, mit welchen Kunden Sie eine GDAP-Beziehung erstellen möchten.

Die Antwort hängt davon ab, wie Sie Ihre Kunden verwalten möchten.

• Wenn Sie möchten, dass Ihre Partnerbenutzer alle Kunden verwalten können, können Sie alle Partnerbenutzer in einer Sicherheitsgruppe platzieren, und dass eine Gruppe alle Ihre Kunden verwalten kann.
• Wenn Sie mehrere Partnerbenutzer bevorzugen, die verschiedene Kunden verwalten, weisen Sie diesen Partnerbenutzern sicherheitsgruppen für die Kundenisolation zu.

Ja. Indirekte Wiederverkäufer (und indirekte Anbieter und Direktrechnungspartner) können GDAP-Beziehungsanfragen im Partner Center erstellen.

Stellen Sie im Rahmen der GDAP-Einrichtung sicher, dass Sicherheitsgruppen ausgewählt werden, die im Partnermandanten mit Partnerbenutzern erstellt wurden. Stellen Sie außerdem sicher, dass der Sicherheitsgruppe die gewünschten Microsoft Entra-Rollen zugewiesen sind. Weitere Informationen finden Sie unter Zuweisen von Microsoft Entra-Rollen.

Kunden können jetzt CSPs aus der Richtlinie für bedingten Zugriff ausschließen, damit Partner zu GDAP wechseln können, ohne blockiert zu werden.

• Benutzer einschließen – Diese Liste der Benutzer enthält in der Regel alle Benutzer, für die eine Organisation in einer Richtlinie für bedingten Zugriff ausgerichtet ist.
• Die folgenden Optionen stehen zum Erstellen einer Richtlinie für bedingten Zugriff zur Verfügung:
• Auswählen von Benutzern und Gruppen
• Gast- oder externe Benutzer (Vorschau)
• Diese Auswahl bietet mehrere Optionen, die verwendet werden können, um Richtlinien für bedingten Zugriff auf bestimmte Gast- oder externe Benutzertypen und bestimmte Mandanten zu richten, die diese Benutzertypen enthalten. Es gibt mehrere verschiedene Arten von Gast- oder externen Benutzern, die ausgewählt werden können, und mehrere Auswahlmöglichkeiten können getroffen werden:
• Dienstanbieterbenutzer, z. B. einen Cloud-Lösungsanbieter (Cloud Solution Provider, CSP).
• Sie können einen oder mehrere Mandanten für die ausgewählten Benutzertypen angeben oder alle Mandanten angeben.
• Zugriff auf externe Partner – Richtlinien für bedingten Zugriff, die auf externe Benutzer abzielen, können den Zugriff des Dienstanbieters beeinträchtigen, z. B. präzise delegierte Administratorrechte. Weitere Informationen finden Sie unter Einführung in granulare delegierte Administratorrechte (GDAP). Verwenden Sie für Richtlinien, die für Mandanten des Dienstanbieters vorgesehen sind, den Dienstanbieterbenutzer externen Benutzertyps, der in den Gast- oder externen Benutzern Auswahloptionen verfügbar ist.
• Benutzer ausschließen – Wenn Organisationen einen Benutzer oder eine Gruppe einschließen und ausschließen, wird der Benutzer oder die Gruppe von der Richtlinie ausgeschlossen, da eine Ausschlussaktion eine einschließende Aktion in einer Richtlinie außer Kraft setzt.
• Die folgenden Optionen stehen zum Ausschließen beim Erstellen einer Richtlinie für bedingten Zugriff zur Verfügung:
• Gast- oder externe Benutzer
• Diese Auswahl bietet mehrere Optionen, die verwendet werden können, um Richtlinien für bedingten Zugriff auf bestimmte Gast- oder externe Benutzertypen und bestimmte Mandanten zu richten, die diese Benutzertypen enthalten. Es gibt verschiedene Arten von Gast- oder externen Benutzern, dieausgewählt werden können, und mehrere Auswahlmöglichkeiten können getroffen werden:
• Dienstanbieterbenutzer, z. B. einen Cloud-Lösungsanbieter (CSP)
• Mindestens ein Mandant kann für die ausgewählten Benutzertypen angegeben werden, oder Sie können alle Mandanten angeben. Weitere Informationen finden Sie unter:
• Graph API Experience: Beta-API mit den neuen Informationen zum externen Benutzertyp
• Richtlinie für bedingten Zugriff
• externe Benutzer mit bedingtem Zugriff

Ja. Unabhängig vom Supportplan, den Sie haben, ist die Rolle mit den geringsten Rechten für Partnerbenutzer, um Supporttickets für ihren Kunden zu erstellen, der Servicesupportadministrator ist.

Nein. Der Partner kann derzeit ein GDAP im status Genehmigung ausstehend beenden. Er läuft in 90 Tagen ab, wenn der Kunde keine Maßnahmen ergreift.

Erst nach 365 Tagen (Bereinigung) nach Beendigung oder Ablauf der GDAP-Beziehung können Sie denselben Namen wiederverwenden, um eine neue GDAP-Beziehung zu erstellen.

Ja. Ein Partner kann seine Kunden regionenübergreifend verwalten, ohne neue Partnermandanten pro Kundenregion zu erstellen. Sie gilt nur für die Von GDAP (Administratorbeziehungen) bereitgestellte Kundenverwaltungsrolle. Transaktionsrolle und -funktionen sind weiterhin auf Ihr autorisiertes Gebietbeschränkt.

Nein. Ein Dienstanbieter kann nicht Teil einer mehrinstanzenübergreifenden Organisation sein, sie schließen sich gegenseitig aus.

1. Stellen Sie sicher, dass GDAP ordnungsgemäß eingerichtet ist, einschließlich der Erteilung von Berechtigungen für Sicherheitsgruppen.
2. Stellen Sie sicher, dass Ihre präzisen Sicherheitsgruppenberechtigungen korrekt sind.
3. Weitere Informationen finden Sie in den Security Copilot FAQ.

Weitere Informationen zu APIs und GDAP finden Sie in der Partner Center-Entwicklerdokumentation.

Ja. Es wird empfohlen, dass Partner die Beta-GDAP-APIs für die Produktion verwenden und später zu APIs v.1 wechseln, wenn sie verfügbar sind. Obwohl es eine Warnung gibt, "Die Verwendung dieser APIs in Produktionsanwendungen wird nicht unterstützt", ist die allgemeine Anleitung für jede Beta-API unter Graph und gilt nicht für die Beta-GDAP Graph-APIs.

Ja. Sie können GDAP-Beziehungen mithilfe von APIs erstellen, mit denen Partner diesen Prozess skalieren können. Das Erstellen mehrerer GDAP-Beziehungen ist jedoch nicht im Partner Center verfügbar. Informationen zu APIs und GDAP finden Sie in der Partner Center-Entwicklerdokumentation.

Die API funktioniert jeweils für eine Sicherheitsgruppe, Sie können jedoch mehrere Sicherheitsgruppen mehreren Rollen im Partner Center zuordnen.

Führen Sie einzelne Aufrufe für jede Ressource durch. Übergeben Sie beim Erstellen einer einzelnen POST-Anforderung nur eine Ressource und die entsprechenden Bereiche. Um z. B. Berechtigungen für https://graph.windows.net/Directory.AccessAsUser.All und https://graph.microsoft.com/Organization.Read.Allanzufordern, führen Sie jeweils zwei verschiedene Anforderungen aus.

Verwenden Sie den bereitgestellten Link, um nach dem Ressourcennamen zu suchen: Überprüfen von Microsoft-Anwendungen von Erstanbietern in Anmeldeberichten – Active Directory. Um beispielsweise die Ressourcen-ID 00000003-0000-0000-c000-0000000000000 für graph.microsoft.com zu finden:

Dieser Fehler tritt in der Regel auf, wenn im Abfragefilter ein falscher Bezeichner verwendet wird. Um dies zu beheben, stellen Sie sicher, dass Sie die enterpriseApplicationId Eigenschaft mit der richtigen Ressourcen-IDund nicht mit dem Ressourcennamen verwenden.

• Falsche Anforderung Für enterpriseApplicationId-verwenden Sie keinen Ressourcennamen wie graph.microsoft.com.
• Richtigen Anforderungs- Verwenden Sie stattdessen für enterpriseApplicationIddie Ressourcen-ID, z. B. 00000000-0000-0000-00000000000.

Beispielsweise wurde zuvor in graph.microsoft.com Ressource nur der Bereich "Profil" zugestimmt. Jetzt müssen wir auch profil und user.read hinzufügen. So fügen Sie einer zuvor zugestimmten Anwendung neue Bereiche hinzu:

1. Verwenden Sie die DELETE-Methode, um die vorhandene Anwendungszustimmung vom Mandanten des Kunden zu widerrufen.
2. Verwenden Sie die POST-Methode, um eine neue Anwendungszustimmung mit den zusätzlichen Bereichen zu erstellen.

Verketten Sie die erforderlichen Bereiche mithilfe eines Kommas, gefolgt von einem Leerzeichen. Beispiel: "scope": "profile, User.Read"

1. Vergewissern Sie sich, dass die Eigenschaften "displayName" und "applicationId" im Anforderungstext korrekt sind und der Anwendung entsprechen, die Sie dem Kundenmandanten zustimmen möchten.
2. Stellen Sie sicher, dass Sie dieselbe Anwendung verwenden, um das Zugriffstoken zu generieren, das Sie dem Kundenmandanten zustimmen möchten. Beispiel: Wenn die Anwendungs-ID "12341234-1234-1234-12341234" lautet, sollte der Anspruch "appId" im Zugriffstoken auch "12341234-1234-1234-12341234" sein.
3. Stellen Sie sicher, dass eine der folgenden Bedingungen erfüllt ist:

• Sie verfügen über ein aktives delegiertes Administratorrecht (Delegiertes Administratorrecht, DAP), und der Benutzer ist auch Mitglied der Sicherheitsgruppe "Admin Agents" im Partnermandanten.
• Sie verfügen über eine aktive granulare delegierte Administratorberechtigung (GDAP) mit dem Kundenmandanten mit mindestens einer der folgenden drei GDAP-Rollen, und Sie haben die Zugriffszuweisung abgeschlossen:
  • Rolle "Globaler Administrator", "Anwendungsadministrator" oder "Cloudanwendungsadministrator".
  • Der Partnerbenutzer ist Mitglied der Sicherheitsgruppe, die in der Zugriffszuweisung angegeben ist.

• Um Azure mit Partitionierung pro Kunde zu verwalten (dies ist die empfohlene bewährte Methode), erstellen Sie eine Sicherheitsgruppe (z. B. Azure Manager) und sie unter Administrator-Agentsverschachteln.
• Um auf ein Azure-Abonnement als Besitzer für einen Kunden zuzugreifen, können Sie jeder integrierten Microsoft Entra-Rollen- (z. B. Verzeichnisleser, die Rolle mit den geringsten Rechten) der sicherheitsgruppe Azure Managers zuweisen. Die Schritte zum Einrichten von Azure GDAP finden Sie unter Workloads, die von granularen delegierten Administratorrechten (GDAP)unterstützt werden.

Ja. Informationen zum Einschränken der Administratorberechtigungen eines Benutzers durch Zuweisen von Rollen mit den geringsten Rechten in Microsoft Entra finden Sie unter Rollen mit den geringsten Rechten nach Aufgabe in Microsoft Entra.

Es wird empfohlen, den Dienstsupportadministrator Rolle zuzuweisen. Weitere Informationen finden Sie unter Rollen mit den geringsten Rechten nach Aufgabe in Microsoft Entra.

• Um die Lücke zwischen den in der Partner Center-API verfügbaren Microsoft Entra-Rollen im Vergleich zur Benutzeroberfläche zu verringern, stehen im Juli 2024 eine Liste mit neun Rollen in der Partner Center-Benutzeroberfläche zur Verfügung.
• Unter Zusammenarbeit:
  • Microsoft Edge-Administrator
  • Administrator virtueller Besuche
  • Viva Goals-Administrator
  • Viva Pulse-Administrator
  • Yammer Administrator
• Unter Identität:
  • Berechtigungsverwaltungsadministrator
  • Lebenszyklusworkflows-Administrator
• Unter Anderen:
  • Organisationsbrandingadministrator
  • Genehmigende Organisation von Nachrichten

Nein. Die Am wenigsten privilegierte Rolle für Partnerbenutzer, um Supporttickets für ihren Kunden zu erstellen, ist der Service Support-Administrator. Damit sie Supporttickets für den Kunden erstellen können, muss sich ein Partnerbenutzer in einer Sicherheitsgruppe befinden und diesem Kunden mit dieser Rolle zugewiesen sein.

Informationen zu allen Rollen finden Sie unter integrierten Microsoft Entra-Rollen. Informationen zu Workloads finden Sie unter Workloads, die von granularen delegierten Administratorrechten (GDAP)unterstützt werden.

Viele Rollen werden für das Microsoft 365 Admin Center verwendet. Weitere Informationen finden Sie unter Häufig verwendete Microsoft 365 Admin Center-Rollen.

Ja. Erstellen Sie eine Sicherheitsgruppe, weisen Sie genehmigte Rollen zu, und weisen Sie dieser Sicherheitsgruppe Partnermandantenbenutzer zu.

Der schreibgeschützte Zugriff auf die Abonnements des Kunden wird vom globalen Reader, Verzeichnisleser-und Partnerebene 2 bereitgestellt, um Rollen zu unterstützen.

Es wird empfohlen, die Partner-Agents aus dem Administrator-Agent Rolle zu entfernen und sie nur einer GDAP-Sicherheitsgruppe hinzuzufügen. Auf diese Weise können sie Dienste verwalten (z. B. Dienstverwaltungs- und Protokolldienstanforderungen), aber sie können keine Abonnements kaufen und verwalten (Menge ändern, Kündigen, Planen von Änderungen usw.).

Die sicherheitsgruppen, die der Beziehung zugewiesen sind, verlieren den Zugriff auf diesen Kunden. Dasselbe geschieht, wenn ein Kunde eine DAP-Beziehung beendet.

Ja. Durch das Entfernen der GDAP-Beziehungen mit einem Kunden wird die Handelspartnerbeziehung der Partner mit dem Kunden nicht beendet. Partner können weiterhin Produkte für den Kunden erwerben und Azure-Budget und andere verwandte Aktivitäten verwalten.

Nein. Alle Rollen in einer GDAP-Beziehung haben die gleiche Zeit bis zum Ablauf: die Dauer, die beim Erstellen der Beziehung ausgewählt wurde.

Nein. Sie benötigen GDAP nicht, um Aufträge für neue und bestehende Kunden zu erfüllen. Sie können weiterhin denselben Prozess verwenden, um Kundenbestellungen im Partner Center zu erfüllen.

GDAP-Beziehungen sind pro Kunde. Sie können mehrere Beziehungen pro Kunde haben. Jede GDAP-Beziehung kann unterschiedliche Rollen haben und unterschiedliche Microsoft Entra-Gruppen innerhalb Ihres CSP-Mandanten verwenden. Im Partner Center funktioniert die Rollenzuweisung auf Kunden-zu-GDAP-Beziehungsebene. Wenn Sie eine Multicustomer-Rollenzuweisung verwenden möchten, können Sie die Verwendung von APIs automatisieren.

GDAP-Gastadministratoren können ihre eigenen Sicherheitsinformationen bei My Security-Infonicht verwalten. Stattdessen benötigen sie unterstützung des Mandantenadministrators, in dem er gastiert ist, um sicherheitsrelevante Informationen zu registrieren, zu aktualisieren oder zu löschen. Organisationen können mandantenübergreifende Zugriffsrichtlinien konfigurieren, um der MFA vom vertrauenswürdigen CSP-Mandanten zu vertrauen. Andernfalls sind GDAP-Gastadministratoren nur auf Methoden beschränkt, die vom Mandantenadministrator (sms oder Voice) registriert werden können. Weitere Informationen finden Sie unter mandantenübergreifende Zugriffsrichtlinien.

Richten Sie sich an das Leitprinzip Zero Trust: Verwenden Sie den geringsten Berechtigungszugriff:

• Es wird empfohlen, eine Rolle mit den geringsten Rechten nach Aufgaben und Workloadaufgaben Workloads zu verwenden, die von granularen delegierten Administratorrechten (GDAP) unterstützt, die von GDAP unterstützt werden.
• Wenn es erforderlich ist, die aufgeführten bekannten Probleme zu umgehen, arbeiten Sie mit Ihrem Kunden zusammen, um eine zeitgebundene globale Administratorrolle anzufordern.
• Wir nicht empfehlen, die Rolle "Globaler Administrator" durch alle möglichen Microsoft Entra-Rollen zu ersetzen.

Ja. Während des Übergangszeitraums werden DAP und GDAP koexistieren, wobei GDAP-Berechtigungen Vorrang vor DAP-Berechtigungen für Microsoft 365, Dynamics 365und Azure-Workloads haben.

DAP und GDAP koexistieren während des Übergangszeitraums. Schließlich ersetzt GDAP jedoch DAP, um sicherzustellen, dass wir eine sicherere Lösung für unsere Partner und Kunden bereitstellen. Wir empfehlen Ihnen, Ihre Kunden so bald wie möglich auf GDAP umzusteigen, um die Kontinuität sicherzustellen.

Es gibt keine Änderungen am vorhandenen DAP-Beziehungsfluss, während DAP und GDAP koexistieren.

DAP wird zurzeit gewährt, wenn ein neuer Kundemandant erstellt wird. Am 25. September 2023 gewährt Microsoft keine DAP mehr für die neue Kundenerstellung und gewährt stattdessen standardmäßige GDAP mit bestimmten Rollen. Die Standardrollen variieren je nach Partnertyp, wie in der folgenden Tabelle dargestellt:

Partner können Privileged Identity Management (PIM) für eine GDAP-Sicherheitsgruppe im Mandanten des Partners implementieren, um den Zugriff einiger Benutzer mit hohen Rechten zu erhöhen, nur rechtzeitig (JIT), um ihnen hochprivilegierte Rollen wie Kennwortadministratoren mit automatischer Entfernung des Zugriffs zu gewähren. Bis Januar 2023war es erforderlich, dass sich jede Privileged Access Group (früherer Name des PIM for Groups Feature) in einer rollenzuweisungsfähigen Gruppe befinden musste. Diese Einschränkung wird jetzt entfernt. Aufgrund dieser Änderung ist es möglich, mehr als 500 Gruppen pro Mandant in PIM-zu aktivieren, aber nur bis zu 500 Gruppen können rollenzuweisungsfähig sein. Zusammenfassung:

• Partner können sowohl rollenzuweisungsfähige als auch nicht rollenverwendbare-Gruppen in PIM verwenden. Diese Option entfernt effektiv den Grenzwert für 500 Gruppen/tenant in PIM.
• Mit den neuesten Updates gibt es zwei Möglichkeiten, Gruppe in PIM (UX-weise) zu integrieren: aus dem PIM--Menü oder aus dem menü Gruppen. Unabhängig von der gewählten Wahl ist das Nettoergebnis identisch.
  • Die Möglichkeit zum Onboarding von rollenzuweisungsfähigen/nicht rollenzuweisenden Gruppen über das PIM-Menü ist bereits verfügbar.
  • Die Möglichkeit zum Onboarding von rollenzuweisungsfähigen/nicht rollenzuweisenden Gruppen über das Menü "Gruppen" ist bereits verfügbar.
• Weitere Informationen finden Sie unter Privileged Identity Management (PIM) für Gruppen (Vorschau) – Microsoft Entra.

GDAP ist allgemein verfügbar mit Unterstützung für alle kommerziellen Microsoft Cloud Services (Microsoft 365, Dynamics 365, Microsoft Azureund Microsoft Power Platform Workloads). Weitere Informationen dazu, wie DAP und GDAP koexistieren können und wie GDAP Vorrang hat, finden Sie in den häufig gestellten Fragen (FAQ) nach der Wie haben GDAP-Berechtigungen Vorrang vor DAP-Berechtigungen, während DAP und GDAP koexistieren? Frage.

Sie können diese Aktion mit APIs ausführen.

Nein. Ihre PEC-Einnahmen sind nicht betroffen, wenn Sie zu GDAP wechseln. Es gibt keine Änderungen an PAL mit dem Übergang, um sicherzustellen, dass Sie weiterhin PEC verdienen.

• Wenn der Kunde eines Partners nur DAP hat und DAP entfernt wird, geht PEC nicht verloren.
• Wenn der Kunde eines Partners ÜBER DAP verfügt und er gleichzeitig zu GDAP für Microsoft 365 und Azure wechselt und DAP entfernt wird, geht PEC nicht verloren.
• Wenn der Kunde des Partners ÜBER DAP verfügt und er zu GDAP für Microsoft 365 wechselt, Azure as-is (sie werden nicht zu GDAP wechseln) und DAP entfernt wird, geht PEC nicht verloren, aber der Zugriff auf das Azure-Abonnement geht verloren.
• Wenn eine RBAC-Rolle entfernt wird, geht PEC verloren, aber das Entfernen von GDAP entfernt RBAC nicht.

Wenn der Benutzer teil der GDAP-Sicherheitsgruppe und der DAP Admin Agents-Gruppe ist und der Kunde sowohl ÜBER DAP- als auch GDAP-Beziehungen verfügt, hat GDAP-Zugriff Vorrang auf Partner-, Kunden- und Workloadebene.

Wenn sich beispielsweise ein Partnerbenutzer für eine Workload anmeldet und DAP für die Rolle "Globaler Administrator" und "GDAP" für die Rolle "Globaler Leser" vorhanden ist, erhält der Partnerbenutzer nur globale Leseberechtigungen.

Wenn drei Kunden mit GDAP-Rollenzuweisungen nur der GDAP-Sicherheitsgruppe (nicht den Administrator-Agents) zugewiesen sind:

In der folgenden Tabelle wird beschrieben, was passiert, wenn sich ein Benutzer bei einem anderen Kundenmandanten anmeldet.

DAP und GDAP sind keine geeigneten Zuordnungstypen für Solutions Partner-Bezeichnungen. Eine Deaktivierung oder Umstellung von DAP auf GDAP wirkt sich nicht auf Ihre Erreichung von Lösungspartnerbezeichnungen aus. Außerdem ist die Erneuerung von Legacy-Kompetenzvorteilen oder Solutions Partner-Vorteilen nicht betroffen. Informationen zum Anzeigen der anderen Partnerzuordnungstypen, die für die Bezeichnung "Solutions Partner Partner" berechtigt sind, finden Sie unter Partner Center Solutions Partner-Bezeichnungen.

In Bezug auf die Beziehung zwischen Azure Lighthouse und DAP/GDAP betrachten Sie sie als entkoppelte parallele Pfade zu Azure-Ressourcen. Das Abtrennen sollte sich nicht auf den anderen auswirken.

• Im Azure Lighthouse-Szenario melden sich Benutzer vom Partnermandanten nie beim Kundenmandanten an und verfügen nicht über Microsoft Entra-Berechtigungen im Kundenmandanten. Ihre Azure RBAC-Rollenzuweisungen werden auch im Partnermandanten gespeichert.
• Im GDAP-Szenario melden sich Benutzer vom Partnermandanten beim Kundenmandanten an. Die Azure RBAC-Rollenzuweisung der Gruppe "Admin Agents" befindet sich auch im Kundenmandanten. Sie können den GDAP-Pfad blockieren (Benutzer können sich nicht mehr anmelden), während der Azure Lighthouse-Pfad nicht betroffen ist. Umgekehrt können Sie die Lighthouse-Beziehung (Projektion) ohne Auswirkungen auf GDAP abtrennen. Weitere Informationen finden Sie in der Dokumentation Azure Lighthouse.

Verwaltete Dienstanbieter (Managed Service Providers, MSPs), die im CSP-Programm (Cloud Solution Provider) registriert sind, als indirekten Wiederverkäufer oder direkten Rechnung Partner können jetzt Microsoft 365 Lighthouse verwenden, um GDAP für jeden Kundenmandanten einzurichten. Da es einige Möglichkeiten gibt, wie Partner ihren Übergang zu GDAP bereits verwalten, kann dieser Assistent Lighthouse-Partner rollenspezifische Empfehlungen für ihre Geschäftsanforderungen übernehmen. Außerdem können sie Sicherheitsmaßnahmen wie just-in-time -Zugriff (JIT) ergreifen. MSPs können auch GDAP-Vorlagen über Lighthouse erstellen, um einfach Einstellungen zu speichern und erneut anzuwenden, die den zugriff am wenigsten privilegierten Kunden ermöglichen. Weitere Informationen und zum Anzeigen einer Demo finden Sie im Lighthouse GDAP-Setup-Assistenten. MSPs können GDAP für jeden Kundenmandanten in Lighthouse einrichten. Um auf die Workloaddaten des Kunden in Lighthouse zuzugreifen, ist eine GDAP- oder DAP-Beziehung erforderlich. Wenn GDAP und DAP in einem Kundenmandanten koexistieren, haben GDAP-Berechtigungen Vorrang für MSP-Techniker in GDAP-fähigen Sicherheitsgruppen. Weitere Informationen zu den Anforderungen für Microsoft 365 Lighthouse finden Sie unter Anforderungen für Microsoft 365 Lighthouse.

Die richtige Reihenfolge für dieses Szenario ist:

1. Erstellen Sie eine GDAP-Beziehung für sowohl Microsoft 365 als auch Azure.
2. Weisen Sie Microsoft Entra-Rollen Sicherheitsgruppen für sowohl Microsoft 365 als auch Azurezu.
3. Konfigurieren Sie GDAP so, dass sie Vorrang vor DAP hat.
4. Entfernen Sie DAP.

Die folgende Sequenz könnte dazu führen, dass den Zugriff auf Azure-Abonnements verliert:

1. Entfernen Sie DAP. Sie verlieren nicht unbedingt den Zugriff auf ein Azure-Abonnement, indem Sie DAP entfernen. Derzeit können Sie jedoch nicht das Verzeichnis des Kunden durchsuchen, um alle Azure RBAC-Rollenzuweisungen (z. B. das Zuweisen eines neuen Kundenbenutzers als Abonnement-RBAC-Mitwirkender) zu erledigen.
2. Erstellen Sie eine GDAP-Beziehung für microsoft 365 und Azure zusammen. Sie verlieren möglicherweise den Zugriff auf das Azure-Abonnement in diesem Schritt, sobald GDAP eingerichtet ist.
3. Zuweisen von Microsoft Entra-Rollen zu Sicherheitsgruppen für sowohl microsoft 365 als auch Azure

Nach Abschluss des Azure GDAP-Setups erhalten Sie wieder Zugriff auf Azure-Abonnements.

Wenn Sie Über Azure-Abonnements ohne DAP- verfügen, die Sie als Besitzer verwalten, wenn Sie GDAP für Microsoft 365 zu diesem Kunden hinzufügen, verlieren Sie möglicherweise den Zugriff auf die Azure-Abonnements. Um verlorenen Zugriff zu vermeiden, verschieben Sie den Kunden gleichzeitig auf Azure GDAP-, die Sie den Kunden nach Microsoft 365 GDAP verschieben.

Nein. Beziehungen, sobald sie akzeptiert wurden, sind nicht wiederverwendbar.

Wenn Sie über eine bestehende Vertriebspartnerschaft mit dem Kunden verfügen, müssen Sie dennoch eine GDAP-Beziehung einrichten, um ihre Azure-Abonnements zu verwalten.

1. Erstellen Sie eine Sicherheitsgruppe (z. B. Azure-Manager) in Microsoft Entra.
2. Erstellen Sie eine GDAP-Beziehung mit der Verzeichnisleserrolle Rolle.
3. Legen Sie die Sicherheitsgruppe als Mitglied der Admin Agent Gruppe fest. Nachdem Sie diese Schritte ausgeführt haben, können Sie das Azure-Abonnement Ihres Kunden über AOBO verwalten. Sie können das Abonnement nicht über CLI/PowerShell verwalten.

Ja. Sie können einen Azure-Plan auch dann erstellen, wenn es keine DAP- oder GDAP-Richtlinie mit einer bestehenden Händlerbeziehung gibt. Um dieses Abonnement zu verwalten, benötigen Sie jedoch DAP oder GDAP.

Wenn Partner von DAP zu GDAP wechseln, müssen sie sicherstellen, dass Folgendes vorhanden ist, um Unternehmensdetails anzuzeigen:

• Eine aktive GDAP-Beziehung.
• Jeder der folgenden Microsoft Entra-Rollen wird zugewiesen: Globaler Administrator, Verzeichnisleser, globaler Reader. Weitere Informationen finden Sie unter präzise Berechtigungen für Sicherheitsgruppengewähren.

Wenn sich ein CSP mit seinen CSP-Anmeldeinformationen und einer GDAP-Beziehung im Azure-Portal (portal.azure.come) seines Kunden anmeldet, stellt der CSP fest, dass sein Benutzername "user_" gefolgt von einer bestimmten Zahl ist. Der tatsächliche Benutzername wird nicht wie in DAP angezeigt. Es ist designiert.

Partner müssen explizit präzise Berechtigungen für Sicherheitsgruppen im Standard-GDAP erteilen.
Ab dem 10. Oktober 2023 steht DAP nicht mehr mit Vertriebspartnerbeziehungen zur Verfügung. Der aktualisierte Link "Reseller Relationship request" ist in der Partner Center-Benutzeroberfläche verfügbar, und die API-Vertrags-URL "/v1/customers/relationship requests" gibt die Einladungs-URL zurück, die an den Administrator des Kundenmandanten gesendet werden soll.

Ja, Partner müssen explizit präzise Berechtigungen für Sicherheitsgruppen im Standardmäßigen GDAP erteilen, um Kunden zu verwalten.

Partner mit Händlerbeziehung nur ohne DAP oder GDAP können Kunden erstellen, Bestellungen aufgeben und verwalten, Softwareschlüssel herunterladen, Azure RI verwalten. Sie können keine Kundenunternehmensdetails anzeigen, Keine Benutzer anzeigen oder Benutzern Lizenzen zuweisen, keine Tickets im Namen von Kunden protokollieren und keine produktspezifischen Admin Center (z. B. Teams Admin Center) zugreifen und verwalten.)

Damit ein Partner oder CPV auf einen Kundenmandanten zugreifen und diese verwalten kann, muss der Dienstprinzipal seiner App im Kundenmandanten zugestimmt werden. Wenn DAP aktiv ist, müssen sie dem Administrator-Agents SG im Partnermandanten den Dienstprinzipal der App hinzufügen. Mit GDAP muss der Partner sicherstellen, dass seine App im Kundenmandanten zugestimmt wird. Wenn die App delegierte Berechtigungen (App + Benutzer) verwendet und eine aktive GDAP mit einer der drei Rollen (CloudAnwendungsadministrator, Anwendungsadministrator, globaler Administrator) vorhanden ist, Zustimmungs-API verwendet werden kann. Wenn die App nur Anwendungsberechtigungen verwendet, muss sie entweder vom Partner oder Kunden mit einer der drei Rollen (Cloudanwendungsadministrator, Anwendungsadministrator, globaler Administrator) mithilfe mandantenweiten Administratorzustimmungs-URLmanuell zugestimmt werden.

Wenn der folgende Fehler angezeigt wird:

"Zurzeit können wir Ihre Anforderung "Neue GDAP-Beziehung erstellen" nicht überprüfen. Es wird empfohlen, dass anonyme Verbindungen für diesen Dienst nicht zulässig sind. Wenn Sie glauben, dass Sie diese Meldung fehlerhaft erhalten haben, versuchen Sie es erneut. Wählen Sie diese Option aus, um mehr über Aktionen zu erfahren, die Sie ausführen können. Wenn das Problem weiterhin besteht, wenden Sie sich an den Support und den Referenznachrichtencode 715-123220 und die Transaktions-ID: GUID."

Ändern Sie, wie Sie eine Verbindung mit Microsoft herstellen, damit der Identitätsüberprüfungsdienst ordnungsgemäß ausgeführt werden kann. Dadurch wird sichergestellt, dass Ihr Konto nicht kompromittiert wird und den Vorschriften entspricht, die Microsoft einhalten muss.

Dinge, die Sie tun können:

• Löschen Sie den Browsercache.
• Deaktivieren Sie die Nachverfolgungsprävention in Ihrem Browser, oder fügen Sie unsere Website zu Ihrer Ausnahme-/Sicheren Liste hinzu.
• Deaktivieren Sie ein beliebiges VPN-Programm (Virtual Private Network), das Sie möglicherweise verwenden.
• Stellen Sie eine direkte Verbindung mit Ihrem lokalen Gerät her, anstatt über einen virtuellen Computer (VM).

Wenn Sie nach dem Ausprobieren der vorherigen Schritte immer noch keine Verbindung herstellen können, empfehlen wir Ihnen, sich mit Ihrem IT-Helpdesk zu beraten, um festzustellen, ob sie helfen können, zu ermitteln, was das Problem verursacht. Manchmal befindet sich das Problem in den Netzwerkeinstellungen Ihres Unternehmens. Ihr IT-Administrator müsste beispielsweise das Problem beheben, indem wir unsere Website sicher auflisten oder andere Netzwerkeinstellungsanpassungen vornehmen.

• Restricted (Direct Bill): Neue GDAP (Administratorbeziehungen) kann nicht erstellt werden. Vorhandene GDAPs und ihre Rollenzuweisungen können aktualisiert werden.
• Suspended (Direct Bill/Indirect Provider/Indirect Reseller): Neue GDAP KANN nicht erstellt werden. Vorhandene GDAPs und ihre Rollenzuweisungen können nicht aktualisiert werden.
• Restricted (Direct Bill) + Active (Indirekter Wiederverkäufer): Für eingeschränkte direkte Rechnung: Neue GDAP (Administratorbeziehungen) KANN nicht erstellt werden. Vorhandene GDAPs und ihre Rollenzuweisungen können aktualisiert werden. Für aktive indirekte Wiederverkäufer: Neue GDAP KANN erstellt werden, vorhandene GDAPs und ihre Rollenzuweisungen KÖNNEN aktualisiert werden. Wenn ein offboardiertes neues GDAP nicht erstellt werden kann, können vorhandene GDAP und ihre Rollenzuweisungen nicht aktualisiert werden.

Ja. Die aktuelle Version von GDAP unterstützt alle Produkte: Microsoft 365, Dynamics 365, Microsoft Power Platformund Microsoft Azure.