Häufig gestellte Fragen zur GDAP

Geeignete Rollen: Alle Benutzer, die an Partner Center interessiert sind

Präzise delegierte Administratorberechtigungen (GDAP) ermöglichen Partnern Zugriff auf die Arbeitslasten ihrer Kunden auf eine granularere und zeitlich begrenztere Weise, was dazu beitragen kann, Sicherheitsbedenken der Kunden anzugehen.

Mit GDAP können Partner mehr Dienstleistungen für Kunden anbieten, die möglicherweise ein Problem mit den hohen Partnerzugriffs-Ebenen haben.

GDAP unterstützt auch Kunden, die regulatorische Anforderungen haben, den Partnern nur den Zugriff mit minimalen Rechten zu gewähren.

Einrichten von GDAP

Wer kann eine GDAP-Beziehung anfordern?

Jemand mit der Administrator-Agentenrolle in einer Partnerorganisation kann eine GDAP-Beziehungsanforderung erstellen.

Läuft eine GDAP-Beziehungsanforderung ab, wenn der Kunde keine Maßnahmen ergreift?

Ja. GDAP-Beziehungsanforderungen laufen nach 90 Tagen ab.

Kann ich eine GDAP-Beziehung zu einem Kunden dauerhaft machen?

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.

Kann eine GDAP-Beziehung mit einem Kunden automatisch verlängert/erweitert werden?

Ja. Eine GDAP-Beziehung kann um sechs Monate automatisch verlängert werden, bis sie beendet wird oder die automatische Verlängerung auf 'Deaktiviert' gesetzt ist.

Was kann ich tun, wenn die GDAP-Beziehung mit einem Kunden abläuft?

• 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.

Wie kann ein Kunde eine GDAP-Beziehung erweitern oder verlängern?

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.

Kann ein aktives GDAP, das bald abläuft, aktualisiert werden, um automatisch verlängert zu werden?

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

Wann wird die automatische Verlängerung wirksam?

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.

Kann ein GDAP mit einem Partner Led Tool (PLT) erstellt werden, Microsoft Led Tool, Partner Center UI oder Partner Center API automatisch erweitert werden?

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

Ist die Zustimmung des Kunden erforderlich, um die automatische Erweiterung auf vorhandene aktive GDAPs festzulegen?

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

Sollen granulare Berechtigungen nach der automatischen Erweiterung den Sicherheitsgruppen erneut zugewiesen werden?

Nein. Granulare Berechtigungen, die Sicherheitsgruppen zugewiesen sind, bleiben wie gehabt.

Kann eine Administratorbeziehung mit der Rolle "Globaler Administrator" automatisch erweitert werden?

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

Warum wird die Seite **Ablaufende granulare Beziehungen** im Arbeitsbereich "Kunden" nicht angezeigt?

Die Seite Ablauf granularer Beziehungen ist nur für Partnerbenutzer mit Admin-Agenten-Rollen verfügbar. Diese Seite unterstützt beim Filtern von GDAPs, die in unterschiedlichen Zeiträumen ablaufen, und ermöglicht das Aktualisieren der automatischen Verlängerung (Aktivieren/Deaktivieren) für einen oder mehrere GDAPs.

Wenn eine GDAP-Beziehung abläuft, sind die bestehenden Abonnements des Kunden betroffen?

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

Wie kann ein Kunde sein Kennwort und MFA-Gerät zurücksetzen, wenn er aus dem Konto gesperrt ist und keine GDAP-Beziehungsanfrage von einem Partner annehmen kann?

Weitere Informationen finden Sie unter Problembehandlung bei Microsoft Entra-Problemen mit der mehrstufigen Authentifizierung und Microsoft Entra mehrstufige Authentifizierung kann nicht verwendet werden, um sich bei Clouddiensten anzumelden, wenn Sie Ihr Telefon verloren haben oder sich Ihre Telefonnummer geändert hat.

Welche Rollen benötigt ein Partner, um ein Administratorkennwort und ein MFA-Gerät zurückzusetzen, wenn ein Kundenadministrator aus ihrem Konto gesperrt ist und eine GDAP-Beziehungsanfrage von einem Partner nicht akzeptieren kann?

Ein Partner muss die Rolle Privileged authentication administrator Microsoft Entra anfordern, wenn er den ersten GDAP erstellt.

• Mit dieser Rolle kann ein Partner ein Kennwort und die Authentifizierungsmethode für einen Administrator oder nichtadmin-Benutzer zurücksetzen. Die Rolle des Administrators für privilegierte Authentifizierung ist Teil der Rollen, die von Microsoft led Tool eingerichtet wurden, und ist geplant, während des Erstellungs-Kundenablaufs (geplant für September) mit dem Standard-GDAP verfügbar zu sein.
• Der Partner könnte den Kundenadministrator bitten, das Kennwort zurü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.

Wer erhält eine E-Mail-Benachrichtigung zur Beendigung einer GDAP-Beziehung?

• 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.

Kann ich sehen, wann ein Kunde GDAP in den Aktivitätsprotokollen entfernt?

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

Muss ich eine GDAP-Beziehung mit allen meinen Kunden erstellen?

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.

Wenn ich mehrere Kunden habe, muss ich über mehrere Sicherheitsgruppen für diese Kunden verfügen?

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 bevorzugen, dass mehrere Partnerbenutzer verschiedene Kunden verwalten, weisen Sie diese Partnerbenutzer separaten Sicherheitsgruppen zur Trennung der Kunden zu.

Können indirekte Händler GDAP-Beziehungsanfragen im Partner Center erstellen?

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

Warum kann ein Partnerbenutzer mit GDAP-Zugriff nicht als AOBO (Administrator im Auftrag von) auf eine Workload zugreifen?

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.

Was ist der empfohlene nächste Schritt, wenn die vom Kunden festgelegte Richtlinie für bedingten Zugriff den gesamten externen Zugriff blockiert, einschließlich des Zugriffs des CSP als Administrator im Auftrag des Kunden auf den Tenant des Kunden?

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 enthält meistens alle Benutzer, die eine Organisation mit einer Richtlinie für bedingten Zugriff anvisiert.
• 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:
• Benutzer von Dienstanbietern, z. B. eines Cloud Solution Providers (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 externen Benutzertyp Dienstanbieter-Benutzer, der in den 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:
• Dienstanbieter-Benutzer, z. B. ein 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

Benötige ich eine GDAP-Beziehung, um Support-Tickets zu erstellen, obwohl ich Premier Support für Partner habe?

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

Kann GDAP im Status **Genehmigung ausstehend** vom Partner beendet werden?

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

Nachdem eine GDAP-Beziehung beendet wurde, kann ich denselben GDAP-Beziehungsnamen wiederverwenden, um eine neue Beziehung zu erstellen?

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.

Kann ein Partner in einer Region seine Kunden in verschiedenen Regionen verwalten?

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.

Kann ein Dienstanbieter Teil einer mehrinstanzenübergreifenden Organisation sein, was ist Error-Action 103?

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

Was kann ich tun, wenn der Fehler "Kontoinformationen können nicht abgerufen werden" angezeigt wird, wenn ich von der Partner Center Service Management-Seite zu Microsoft Security Copilot navigiere?

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 unter Security Copilot FAQ.

Können ein CSP und ein Kunde mit einer GDAP-Beziehung eine mehrinstanzenfähige Organisation bilden?

Multitenant Organization-Funktionen werden zwischen einem CSP und einem Kunden, die über eine GDAP-Beziehung verfügen, nicht unterstützt. GDAP-Funktionen ermöglichen es einem CSP-Partnerbenutzer, Microsoft-Dienste für eine andere Organisation zu verwalten. Die Funktionen einer Multi-Tenant-Organisation sind für die Nutzung zwischen Mandanten vorgesehen, die von derselben Organisation verwaltet werden.

GDAP-API

Sind APIs zum Erstellen einer GDAP-Beziehung mit Kunden verfügbar?

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

Kann ich die Beta-GDAP-APIs für die Produktion verwenden?

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.

Kann ich mehrere GDAP-Beziehungen mit verschiedenen Kunden gleichzeitig erstellen?

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.

Können mehrere Sicherheitsgruppen in einer GDAP-Beziehung mit einem API-Aufruf zugewiesen werden?

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

Wie kann ich mehrere Ressourcenberechtigungen für meine Anwendung anfordern?

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.microsoft.com/Directory.AccessAsUser.All und https://graph.microsoft.com/Organization.Read.Allanzufordern, führen Sie jeweils zwei verschiedene Anforderungen aus.

Wie finde ich die Ressourcen-ID für eine bestimmte Ressource?

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

Was sollte ich tun, wenn der Fehler "Request_UnsupportedQuery" mit der Meldung "Nicht unterstützte oder ungültige Abfragefilterklausel angegeben für die Eigenschaft 'appId' der Ressource 'ServicePrincipal'" angezeigt wird?

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.
• Korrekte Anforderung Verwenden Sie stattdessen für enterpriseApplicationId die Ressourcen-ID, z. B. 00000003-0000-0000-c000-000000000000.

Wie kann ich der Ressource einer Anwendung, die bereits vom Kundenmandanten freigegeben wurde, neue Scopes hinzufügen?

Beispielsweise wurde zuvor nur für den Bereich "Profil" in der Ressource graph.microsoft.com eingewilligt. 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.

Anmerkung

Wenn Ihre Anwendung Berechtigungen für mehrere Ressourcen benötigt, führen Sie die POST-Methode für jede Ressource separat aus.

Wie gebe ich mehrere Bereiche für eine einzelne Ressource (enterpriseApplicationId) an?

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

Was sollte ich tun, wenn ich einen Fehler "400 Ungültige Anforderung" mit der Meldung "Nicht unterstütztes Token" erhalte. Der Autorisierungskontext kann nicht initialisiert werden"?

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, für das Sie dem Kundenmandanten Erlaubnis erteilen 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 (DAP) und der Benutzer ist auch Mitglied der Sicherheitsgruppe "Admin Agents" im Partnermandant.
• 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:
  • Anwendungsadministrator oder Cloudanwendungsadministratorrolle.
  • Der Partnerbenutzer ist Mitglied der Sicherheitsgruppe, die in der Zugriffszuweisung angegeben ist.

Rollen

Welche GDAP-Rollen sind erforderlich, um auf ein Azure-Abonnement zuzugreifen?

• Um Azure mit kundenindividueller Zugriffspartitionierung zu verwalten (dies ist die empfohlene Best Practice), erstellen Sie eine Sicherheitsgruppe (z. B. Azure Manager) und fügen Sie diese unter Admin-Agenten hinzu.
• Um auf ein Azure-Abonnement als Besitzer für einen Kunden zuzugreifen, Sie können jeder Microsoft Entra integrierten Rolle (z. B. Directory readers, die am wenigsten privilegierte Rolle) der Sicherheitsgruppe Azure Manager zuweisen. Die Schritte zum Einrichten Azure GDAP finden Sie unter Workloads, die von granularen delegierten Administratorrechten (GDAP) unterstützt werden.

Gibt es Anleitungen zu den Am wenigsten privilegierten Rollen, die ich Benutzern für bestimmte Aufgaben zuweisen kann?

Ja. Informationen zum Einschränken der Administratorberechtigungen eines Benutzers durch Zuweisen der am wenigsten privilegierten Rollen in Microsoft Entra finden Sie unter Least privileged roles by task in Microsoft Entra.

Was ist die am wenigsten privilegierte Rolle, die ich einem Mandanten eines Kunden zuweisen kann und trotzdem Supporttickets für den Kunden erstellen kann?

Es wird empfohlen, die Rolle des Dienstsupportadministrators zuzuweisen. Weitere Informationen finden Sie unter Mindestprivilegierte Rollen nach Aufgabe in Microsoft Entra.

Welche Microsoft Entra Rollen wurden in der Partner Center-Benutzeroberfläche im Juli 2024 zur Verfügung gestellt?

• Um die Lücke zwischen Microsoft Entra Rollen zu verringern, die in der Partner Center-API im Vergleich zur Benutzeroberfläche verfügbar sind, stehen im Juli 2024 eine Liste mit neun Rollen in der Partner Center-Benutzeroberfläche zur Verfügung.
• In Zusammenarbeit:
  • Microsoft Edge Administrator
  • Administrator virtueller Besuche
  • Viva Goals Administrator
  • Viva Pulse Administrator
  • Yammer-Administrator
• Unter Identität:
  • Berechtigungsverwaltungsadministrator
  • Lebenszyklusworkflows-Administrator
• Unter Sonstiges:
  • Administrator für Organisationsmarken
  • Genehmiger von Organisationsnachrichten

Welche Microsoft Entra Rollen wurden im Dezember 2024 in der Partner Center-Benutzeroberfläche zur Verfügung gestellt?

• Um die Lücke zwischen Microsoft Entra Rollen zu verringern, die in der Partner Center-API im Vergleich zur Benutzeroberfläche verfügbar sind, wurden im Dezember 2024 eine Liste von 17 Rollen in der Partner Center-Benutzeroberfläche verfügbar gemacht.
• In Zusammenarbeit:
  • Insights Analyst
  • Microsoft 365-Migrationsadministrator
  • Verfasser für organisatorische Mitteilungen
  • SharePoint-Eingebetteter Administrator
  • Teamtelefonieadministrator
  • Erfolgs-Manager für die Benutzererfahrung
• Unter Geräten:
  • Microsoft Hardwaregarantieadministrator
  • Microsoft Hardwaregarantie-Spezialist
• Unter Identität:
  • Attributzuweisungsadministrator
  • Attributzuweisungsleser
  • Attributdefinitionsadministrator
  • Attributdefinitionsleser
  • Attributprotokolladministrator
  • Attributprotokollleser
  • Authentifizierungserweiterungsadministrator
  • Globaler Administrator für den sicheren Zugriff
  • Mandanten-Ersteller

Kann ich Supporttickets für einen Kunden in einer GDAP-Beziehung öffnen, von der alle Microsoft Entra Rollen ausgeschlossen sind?

Nein. Die am wenigsten privilegierte Rolle für Partnerbenutzer, damit sie Support-Tickets für ihre Kunden erstellen können, 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.

Wo finde ich Informationen zu allen Rollen und Workloads, die in GDAP enthalten sind?

Informationen über alle Rollen finden Sie unter Microsoft Entra integrierte Rollen. Informationen zu Workloads finden Sie unter Workloads, die von granularen delegierten Administratorrechten (GDAP)unterstützt werden.

Welche GDAP-Rolle bietet Zugriff auf das Microsoft 365 Admin Center?

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

Kann ich benutzerdefinierte Sicherheitsgruppen für GDAP erstellen?

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

Welche GDAP-Rollen gewähren schreibgeschützten Zugriff auf die Abonnements des Kunden und erlauben dem Benutzer daher nicht, sie zu verwalten?

Der schreibgeschützte Zugriff auf die Abonnements des Kunden wird durch die Rollen des Globalen Readers, Verzeichnislesers und der Unterstützung durch Partnerrolle 2 bereitgestellt.

Welche Rolle sollte ich meinen Partner-Agents (derzeit Administrator-Agents) zuweisen, wenn sie den Mandanten verwalten, jedoch die Abonnements der Kunden nicht ändern dürfen?

Es wird empfohlen, die Partner-Agents aus der Admin-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.).

Was geschieht, wenn ein Kunde den Partnern GDAP-Rollen gewährt und dann Rollen entfernt oder die GDAP-Beziehung abtrennt?

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

Kann ein Partner weiterhin Transaktionen für einen Kunden durchführen, nachdem alle GDAP-Beziehungen mit dem Kunden entfernt wurden?

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.

Können einige Rollen in meiner GDAP-Beziehung mit meinem Kunden länger ablaufen als andere?

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

Benötige ich GDAP, um Aufträge für neue und bestehende Kunden im Partner Center zu erfüllen?

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.

Muss ich allen Kunden eine Partner-Agent-Rolle zuweisen oder kann ich nur einem Kunden eine Partner-Agent-Rolle zuweisen?

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 durchführen möchten, können Sie dies mithilfe von APIs automatisieren.

Kann ein Partnerbenutzer über GDAP-Rollen und ein Gastkonto verfügen?

Nein. Gastkonten funktionieren nicht mit GDAP. Kunden müssen alle Gastkonten entfernen, damit GDAP funktioniert.

Warum können GDAP-Administratoren + B2B-Benutzer keine Authentifizierungsmethoden in aka.ms/mysecurityinfo hinzufügen?

GDAP-Gastadministratoren können ihre eigenen Sicherheitsinformationen bei My Security-Infonicht verwalten. Stattdessen benötigen Sie die Unterstützung des Mandantenadministrators, bei dem sie Gast sind, 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 registriert werden können, was kurznachrichtendienst (SMS) oder Voice ist. Weitere Informationen finden Sie unter mandantenübergreifende Zugriffsrichtlinien.

Welche Rollen kann ein Partner verwenden, um die automatische Erweiterung zu aktivieren?

Richten Sie sich am Guiding-Prinzip von Zero Trust: Verwenden sie den geringsten Berechtigungszugriff:

• Es wird empfohlen, eine Rolle mit minimalen Rechten je nach Aufgaben zu verwenden, und Workloads, die von granularen delegierten Administratorrechten (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 empfehlen nicht, die Rolle "Globaler Administrator" durch alle möglichen Microsoft Entra Rollen zu ersetzen.

DAP und GDAP

Ersetzt GDAP DAP?

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

Kann ich DAP weiterhin verwenden oder muss ich alle meine Kunden auf GDAP umstellen?

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.

Während DAP und GDAP koexistieren, gibt es Änderungen an der Art und Weise, wie eine DAP-Beziehung erstellt wird?

Es gibt keine Änderungen am bestehenden Ablauf der DAP-Beziehung, während DAP und GDAP koexistieren.

Welche Microsoft Entra Rollen würden für die Standard-GDAP im Rahmen von "Kunden erstellen" gewährt?

DAP wird derzeit gewährt, wenn ein neuer Kundentenant erstellt wird. Am 25. September 2023 gewährt Microsoft nicht mehr DAP 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:

Microsoft Entra-Rollen, die für Standard-GDAP erteilt wurden	Direktabrechnungspartner	Indirekte Anbieter	Indirekte Wiederverkäufer	Domänenpartner	Systemsteuerung Anbieter (CPVs)	Berater	Standard-GDAP deaktiviert (Kein DAP)
1. Verzeichnisleser. Kann grundlegende Verzeichnisinformationen lesen. Wird häufig verwendet, um Verzeichnislesezugriff auf Anwendungen und Gäste zu gewähren.	x	x	x	x	x
2. Verzeichnisautoren. Kann grundlegende Verzeichnisinformationen lesen und schreiben. Für die Gewährung des Zugriffs auf Anwendungen, nicht für Benutzer vorgesehen.	x	x	x	x	x
3. Lizenzadministrator. Kann Produktlizenzen für Benutzer und Gruppen verwalten.	x	x	x	x	x
4. Administrator des Service-Supports. Kann Dienststatusinformationen lesen und Supporttickets verwalten.	x	x	x	x	x
5. Benutzeradministrator. Kann alle Aspekte von Benutzern und Gruppen verwalten, einschließlich zurücksetzen von Kennwörtern für eingeschränkte Administratoren.	x	x	x	x	x
6. Administrator für privilegierte Rollen. Kann Rollenzuweisungen in Microsoft Entra und alle Aspekte von Privileged Identity Management verwalten.	x	x	x	x	x
7. Helpdesk-Administrator. Kann Kennwörter für Nichtadministratoren und Helpdesk-Administratoren zurücksetzen.	x	x	x	x	x
8. Administrator für privilegierte Authentifizierung. Kann auf die Informationen zur Anzeige, Festlegung und Zurücksetzung der Authentifizierungsmethoden für jeden Benutzer (Administrator oder Nicht-Administrator) zugreifen.	x	x	x	x	x
9. Cloudanwendungsadministrator. Kann alle Aspekte von App-Registrierungen und Unternehmens-Apps mit Ausnahme von App-Proxy erstellen und verwalten.	x	x		x	x
10. Anwendungsadministrator. Kann alle Aspekte von App-Registrierungen und Unternehmens-Apps erstellen und verwalten.	x	x		x	x
11. global reader. Kann alles lesen, was ein global administrierende Person kann, aber nichts aktualisieren kann.	x	x	x	x	x
12. Administrator des externen Identitätsanbieters. Kann den Partnerverbund zwischen Microsoft Entra Organisationen und externen Identitätsanbietern verwalten.				x
13. Domänennamenadministrator. Kann Domänennamen in der Cloud und lokal verwalten.				x

Wie funktioniert GDAP mit Privileged Identity Management in Microsoft Entra?

Partner können Privileged Identity Management (PIM) in einer GDAP-Sicherheitsgruppe im Mandanten des Partners implementieren, um den Zugriff auf einige Benutzer mit hohen Rechten zu erhöhen, nur rechtzeitig (JIT), um ihnen hohe Rechte 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/Mandanten 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.

Wie koexistieren DAP und GDAP, wenn ein Kunde Microsoft Azure und Microsoft 365 oder Dynamics 365 kauft?

GDAP ist allgemein verfügbar mit Unterstützung für alle kommerziellen Cloud-Dienste von Microsoft (Microsoft 365, Dynamics 365, Microsoft Azure und 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.

Ich habe eine große Kundenbasis (z. B. 10.000 Kundenkonten). Wie kann ich von DAP zu GDAP wechseln?

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

Sind die PEC-Punkte meines Partners betroffen, wenn ich von DAP zu GDAP wechsele? Gibt es Auswirkungen auf partner Admin Link (PAL)?

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.

Ist die PEC betroffen, wenn DAP/GDAP entfernt wird?

• 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 zur GDAP für Microsoft 365 und gleichzeitig Azure wechselt und DAP entfernt wird, geht PEC nicht verloren.
• Wenn der Kunde des Partners ÜBER DAP verfügt und er für Microsoft 365 zu GDAP wechselt, aber Azure as-is beibehalten (sie wechseln nicht zu GDAP) 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.

Wie haben GDAP-Berechtigungen Vorrang vor DAP-Berechtigungen, während DAP und GDAP koexistieren?

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:

Kunde	Beziehung mit Partner
Kunde 1	DAP (ohne GDAP)
Kunde 2	DAP + GDAP beide
Kunde 3	GDAP (kein DAP)

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

Beispielbenutzer	Beispiel für kundenmandanten	Benehmen	Kommentare
Benutzer 1	Kunde 1	DAP	Dieses Beispiel ist DAP as-is.
Benutzer 1	Kunde 2	DAP	Es gibt keine GDAP-Rollenzuweisung für die Admin-Agents Gruppe, was zu DAP-Verhalten führt.
Benutzer 1	Kunde 3	Kein Zugriff	Es gibt keine DAP-Beziehung, sodass die Administrator-Agents Gruppe keinen Zugriff auf Kunden drei haben.
Benutzer 2	Kunde 1	DAP	Dieses Beispiel ist DAP as-is.
Benutzer 2	Kunde zwei	GDAP	GDAP hat Vorrang vor DAP, da benutzer zwei über die GDAP-Sicherheitsgruppe eine GDAP-Rolle zugewiesen wird, auch wenn der Benutzer Teil des Admin-Agents Gruppe ist.
Benutzer 2	Kunde 3	GDAP	Dieses Beispiel ist ein GDAP-Only-Kunde.
Benutzer 3	Kunde 1	Kein Zugriff	Es gibt keine GDAP-Rollenzuweisung für Kunde eins.
Benutzer 3	Kunde zwei	GDAP	Benutzer drei ist nicht Teil der Admin-Agenten-Gruppe, was zu einem nur-GDAP-Verhalten führt.
Benutzer 3	Kunde 3	GDAP	Nur GDAP-Verhalten

Wirkt sich die Deaktivierung von DAP oder der Übergang zu GDAP auf meine Legacy-Kompetenzvorteile oder Lösungspartnerbezeichnungen aus, die ich erreicht habe?

DAP und GDAP sind keine geeigneten Zuordnungstypen für Solutions Partner-Bezeichnungen. Eine Deaktivierung oder Umstellung von DAP auf GDAP wirkt sich nicht auf den Erhalt Ihres Lösungspartnerstatus aus. Außerdem ist die Erneuerung von Legacy-Kompetenzvorteilen oder Solutions Partner-Vorteilen nicht betroffen. Um die anderen Partnertypen zu sehen, die für die Bezeichnung 'Solutions Partner' berechtigt sind, klicken Sie auf Partner Center Solutions Partner-Bezeichnungen.

Wie funktioniert GDAP mit Azure Lighthouse? Wirken sich GDAP und Azure Lighthouse gegenseitig aus?

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 szenario Azure Lighthouse 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 für die Gruppe "Admin Agents" befindet sich ebenfalls 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 Beziehung zu Lighthouse (Projektion) ohne Auswirkungen auf GDAP abtrennen. Weitere Informationen finden Sie in der Dokumentation Azure Lighthouse.

Wie funktioniert GDAP mit Microsoft 365 Lighthouse?

Managed Service Providers (MSPs), die im Cloud Solution Provider(CSP)-Programm als indirect Reseller oder direct bill Partner registriert sind, können jetzt Microsoft 365 Lighthouse verwenden, um GDAP für jeden Kundenmandanten einzurichten. Da es mehrere Wege gibt, auf denen Partner ihren Übergang zu GDAP bereits steuern, ermöglicht dieser Assistent es Lighthouse-Partnern, empfohlene Rollen zu übernehmen, die ihren spezifischen Geschäftsanforderungen entsprechen. 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 um eine Demo anzusehen, finden Sie den 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 Requirements für Microsoft 365 Lighthouse.

Was ist die beste Möglichkeit, um zu GDAP zu wechseln und DAP zu entfernen, ohne den Zugriff auf Azure Abonnements zu verlieren, wenn ich Kunden mit Azure habe?

Die richtige Reihenfolge für dieses Szenario ist:

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

Wichtig

Wenn Sie diese Schritte nicht ausführen, verlieren vorhandene Administrator-Agents, die Azure verwalten, möglicherweise den Zugriff auf Azure Abonnements für den Kunden.

Die folgende Sequenz könnte dazu führen, den Zugriff zu verlieren auf Azure-Abonnements.

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

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

Ich habe Kunden mit Azure Abonnements ohne DAP. Wenn ich sie für Microsoft 365 in GDAP verschiebe, verliere ich den Zugriff auf die Azure-Abonnements?

Wenn Sie über Azure Abonnements without DAP verfügen, die Sie als Besitzer verwalten, können Sie beim Hinzufügen von GDAP für Microsoft 365 zu diesem Kunden den Zugriff auf die Azure Abonnements verlieren. Um einen verlorenen Zugriff zu vermeiden, verschieben Sie den Kunden auf Azure GDAP zur gleichen Zeit dass Sie den Kunden zu Microsoft 365 GDAP verschieben.

Wichtig

Wenn Sie diese Schritte nicht ausführen, verlieren die vorhandenen Administrator-Agents, die Azure verwalten, möglicherweise den Zugriff auf Azure Abonnements für den Kunden.

Kann ein einzelner Beziehungslink mit mehreren Kunden verwendet werden?

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

Wenn ich eine Vertriebspartnerschaft mit Kunden ohne DAP habe und keine GDAP-Beziehung haben, kann ich auf ihr Azure-Abonnement zugreifen?

Wenn Sie über eine bestehende Händlerbeziehung 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 Rolle Verzeichnisleser.
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.

Kann ich einen Azure-Plan für Kunden erstellen, die weder eine DAP noch eine GDAP-Beziehung haben?

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

Warum wird der Abschnitt "Unternehmensdetails" auf der Seite "Konto" unter "Kunden" nicht mehr angezeigt, wenn DAP entfernt wird?

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: Verzeichnisleser, Globaler Reader. Weitere Informationen finden Sie unter präzise Berechtigungen für Sicherheitsgruppen gewähren.

Warum wird mein Benutzername in portal.azure.com durch "user_somenumber" ersetzt, wenn eine GDAP-Beziehung vorhanden ist?

Wenn sich ein CSP mit seinen CSP-Anmeldeinformationen im Azure-Portal des Kunden (portal.azure.com) anmeldet und eine GDAP-Beziehung besteht, bemerkt der CSP, dass sein Benutzername "user_" gefolgt von einer bestimmten Zahl ist. Der tatsächliche Benutzername wird nicht wie in DAP angezeigt. Es ist so beabsichtigt.

Was sind die Zeitpläne für das Stoppen von DAP und das Gewähren von Standard-GDAP bei der Erstellung eines neuen Kunden?

Mandantentyp	Verfügbarkeitsdatum	Verhalten der Partner Center-API (POST /v1/customers) enableGDAPByDefault: true	Verhalten der Partner Center-API (POST /v1/customers) enableGDAPByDefault: falsch	Verhalten der Partner Center-API (POST /v1/customers) Keine Änderung an Anforderung oder Nutzlast	Verhalten der Partner Center-Benutzeroberfläche
Sandbox	25. September 2023 (nur API)	DAP = Nein. Standard GDAP = Ja	DAP = Nein. Standard GDAP = Nein	DAP = Ja. Standard GDAP = Nein	Standard GDAP = Ja
Produktion	10. Oktober 2023 (API + UI)	DAP = Nein. Standard GDAP = Ja	DAP = Nein. Standard GDAP = Nein	DAP = Ja. Standard GDAP = Nein	Anmeldung/Abmeldung verfügbar: Standard-GDAP
Produktion	27. November 2023 (GA-Rollout am 2. Dezember abgeschlossen)	DAP = Nein. Standard GDAP = Ja	DAP = Nein. Standard GDAP = Nein	DAP = Nein. Standard GDAP = Ja	Opt-In/Out verfügbar: Standard-GDAP

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 "Anfrage für das Händlerverhältnis" ist in der Partner Center-Benutzeroberfläche verfügbar, und die API-Vertragseigenschaft "/v1/customers/relationship requests" gibt die Einladungs-URL zurück, die an den Administrator des Kundenmandanten gesendet werden soll.

Soll ein Partner präzise Berechtigungen für Sicherheitsgruppen im Standard-GDAP erteilen?

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

Welche Aktionen kann ein Partner mit der Reseller-Beziehung, aber ohne DAP und GDAP im Partner Center ausführen?

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 nicht auf produktspezifische Admin Center (z. B. Teams Admin Center) zugreifen und diese verwalten.

Welche Aktion muss ein Partner durchführen, der von DAP zu GDAP über die Zustimmung wechselt?

Damit ein Partner oder CPV auf einen Kundenmandanten zugreifen und diesen verwalten kann, muss dem Dienstprinzipal der App im Kunden-Mandanten zugestimmt werden. Wenn DAP aktiv ist, müssen sie den Service Principal der App zum Admin Agents SG im Partnermandanten hinzufügen. Mit GDAP muss der Partner sicherstellen, dass im Kundenmandanten seiner Anwendung die Genehmigung erteilt wurde. Wenn die App delegierte Berechtigungen (App + Benutzer) verwendet und ein aktives GDAP mit einer der drei Rollen (CloudAnwendungsadministrator, Anwendungsadministrator) 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) mithilfe mandantenweiten Administratorzustimmungs-URLmanuell zugestimmt werden.

Welche Aktion muss ein Partner für einen 715-123220-Fehler ausführen, oder anonyme Verbindungen sind für diesen Dienst nicht zulässig?

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 müssen.

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-Support zu beraten, um Ihre Einstellungen zu überprüfen und die Ursache des Problems zu identifizieren. Manchmal befindet sich das Problem in den Netzwerkeinstellungen Ihres Unternehmens. Ihr IT-Administrator müsste das Problem beheben, indem er beispielsweise unsere Website auf die Whitelist setzt oder andere Netzwerkeinstellungen anpasst.

Welche GDAP-Aktionen sind für einen Partner zulässig, der sich im Offboarding-Prozess befindet, eingeschränkt, gesperrt oder bereits offboarded ist?

• Restricted (Direct Bill): Neue GDAP (Administratorbeziehungen) können nicht erstellt werden. Vorhandene GDAPs und ihre Rollenzuweisungen können aktualisiert werden.
• Suspended (Direct Bill/Indirect Provider/Indirect Reseller): Eine 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 Rechnungen: Neue GDAP (Administratorbeziehungen) können 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 neues GDAP im Offboarding-Prozess nicht erstellt werden kann, können vorhandene GDAP und deren Rollenzuweisungen nicht aktualisiert werden.

Angebote

Ist die Verwaltung von Azure Abonnements in dieser Version von GDAP enthalten?

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

Geeignete Rollen: Alle Benutzer, die an Partner Center interessiert sind

Präzise delegierte Administratorberechtigungen (GDAP) ermöglichen Partnern Zugriff auf die Arbeitslasten ihrer Kunden auf eine granularere und zeitlich begrenztere Weise, was dazu beitragen kann, Sicherheitsbedenken der Kunden anzugehen.

Mit GDAP können Partner mehr Dienstleistungen für Kunden anbieten, die möglicherweise ein Problem mit den hohen Partnerzugriffs-Ebenen haben.

GDAP unterstützt auch Kunden, die regulatorische Anforderungen haben, den Partnern nur den Zugriff mit minimalen Rechten zu gewähren.

Jemand mit der Administrator-Agentenrolle in einer Partnerorganisation kann eine GDAP-Beziehungsanforderung erstellen.

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.

Ja. Eine GDAP-Beziehung kann um sechs Monate automatisch verlängert werden, bis sie beendet wird oder die automatische Verlängerung auf 'Deaktiviert' gesetzt ist.

• 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, bleiben wie gehabt.

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

Die Seite Ablauf granularer Beziehungen ist nur für Partnerbenutzer mit Admin-Agenten-Rollen verfügbar. Diese Seite unterstützt beim Filtern von GDAPs, die in unterschiedlichen Zeiträumen ablaufen, und ermöglicht das Aktualisieren der automatischen Verlängerung (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 Problembehandlung bei Microsoft Entra-Problemen mit der mehrstufigen Authentifizierung und Microsoft Entra mehrstufige Authentifizierung kann nicht verwendet werden, um sich bei Clouddiensten anzumelden, wenn Sie Ihr Telefon verloren haben oder sich Ihre Telefonnummer geändert hat.

Ein Partner muss die Rolle Privileged authentication administrator Microsoft Entra anfordern, wenn er den ersten GDAP erstellt.

• Mit dieser Rolle kann ein Partner ein Kennwort und die Authentifizierungsmethode für einen Administrator oder nichtadmin-Benutzer zurücksetzen. Die Rolle des Administrators für privilegierte Authentifizierung ist Teil der Rollen, die von Microsoft led Tool eingerichtet wurden, und ist geplant, während des Erstellungs-Kundenablaufs (geplant für September) mit dem Standard-GDAP verfügbar zu sein.
• Der Partner könnte den Kundenadministrator bitten, das Kennwort zurü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 bevorzugen, dass mehrere Partnerbenutzer verschiedene Kunden verwalten, weisen Sie diese Partnerbenutzer separaten Sicherheitsgruppen zur Trennung der Kunden 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 enthält meistens alle Benutzer, die eine Organisation mit einer Richtlinie für bedingten Zugriff anvisiert.
• 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:
• Benutzer von Dienstanbietern, z. B. eines Cloud Solution Providers (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 externen Benutzertyp Dienstanbieter-Benutzer, der in den 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:
• Dienstanbieter-Benutzer, z. B. ein 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 von dem Supportplan, den Sie haben, ist die Rolle mit den geringsten Rechten für Partnerbenutzer, um Supporttickets für ihre Kunden zu erstellen, der Servicesupportadministrator.

Nein. Der Partner kann derzeit ein GDAP im Status Genehmigung ausstehend nicht kündigen. 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 unter Security Copilot FAQ.

Multitenant Organization-Funktionen werden zwischen einem CSP und einem Kunden, die über eine GDAP-Beziehung verfügen, nicht unterstützt. GDAP-Funktionen ermöglichen es einem CSP-Partnerbenutzer, Microsoft-Dienste für eine andere Organisation zu verwalten. Die Funktionen einer Multi-Tenant-Organisation sind für die Nutzung zwischen Mandanten vorgesehen, die von derselben Organisation verwaltet werden.

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.microsoft.com/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: Erste Microsoft-Anwendungen in Anmeldeberichten überprüfen – 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.
• Korrekte Anforderung Verwenden Sie stattdessen für enterpriseApplicationId die Ressourcen-ID, z. B. 00000003-0000-0000-c000-000000000000.

Beispielsweise wurde zuvor nur für den Bereich "Profil" in der Ressource graph.microsoft.com eingewilligt. 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.

Anmerkung

Wenn Ihre Anwendung Berechtigungen für mehrere Ressourcen benötigt, führen Sie die POST-Methode für jede Ressource separat aus.

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, für das Sie dem Kundenmandanten Erlaubnis erteilen 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 (DAP) und der Benutzer ist auch Mitglied der Sicherheitsgruppe "Admin Agents" im Partnermandant.
• 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:
  • Anwendungsadministrator oder Cloudanwendungsadministratorrolle.
  • Der Partnerbenutzer ist Mitglied der Sicherheitsgruppe, die in der Zugriffszuweisung angegeben ist.

• Um Azure mit kundenindividueller Zugriffspartitionierung zu verwalten (dies ist die empfohlene Best Practice), erstellen Sie eine Sicherheitsgruppe (z. B. Azure Manager) und fügen Sie diese unter Admin-Agenten hinzu.
• Um auf ein Azure-Abonnement als Besitzer für einen Kunden zuzugreifen, Sie können jeder Microsoft Entra integrierten Rolle (z. B. Directory readers, die am wenigsten privilegierte Rolle) der Sicherheitsgruppe Azure Manager zuweisen. Die Schritte zum Einrichten 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 der am wenigsten privilegierten Rollen in Microsoft Entra finden Sie unter Least privileged roles by task in Microsoft Entra.

Es wird empfohlen, die Rolle des Dienstsupportadministrators zuzuweisen. Weitere Informationen finden Sie unter Mindestprivilegierte Rollen nach Aufgabe in Microsoft Entra.

• Um die Lücke zwischen Microsoft Entra Rollen zu verringern, die in der Partner Center-API im Vergleich zur Benutzeroberfläche verfügbar sind, stehen im Juli 2024 eine Liste mit neun Rollen in der Partner Center-Benutzeroberfläche zur Verfügung.
• In Zusammenarbeit:
  • Microsoft Edge Administrator
  • Administrator virtueller Besuche
  • Viva Goals Administrator
  • Viva Pulse Administrator
  • Yammer-Administrator
• Unter Identität:
  • Berechtigungsverwaltungsadministrator
  • Lebenszyklusworkflows-Administrator
• Unter Sonstiges:
  • Administrator für Organisationsmarken
  • Genehmiger von Organisationsnachrichten

• Um die Lücke zwischen Microsoft Entra Rollen zu verringern, die in der Partner Center-API im Vergleich zur Benutzeroberfläche verfügbar sind, wurden im Dezember 2024 eine Liste von 17 Rollen in der Partner Center-Benutzeroberfläche verfügbar gemacht.
• In Zusammenarbeit:
  • Insights Analyst
  • Microsoft 365-Migrationsadministrator
  • Verfasser für organisatorische Mitteilungen
  • SharePoint-Eingebetteter Administrator
  • Teamtelefonieadministrator
  • Erfolgs-Manager für die Benutzererfahrung
• Unter Geräten:
  • Microsoft Hardwaregarantieadministrator
  • Microsoft Hardwaregarantie-Spezialist
• Unter Identität:
  • Attributzuweisungsadministrator
  • Attributzuweisungsleser
  • Attributdefinitionsadministrator
  • Attributdefinitionsleser
  • Attributprotokolladministrator
  • Attributprotokollleser
  • Authentifizierungserweiterungsadministrator
  • Globaler Administrator für den sicheren Zugriff
  • Mandanten-Ersteller

Nein. Die am wenigsten privilegierte Rolle für Partnerbenutzer, damit sie Support-Tickets für ihre Kunden erstellen können, 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 über alle Rollen finden Sie unter Microsoft Entra integrierte Rollen. Informationen zu Workloads finden Sie unter Workloads, die von granularen delegierten Administratorrechten (GDAP)unterstützt werden.

Viele Rollen werden für 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 durch die Rollen des Globalen Readers, Verzeichnislesers und der Unterstützung durch Partnerrolle 2 bereitgestellt.

Es wird empfohlen, die Partner-Agents aus der Admin-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 durchführen möchten, können Sie dies mithilfe von APIs automatisieren.

Nein. Gastkonten funktionieren nicht mit GDAP. Kunden müssen alle Gastkonten entfernen, damit GDAP funktioniert.

GDAP-Gastadministratoren können ihre eigenen Sicherheitsinformationen bei My Security-Infonicht verwalten. Stattdessen benötigen Sie die Unterstützung des Mandantenadministrators, bei dem sie Gast sind, 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 registriert werden können, was kurznachrichtendienst (SMS) oder Voice ist. Weitere Informationen finden Sie unter mandantenübergreifende Zugriffsrichtlinien.

Richten Sie sich am Guiding-Prinzip von Zero Trust: Verwenden sie den geringsten Berechtigungszugriff:

• Es wird empfohlen, eine Rolle mit minimalen Rechten je nach Aufgaben zu verwenden, und Workloads, die von granularen delegierten Administratorrechten (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 empfehlen nicht, 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 365 und 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 bestehenden Ablauf der DAP-Beziehung, während DAP und GDAP koexistieren.

DAP wird derzeit gewährt, wenn ein neuer Kundentenant erstellt wird. Am 25. September 2023 gewährt Microsoft nicht mehr DAP 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:

Microsoft Entra-Rollen, die für Standard-GDAP erteilt wurden	Direktabrechnungspartner	Indirekte Anbieter	Indirekte Wiederverkäufer	Domänenpartner	Systemsteuerung Anbieter (CPVs)	Berater	Standard-GDAP deaktiviert (Kein DAP)
1. Verzeichnisleser. Kann grundlegende Verzeichnisinformationen lesen. Wird häufig verwendet, um Verzeichnislesezugriff auf Anwendungen und Gäste zu gewähren.	x	x	x	x	x
2. Verzeichnisautoren. Kann grundlegende Verzeichnisinformationen lesen und schreiben. Für die Gewährung des Zugriffs auf Anwendungen, nicht für Benutzer vorgesehen.	x	x	x	x	x
3. Lizenzadministrator. Kann Produktlizenzen für Benutzer und Gruppen verwalten.	x	x	x	x	x
4. Administrator des Service-Supports. Kann Dienststatusinformationen lesen und Supporttickets verwalten.	x	x	x	x	x
5. Benutzeradministrator. Kann alle Aspekte von Benutzern und Gruppen verwalten, einschließlich zurücksetzen von Kennwörtern für eingeschränkte Administratoren.	x	x	x	x	x
6. Administrator für privilegierte Rollen. Kann Rollenzuweisungen in Microsoft Entra und alle Aspekte von Privileged Identity Management verwalten.	x	x	x	x	x
7. Helpdesk-Administrator. Kann Kennwörter für Nichtadministratoren und Helpdesk-Administratoren zurücksetzen.	x	x	x	x	x
8. Administrator für privilegierte Authentifizierung. Kann auf die Informationen zur Anzeige, Festlegung und Zurücksetzung der Authentifizierungsmethoden für jeden Benutzer (Administrator oder Nicht-Administrator) zugreifen.	x	x	x	x	x
9. Cloudanwendungsadministrator. Kann alle Aspekte von App-Registrierungen und Unternehmens-Apps mit Ausnahme von App-Proxy erstellen und verwalten.	x	x		x	x
10. Anwendungsadministrator. Kann alle Aspekte von App-Registrierungen und Unternehmens-Apps erstellen und verwalten.	x	x		x	x
11. global reader. Kann alles lesen, was ein global administrierende Person kann, aber nichts aktualisieren kann.	x	x	x	x	x
12. Administrator des externen Identitätsanbieters. Kann den Partnerverbund zwischen Microsoft Entra Organisationen und externen Identitätsanbietern verwalten.				x
13. Domänennamenadministrator. Kann Domänennamen in der Cloud und lokal verwalten.				x

Partner können Privileged Identity Management (PIM) in einer GDAP-Sicherheitsgruppe im Mandanten des Partners implementieren, um den Zugriff auf einige Benutzer mit hohen Rechten zu erhöhen, nur rechtzeitig (JIT), um ihnen hohe Rechte 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/Mandanten 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 Cloud-Dienste von Microsoft (Microsoft 365, Dynamics 365, Microsoft Azure und 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 zur GDAP für Microsoft 365 und gleichzeitig Azure wechselt und DAP entfernt wird, geht PEC nicht verloren.
• Wenn der Kunde des Partners ÜBER DAP verfügt und er für Microsoft 365 zu GDAP wechselt, aber Azure as-is beibehalten (sie wechseln nicht zu GDAP) 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:

Kunde	Beziehung mit Partner
Kunde 1	DAP (ohne GDAP)
Kunde 2	DAP + GDAP beide
Kunde 3	GDAP (kein DAP)

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

Beispielbenutzer	Beispiel für kundenmandanten	Benehmen	Kommentare
Benutzer 1	Kunde 1	DAP	Dieses Beispiel ist DAP as-is.
Benutzer 1	Kunde 2	DAP	Es gibt keine GDAP-Rollenzuweisung für die Admin-Agents Gruppe, was zu DAP-Verhalten führt.
Benutzer 1	Kunde 3	Kein Zugriff	Es gibt keine DAP-Beziehung, sodass die Administrator-Agents Gruppe keinen Zugriff auf Kunden drei haben.
Benutzer 2	Kunde 1	DAP	Dieses Beispiel ist DAP as-is.
Benutzer 2	Kunde zwei	GDAP	GDAP hat Vorrang vor DAP, da benutzer zwei über die GDAP-Sicherheitsgruppe eine GDAP-Rolle zugewiesen wird, auch wenn der Benutzer Teil des Admin-Agents Gruppe ist.
Benutzer 2	Kunde 3	GDAP	Dieses Beispiel ist ein GDAP-Only-Kunde.
Benutzer 3	Kunde 1	Kein Zugriff	Es gibt keine GDAP-Rollenzuweisung für Kunde eins.
Benutzer 3	Kunde zwei	GDAP	Benutzer drei ist nicht Teil der Admin-Agenten-Gruppe, was zu einem nur-GDAP-Verhalten führt.
Benutzer 3	Kunde 3	GDAP	Nur GDAP-Verhalten

DAP und GDAP sind keine geeigneten Zuordnungstypen für Solutions Partner-Bezeichnungen. Eine Deaktivierung oder Umstellung von DAP auf GDAP wirkt sich nicht auf den Erhalt Ihres Lösungspartnerstatus aus. Außerdem ist die Erneuerung von Legacy-Kompetenzvorteilen oder Solutions Partner-Vorteilen nicht betroffen. Um die anderen Partnertypen zu sehen, die für die Bezeichnung 'Solutions Partner' berechtigt sind, klicken Sie auf 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 szenario Azure Lighthouse 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 für die Gruppe "Admin Agents" befindet sich ebenfalls 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 Beziehung zu Lighthouse (Projektion) ohne Auswirkungen auf GDAP abtrennen. Weitere Informationen finden Sie in der Dokumentation Azure Lighthouse.

Managed Service Providers (MSPs), die im Cloud Solution Provider(CSP)-Programm als indirect Reseller oder direct bill Partner registriert sind, können jetzt Microsoft 365 Lighthouse verwenden, um GDAP für jeden Kundenmandanten einzurichten. Da es mehrere Wege gibt, auf denen Partner ihren Übergang zu GDAP bereits steuern, ermöglicht dieser Assistent es Lighthouse-Partnern, empfohlene Rollen zu übernehmen, die ihren spezifischen Geschäftsanforderungen entsprechen. 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 um eine Demo anzusehen, finden Sie den 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 Requirements für Microsoft 365 Lighthouse.

Die richtige Reihenfolge für dieses Szenario ist:

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

Wichtig

Wenn Sie diese Schritte nicht ausführen, verlieren vorhandene Administrator-Agents, die Azure verwalten, möglicherweise den Zugriff auf Azure Abonnements für den Kunden.

Die folgende Sequenz könnte dazu führen, den Zugriff zu verlieren auf Azure-Abonnements.

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

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

Wenn Sie über Azure Abonnements without DAP verfügen, die Sie als Besitzer verwalten, können Sie beim Hinzufügen von GDAP für Microsoft 365 zu diesem Kunden den Zugriff auf die Azure Abonnements verlieren. Um einen verlorenen Zugriff zu vermeiden, verschieben Sie den Kunden auf Azure GDAP zur gleichen Zeit dass Sie den Kunden zu Microsoft 365 GDAP verschieben.

Wichtig

Wenn Sie diese Schritte nicht ausführen, verlieren die vorhandenen Administrator-Agents, die Azure verwalten, möglicherweise den Zugriff auf Azure Abonnements für den Kunden.

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

Wenn Sie über eine bestehende Händlerbeziehung 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 Rolle Verzeichnisleser.
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 erstellen, auch wenn keine DAP- oder GDAP mit einer bestehenden Händlerbeziehung vorhanden ist. 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: Verzeichnisleser, Globaler Reader. Weitere Informationen finden Sie unter präzise Berechtigungen für Sicherheitsgruppen gewähren.

Wenn sich ein CSP mit seinen CSP-Anmeldeinformationen im Azure-Portal des Kunden (portal.azure.com) anmeldet und eine GDAP-Beziehung besteht, bemerkt der CSP, dass sein Benutzername "user_" gefolgt von einer bestimmten Zahl ist. Der tatsächliche Benutzername wird nicht wie in DAP angezeigt. Es ist so beabsichtigt.

Mandantentyp	Verfügbarkeitsdatum	Verhalten der Partner Center-API (POST /v1/customers) enableGDAPByDefault: true	Verhalten der Partner Center-API (POST /v1/customers) enableGDAPByDefault: falsch	Verhalten der Partner Center-API (POST /v1/customers) Keine Änderung an Anforderung oder Nutzlast	Verhalten der Partner Center-Benutzeroberfläche
Sandbox	25. September 2023 (nur API)	DAP = Nein. Standard GDAP = Ja	DAP = Nein. Standard GDAP = Nein	DAP = Ja. Standard GDAP = Nein	Standard GDAP = Ja
Produktion	10. Oktober 2023 (API + UI)	DAP = Nein. Standard GDAP = Ja	DAP = Nein. Standard GDAP = Nein	DAP = Ja. Standard GDAP = Nein	Anmeldung/Abmeldung verfügbar: Standard-GDAP
Produktion	27. November 2023 (GA-Rollout am 2. Dezember abgeschlossen)	DAP = Nein. Standard GDAP = Ja	DAP = Nein. Standard GDAP = Nein	DAP = Nein. Standard GDAP = Ja	Opt-In/Out verfügbar: Standard-GDAP

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 "Anfrage für das Händlerverhältnis" ist in der Partner Center-Benutzeroberfläche verfügbar, und die API-Vertragseigenschaft "/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 nicht auf produktspezifische Admin Center (z. B. Teams Admin Center) zugreifen und diese verwalten.

Damit ein Partner oder CPV auf einen Kundenmandanten zugreifen und diesen verwalten kann, muss dem Dienstprinzipal der App im Kunden-Mandanten zugestimmt werden. Wenn DAP aktiv ist, müssen sie den Service Principal der App zum Admin Agents SG im Partnermandanten hinzufügen. Mit GDAP muss der Partner sicherstellen, dass im Kundenmandanten seiner Anwendung die Genehmigung erteilt wurde. Wenn die App delegierte Berechtigungen (App + Benutzer) verwendet und ein aktives GDAP mit einer der drei Rollen (CloudAnwendungsadministrator, Anwendungsadministrator) 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) 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 müssen.

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-Support zu beraten, um Ihre Einstellungen zu überprüfen und die Ursache des Problems zu identifizieren. Manchmal befindet sich das Problem in den Netzwerkeinstellungen Ihres Unternehmens. Ihr IT-Administrator müsste das Problem beheben, indem er beispielsweise unsere Website auf die Whitelist setzt oder andere Netzwerkeinstellungen anpasst.

• Restricted (Direct Bill): Neue GDAP (Administratorbeziehungen) können nicht erstellt werden. Vorhandene GDAPs und ihre Rollenzuweisungen können aktualisiert werden.
• Suspended (Direct Bill/Indirect Provider/Indirect Reseller): Eine 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 Rechnungen: Neue GDAP (Administratorbeziehungen) können 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 neues GDAP im Offboarding-Prozess nicht erstellt werden kann, können vorhandene GDAP und deren Rollenzuweisungen nicht aktualisiert werden.

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