GDAP - Granular Delegated Admin Privileges

Auch Cloud Dienste kennen einen oder sogar mehrere "Administratoren" oder entsprechende Rolle. Office 365/Microsoft 365 und Azure sind da keine Ausnahme. gibt es verschiedene Wege, diese administrativen Funktionen auszuführen. Das ursprüngliche DAP-Modell (Delegated Admin Privileges) wurde Anfang 2022 um ein "Granular delegated admin privileges (GDAP)"-Modell erweitert.

Dieses Modell ersetzt die alte Funktion per Delegierte Administration in Office 365

Important actions partners need to take to secure the partner ecosystem
https://docs.microsoft.com/en-us/partner-center/announcements/2022-august#4
Seit Anfang Aug 2022 bis 31. Okt 2022 gibt es das Partner Migrationstool.
Nach dem 30 Sep 2022 startet Microsoft mit dem Cleanup
"Microsoft will start removing DAPs that have been inactive for 90 or more days."
"Microsoft will transition active DAP connections to least privileged GDAP roles starting October 31, 2022"

Worum geht es?

Der erste Benutzer, der einen Office 365 Tenant einrichtet, ist in der Regel auch der "globale Admin" aber das ist nur der Startpunkt. Microsoft 365 unterscheidet schon zwischen "normalen Anwendern" und eben Anwendern mit erweiterten Berechtigungen. Das sollten Sie auch tun und gilt genauso für ihr lokales Active Directory. Auch hier sollten Sie z.B. separate und gesondert geschützte Konten für administrative Aufgaben nutzen. Auch wenn das immer noch nicht bei allen Firmen angekommen ist. In der Cloud gibt es aber noch weitere Aspekte, z.B. könnte die Administration an eine andere Firme delegiert worden sein. "Trusts" sind in der Cloud mangels Netzwerkgrenzen sehr einfach möglich. Mittlerweile gibt es eine ganze Menge von Optionen zur Einbindung von Personen als Administrator und alle Modelle können sogar parallel nebeneinander stehen. Bewerten Sie dazu u.a. die Punkte:

  • Kosten
    Für einige Funktionen, z.B. Empfang einer Mail im Postfach oder PIM benötigen die Konten eine Office 365/Azure Lizenz. Das sind zusätzlich Kosten, die z.B. einem Gast mit "bring our own license" nicht anfallen. Auch gesonderte Hardware (Fido-Key, Smartcard o.ä.) fallen hier darunter.
  • Provisioning/Exit Management
    Prüfen Sie, wie das Admin-Konto nicht nur angelegt, sondern auch zur Laufzeit und am Ende verwaltet wird. Auch Administratoren ändern ihren Namen oder vergessen das Kennwort und nach dem Ausscheiden oder einem Funktionswechsel sollten keine Rechte übrig bleiben
  • Auditing
    Die Aktionen von Administratoren sollten protokolliert werden. Prüfen Sie ihre Anforderungen, wo diese Logs landen. Im Tenant des Admins oder des Kunden?

Folgende Varianten beschreibe und bewerte ich kurz. Die Bewertung müssen Sie natürlich selbst machen.

Cloud Only Admin

Die einfaches Möglichkeit ist die Anlage eines "Cloud Only"-Kontos im Tenant, in dem der Benutzer berechtigt werden soll. Dies ist einfach und direkt aber sie sollten dabei einige Aspekte beachten:

  • Separates Konto
    Der Kunde muss dem Admin des Partners ein Konto mit Zugangsdaten anlegen und dieses verwalten.
  • Eigene Lizenz
    Wenn der Admin in dem Tenant mit lizenzpflichtige Optionen arbeiten muss, d.h. ein Postfach benötigt oder die Anmeldung per Conditional Access erfolgen soll, muss eine Lizenz zugeordnet werden
  • Lifecycle bei Rollen
    Das bedeutet auch, dass ein Admin beim Kunden die Rollen der anderen Administratoren ggfls. anpassen muss. Das gilt insbesondere für das EXIT-Management, d.h. dass ein Admin-Konto zeitnah gesperrt
  • Kein "Tenant Wechsel
    Als Admin beim Partner kann ich nicht einfach zum Kundentenant-Wechseln sondern muss z.B. mich ich einen zweiten Browser verbinden.
  • Unsichtbar für Partner
    Die Partnerfirma kann nicht wirklich sehen, was die eigenen Mitarbeiter in dem Kunden-Tenant als Administrator machen.

Durch das eigene Konto hat der Kunde die komplette Kontrolle über die Anlage, Kennwortrücksetzung, Auditing. Wenn die Einschränkungen nicht stören oder anderweitig gelöst werden, ist dies eine durchaus mögliche Variante.

ADSync-Admin

Wenn ein Partner auch ihr lokales Active Directory verwaltet, dann hat er meistens auch dort ein individuelles administratives Konto. Solche Konten sind durchaus üblich, da meist keine Netzwerkkopplung und damit schon gar kein NT-Trust vorhanden ist. Die Firmen nutzen dann RDP-Zugänge, TeamsViewer o.ä. um über Fernzugriff auf ein System des Kunden zu administrieren.

Wenn Sie diese Konto per ADSync aus dem lokalen AD auch in das AzureAD des Kunden repliziert haben, dann können Sie natürlich diesem Konto auch entsprechende Admin-Rollen zuweisen. Das Konzept ist aber sehr nahe am "Cloud Only Admin", nur dass er über das lokale AD synchronisiert wird.

Gast-Admin

Bei dieser Variante nutzen wir im Kunden-Tenant die Funktion, einen Benutzer eines anderen Tenant als Gast einzuladen und diesem Gast dann entsprechende Berechtigungen über die Azure Rollen zu vergeben. Der Kunde vertraut dabei natürlich auf die Identitätsverwaltung des Partner-Tenants, was aber gut ist. Der Partner ist damit für die Identitätsverwaltung der eigenen Personen zuständig und sobald s ein Admin-Konto deaktiviert ist

Sie könnten aber auch namentlich genannte Personen des Dienstleisters als "Gast" in ihren Tenant einladen und ihm dann die gewünschten Berechtigungen über die Rollen geben. Für Azure und Co ist das einfach aber für das Office365 Portal ist es kniffliger für den Dienstleister sich mir ihrem Tenant zu verbinden. Über die SignIn-Logs können Sie auch sehen was diese Konten tun.

Delegated Admin Privileges (DAP)

Ein Dienstleister kann einem Kunden einen Link geben damit Microsoft eine "Partnerbeziehung" zwischen dem Dienstleister und dem Kunden etablieren. Diese Beziehung wird von Microsoft als Delegated Admin Privileges (DAP) bezeichnet. Allerdings ist die Abstufung der Berechtigungen ehre rudimentär. Im Tenant des Partners gibt es drei vorgefertigte Gruppen:

Gruppe im Partner Tenant Berechtigungen im Kundentenant

AdminAgents

Global Admin

HelpdeskAgents

Helpdesk Admin

SalesAgents

 

Bei dem Setup ist aber gut zu sehen, dass alle Mitglieder von "AdminAgents" die "Global Admin"-Rolle bei allen Kunden haben, mit denen es eine DAP-Partnerschaft gibt. Es gibt noch mehrere Probleme:

  • Man ist dann gleiche Global Admin bei allen Kunden
    Das ist natürlich eine besonders hohes Risiko für den Partner, der damit sehr hohe Schutz
  • Eingeschränktes Rollenmodell
    Im AzureAD gibt es sehr viele Rollen die aber bei der Delegierung nicht berücksichtig werden.
  • Admin-Rechte sind verborgen
    Bei einem Audit allein auf die Azure Rechtegruppen finden Sie diese Partner nicht.
  • Keine Named Admin User
    Als Kunde haben sie keine Information, welche "Person" nun in ihrem Tenant aktiv ist. Speziell wenn der Partner nur generische administrative Konten verwendet.

Dennoch was und ist dieser Weg bei vielen Kunden noch zum Teil unwissentlich aktiv ist aber heute nicht mehr den Sicherheitsanforderungen entspricht.

Wenn heute ein Partner über DAP in ihrem Tenant administriert, dann sollten Sie ihn Fragen, in welchem Zeitraum er auf GDAP wechseln wird.

Das gilt umso mehr, da Microsoft das Ende von DAP schon angekündigt hat:

Additionally, DAP will be deprecated soon, and we strongly encourage all partners who are actively using DAP to manage your customer tenants and move towards a least privilege Granular Delegated Admin Privileges model to securely manage your customers tenant.
https://docs.microsoft.com/en-us/partner-center/partner-security-requirements#delegated-admin-privileges-dap

Granular delegated admin privileges (GDAP)

Die doch sehr umfangreichen Berechtigungen eines DAP-Zugangs waren in der Startphase von Office365/Microsoft 365 durchaus zu tolerieren. Wer diesen Weg nicht gehen wollte, konnte ja immer noch "Gastbenutzer" als Administrator oder eigne Admin-Konten in der Cloud verwenden. mit GDAP kombiniert Microsoft die Verwaltung über administrativen Rollen in einem Kunden-Tenant mit einem Benutzerkonto im Partner-Tenant. Technisch ist es also nahe am DAP-Modell nur dass die Berechtigungen feiner vergeben werden können.

Die erste Frage hier bei ist, ob Sie die erweiterten Berechtigungen in einem Kunden-Tenant nun ihrem normalen AzureAD-Konto, einem eigenen AzureAD-Konto im Partnertenant oder sogasr in einem ganz eigenen Tenant zuweisen. Bei DAP gab es diese Frage aber auch schon.

Zwischen DAP und GDAP gibt es einige Unterschiede:

Feature DAP GDAP

Zugriffslevel
  • Global Admin
  • Helpdesk Admin

Granular nach Rollen

Dauer der Berechtigung

Keine Ablaufdatum

Maximal 2 Jahre

Einladungslink

Ein Link des CSP für alle Tenants

Individuell pro Tenant, Zeit und Rolle

Zuweisung über Sicherheitsgruppen

Nein

Ja

Beschränkungen auf Funktionen

Nein

Ja

PIM

Nein

Ja

Das ist nur eine kurze Gegenüberstellung. Aber es ist offensichtlich, dass DAP kein Zukunft hat. Microsoft schreibt dies selbst:

We highly recommend moving away from the current DAP model (which gives admin agents standing or perpetual global admin access) to a fine-grained delegated access model. The fine-grained delegated access model reduces the security risk to customers, and the impact on them as well. 
Quelle: https://docs.microsoft.com/en-us/partner-center/announcements/2021-november#details-16

Als Kunde sollten Sie ihre Partner darauf ansprechen, welche Berechtigungen der Partner warum anfordert und welche Alternativen er ihnen anbietet, wenn ihnen "Global Admin" zu unsicher ist.

Monitor DAP usage
https://partner.microsoft.com/en-us/resources/detail/granular-delegated-admin-privileges-in-csp-pdf

Granular Delegated Admin Privileges-GDAP
https://www.youtube.com/watch?v=5ZefMwvmSac&ab_channel=NickRoss

GDAP anfordern

Nur weil sie heute vielleicht schon bei ihren Kunden per DAP  berechtigt sind, werden diese Einstellungen nicht automatische zu GDAP übertragen. Sie müssen daher all ihre Kunden, in denen Sie heute schon DAP-Administrator sind, neu einladen. Dabei ist der "Einlade-Link" und die Partnerschaft eine neue Konfiguration, die individuell sein muss. Startpunkt ist wieder der Dienstleister, der in seinem Partner Admin-Center einen neuen "Admin relationship request" unter Angabe eines eindeutigen Namens, eine Dauer und der gewünschten Rollen erstellt. Da es hier noch keine Verbindung zum Kunden-Tenant gibt, dürfte GDAP auf die AzureAD-Standardrollen beschränkt sein.

https://partner.microsoft.com/commerce/granularadminaccess/newadminrelationshiprequest

Tipp:
Überlegen Sie sich ein Namenskonzept für den "Admin relationship name", denn er muss eindeutig in ihrem Partner-Tenant sein. Eine Kombination aus Rolle und Zieltenant könnte eine gute Idee sein.

Ein Partner sollte nur die Rollen anfordern, die er später ganz oder teilweise über eigene Sicherheitsgruppen an die administrativen Benutzer delegieren will. Ein mündiger Kunde sollte einer zu umfangreichen Rechteanforderung nicht zustimmen.

Das Ergebnis ist dann ein Textbaustein, den ich an den Kunden sende oder als DAP-Admin notfalls auch selbst ausführe:

Auch wenn es auf den ersten Blick nicht so aussieht, ist der Link nur genau einmal gültig.

GDAP bestätigen

Achtung.
Nicht nur theoretisch könnte in Angreifer einen Tenant anlegen und einen Partnerlink erstellen und ihnen per Phishing zusenden. Prüfen Sie genau, ob die angezeigten Informationen authentisch sind und rufen Sie gerne ihren Partner dazu an, ob er diesen Request auch ausgelöst hat.

Mit dem Link kann ich nun im anderen Tenant die Delegierung einleiten und bestätigen.

Allerdings sehen Sie hier auch, dass ich nur "Alle genehmigen" kann. Der Partner stellt eine Vorlage mit einer Gruppen von Berechtigungen und der Dauer ein.

Als mündiger Kunde sollte ich genau prüfen, welche Berechtigungen hier welcher Partner anfordert und ggfls. die Anforderung ablehnen und um eine neue passende Anforderung bitten.

Microsoft zeigt ihnen aber auch noch explizit eine Warnung:

Danach erscheint die Partnerschaft in der regulären Übersicht. Hier zur Abwechslung mal mit einem deutschen Admin-Portal.

Der Versuch den gleichen Link noch einmal in einem anderen Tenant zu verwenden, schlägt aber fehl.

Bestätigung per Mail

Der Partner selbst bekommt eine Mail, wenn Sie als Kunde die Anfrage bestätigt haben:

Diese Mail bekommen übrigens alle Benutzer mit Postfach und der Rolle "Admin Agent" im Partner Center.

Natürlich erscheint die erfolgreich eingerichtete Beziehung auch im Partner-Portal. Die Mail kommt von "Microsoft Partner Center <msftpc@microsoft.com>" und ist korrekt DKIM-signiert.

Keine Azure Rolle

Ich habe natürlich auch in den Azure Role Groups nachgeschaut. Der Tenant "Net at Work GmbH" hat ja nun die Rollen "Exchange Recipient Administrator" und "Groups Administrator" auf meinen MSXFAQLAB-Tenant. Wie schon bei DAP erscheinen diese Rechte aber nicht in den AzureAD Rollengruppen.

Für Sie als Administrator oder Auditor bedeutet dies, dass Sie nicht nur die AzureAD-Gruppen kontrollieren müssen sondern auch die Partner-Beziehungen

AuditLog

Zumindest wird die Partner-Delegation im AzureAD Auditlog protokolliert:

Die Details verraten dann, dass da wohl ein

Adminrollen zuweisen

Nach dem Abschluss der Aktionen haben wir nun eine Art "Vertrauensstellung" zwischen dem Kunden und den Partner. Da gibt es ein Objekt im Kundentenant, welche die entsprechenden Rollenzuweisungen hat aber für den Kunden-Administrator nicht im Azure-Portal sondern nur über das Microsoft 365 Portal sichtbar ist.

Aber auch auf der Partnerseite sind nun noch weitere Schritt erforderlich. Über das Adminportal im Partner-Center (https://partner.microsoft.com/commerce/granularadminaccess/list) sehe ich alle Tenants, die ich administrieren kann. Sogar die Links zur Verwaltung sind schon vorgegeben.

Die Exchange Verwaltung verweist in dem Beispiel dann auf (OrgGUID und PartnerDomain unkenntlich gemacht):

https://admin.exchange.microsoft.com/?rfr=Admin_o365&exsvurl=1&delegatedOrg=<OrgGuig>&mkt=en-US&Realm=<partnerdomain>

Allerdings können Sie selbst als globaler Admin noch nicht auf den anderen Tenant zugreifen. Sie müssen erst auf den Namen der Firma klicken und sehen dann die Liste der Relationships.

Hier müssten Sie dann noch mal auf den "Relationshipname" klicken, um dann die Sicherheitsgruppen ihres Tenant zuzuweisen:

Sie können aber nur Gruppen zuweisen und keine individuelle Personen. Mögliche Gruppen sind "Sicherheitsgruppen" und "Mail enabled security groups" aber keine reinen Verteiler (Distributiongroup) oder "Microsoft 365 Groups". Wenn sie eine Gruppe addiere, können Sie im zweiten Schritt aber die Rollen auswählen, d.h. die Partnerschaft ist nur der Container über den dann mehrere Gruppen mit unterschiedlichen Berechtigungen zugeteilt werden können.

Der Kunde selbst sieht aber nur die Delegierung aber nicht, welche Gruppen genau welche Berechtigungen bekommen hat und wer in den Gruppen enthalten ist.

Allerdings wird das neu gewährte Recht sehr wohl im Kundentenant per Auditing sichtbar:

Also Kunde kann ich so zumindest sehen, wenn sich etwas verändert aber die GUIDs passend nicht zur Gruppe im Partner-Tenant.

Welcher Partner Tenant?

Sie wissen nun, dass sie Benutzer in eine "Verwaltungstenant" brauchen, die ihrerseits in Sicherheitsgruppen dieses Verwaltungstenant Mitglied sind, welche dann wiederum in den Admin Relationships des Tenants aufgenommen werden, über die diese Konten dann im Kundentenant berechtigt sind.

Da stellt sich nun natürlich die Frage, in welche Tenant diese Admin-Konten angelegt werden. Auch hier gib es ja zwei Optionen für den Dienstleister, der ja sicherlich auch Office365/Microsoft 365 nutzt:

  • Reguläre Benutzer im regulären Firmen-Tenant
    Die Mitarbeiter des Partners haben ihr normales AD-Konto, mit dem Sie auch im AzureAD arbeiten. Sie könnten dieses Konto auch für GDAP nutzen. Allerdings ist das sicher keine gute Praxis, da auch eine Malware im Umfeld des Mitarbeiters die GDAP-Rechte nutzen könnte. Nicht umsonst schreibt Microsoft MFA für die Konten vor.
  • Separate Benutzer im regulären Firmen-Tenant
    Wer Administration und "Bürotätigkeit" trennen will, legt für die Administratoren im anderen Tenant
  • Separate Benutzer im einem CSP-Tenant

Eine pauschale Antwort kann ich hier leider nicht geben, da jede Variante individuelle Vorteile und Nachteile hat. Neben den reinen administrativen Aufgaben gibt es noch andere Aspekte zu berücksichtigen:

  • Lizenzen
    Speziell wenn sie separate Benutzer für die Administration in anderen Tenants wählen, was ich dennoch empfehle, könnten zusätzliche Lizenzen z.B. für ConditionalAccess (AzureAD P1) oder sogar PIN (AzureAD P2) erforderlich werden.
  • Vertriebliche Zuordnung
    Für eine Microsoft Partnerschaft ist es erforderliche, dass man bestimmte Seats bei Kunden mit dem Partner-Tenant verknüpft hat. Das hat erst einmal nichts mit administrativen Aufgaben zu tun. Dennoch ist es von Belang, da ein Microsoft Partner ja einen "Betriebstenant hat. Wer einen eigenen Admin-Tenant betreibt, muss genau schauen, über welchen Tenant dann die Administration und Lizenzvergabe für die Kunden erfolgt.

Neben diesen Fragen und den drei möglichen Konfiguration der GDAP-Adminkonten gibt es natürlich immer noch die Option, einfach per Gast sich die Adminrollen geben zu lassen.

Der Wechsel von DAP zu GDAP hingegen sollte kein Problem sein.

Partners can transition from DAP to GDAP and eventually remove DAP (Global Admin) on customers’ tenant without any effect to partner earned credit (PEC).
Quelle: https://docs.microsoft.com/en-us/partner-center/gdap-introduction

Partner Admin URLs

Über das Partner Center kommen Sie über den Kunden zu einer Seite (https://partner.microsoft.com/commerce/customers/<TenantGUID>/servicemanagementpage), die ihnen zu jedem Kunden direkte Einsprungadressen in die Portale des Kunden liefern. Es ist die normalen Portale, die aber als Parameter die GUID des Kundentenant enthalten.

Portal URL

Azure Active Directory

https://aad.portal.azure.com/<Tenantguid>

Dynamics 365 Business Central

https://businesscentral.dynamics.com/<TenantGUID>/admin

Endpoint Manager

https://endpoint.microsoft.com/<TenantGUID>

Exchange

https://admin.exchange.microsoft.com/?exsvurl=1&delegatedOrg=<TenantGUID>

Lifecycle Services

https://lcs.dynamics.com/Logon/Adlogon?ctid=<TenantGUID>

Microsoft 365

https://portal.office.com/Partner/BeginClientSession.aspx?CTID=<TenantGUID>&CSDEST=o365admincenter

Microsoft 365 Compliance

https://compliance.microsoft.com/?tid=<TenantGUID>

Microsoft 365 Defender

https://security.microsoft.com/?tid=<TenantGUID>

Microsoft 365 Lighthouse

https://lighthouse.microsoft.com/

Microsoft Azure Management Portal

https://portal.azure.com/<TenantGUID>

Power BI

https://app.powerbi.com/admin-Portal?ctid=<TenantGUID>

Power Platform

https://admin.powerplatform.microsoft.com/account/login/<TenantGUID>

Teams

https://admin.teams.microsoft.com/?delegatedOrg=<TenantGUID>

SharePoint Online

https://admin.microsoft.com/Partner/beginclientsession.aspx?CTID=<TenantGUID>&CSDEST=SharePoint

Visual Studio Marketplace

https://app.vsaex.visualstudio.com/integrationredirect/cspPartnerSignin?tenantId=<TenantGUID>&replyto=https://marketplace.visualstudio.com

Manage Visual Studio subscriptions

https://app.vsaex.visualstudio.com/integrationredirect/cspPartnerSignin?tenantId=<TenantGUID>&replyto=https://manage.visualstudio.com/Subscribers?act_id=2

Wenn Sie das GUID die eines eigenen Tenants oder einen Kunden-Tenants eintragen, auf dem sie berechtigt sind, kommen sie so auch direkt ins jeweilige Portal. Das Funktioniert auch mit "Gast-Benutzern", denen entsprechende administrative Rollen zugewiesen wurden.

Rückbau durch Kunde

Bei einem Pharmakonzern habe ich vor vielen Jahren einmal gelernt, dass ein Administrator nicht nur neue Dinge einführen sollte, sondern auch den Rückbau beschreiben muss. Diese Rückbauanleitung sollte it jedem Update oder Patch immer aktuell gehalten werden. Stellen Sie sich mal vor, ein Administrator samt seinem Wissen verlässt das Unternehmen und niemand weiß dann mehr, wie ein System ordnungsgemäß zurückgebaut wird.

Der Kunde kann jederzeit seine Erlaubnis zur Administration durch einen Partner beenden. Er kann aber immer nur den kompletten Eintrag beenden und nicht einzelne Rollen ausschließen.

Beim Partner erscheint die Löschung dann mit dem Status "Terminated"

Der Partner kann dann den Eintrag bei sich löschen. Die Partnerschaft kann aber nicht wieder "erneuert" werden.

Lifecycle

Anders als bei der Berechtigung per DAP ist die GDAP-Erlaubnis immer zeitlich beschränkt. Nach spätestens 730 Tagen ist ein "Renew" durch den Partner und den Kunden erforderlich. Damit möchte Microsoft wohl sicherstellen, dass ein Partner nicht unbemerkt durch den Kunden weiter Zugriff auf die Admin-Portal des Kunden hat. Das ist gut gedacht aber selbst 730 Tage ist relativ lange, wenn ein Kunde mit seinem Partner über Kreuz liegt und vergisst, die granularen administrativen Berechtigungen zu entfernen. Ob der Partner ihn in dem Fall darauf hinweist, steht auf einem anderen Blatt.

Daher sendet Microsoft 30 Tage vor Ablauf der Partnerschaft eine Mail sowohl an den Kunden als auch den Partner. Sie sollten natürlich sicherstellen, dass diese Mails auch gelesen und adäquat behandelt werden. Die Mail an die Partner enthalten direkt einen Link zum Partnercenter. Die Mail an den Kunden allerdings ist nur eine Text-Information, dass er auf den Kontakt durch den Partner warten soll.

Ich hätte mir schon gewünscht, dass auch der Kunde einfach per Link ein "Verlängern" bestätigen kann.

So sehe ich viele Partner vor der Aufgabenstellung, die GDAP-Konfiguration zu überwachen und einen Prozess zur Erneuerung der Vertrauensstellungen zu etablieren.

Rückbau durch Partner

Deutlich seltener wird vermutlich ein Partner die Verbindung zu einem Kunden-Tenant beenden. Sie ist ja gerade der Schlüssel, weitere Dienstleistungen zu erbringen. Dennoch ist auch dies möglich:

Interessanterweise kann ich eine Partnerschaft nur entfernen, wenn sie noch aktiv ist. Sie bekommt dann erst einmal den Status "Termination requested"

Wenn der Kunde die Partnerschaft seinerseits entfernt hat, dann steht sie bei mir im Tenant für einige Zeit noch als "Terminated", aber ich kann sie nicht löschen. Im Hintergrund gibt es wohl einen Cleanup-Prozess, denn einige Seite später zeigt mit die gleiche Seite einen Fehler an und wenn ich dann neu von Anfang über die "Kunden - Administration" einsteige, ist der Tenant nicht mehr da.

PowerShell

Ich bin sicher, dass die Einrichtung und Verwaltung von GDAP auch per Skript möglich ist. Es gibt eine eigene Partner Center API, über die solche Aktionen auch automatisiert werden können.

Natürlich gibt es auch eine PowerShell

Hiermit habe ich mich aber nicht weiter beschäftigt.

Einschränkungen

GDAP ist aber noch nicht perfekt, denn einige Funktionen fehlen mir immer noch:

  • Keine Custom Roles
    Aktuell kann ich nur die Standard-Rollen anfordern. Wenn der Kunde "Custom Admin Roles" verwendet, sind diese für mich als Partner nicht nutzbar
  • Keine Admin-OUs
    Ein AzureAD hat eigentlich keine Struktur sondern ist flach wie eine NT4-Domain. Ich kann im Kundentenant allerdings AdminScopes einrichten, um die Berechtigung von Adminrollen zu beschränken. Das ist mit GDAP meines Wissens noch nicht möglich
  • Nicht immer sind Admin-Rollen ausreichend
    Der Zugriff auf das jeweilige Portal ist nicht immer für die Administration ausreichend. Für Exchange gibt es quasi nur den Exchange Admin und den Exchange Recipient Admin. Für die Ausführung des Hybrid Configuration Wizard muss es aber immer noch ein "Global Admin" sein.

Diese Einschränkungen sind mir schon beim ersten Test aufgefallen. Es könnte noch mehr geben oder die Liste ist bald schon überholt.

Conditional Access

Wenn Sie als Partner auf ein Portal eines anderen Tenants zugreifen wollen, werden natürlich auch hier Regeln des "Bedingten Zugriffs" angewendet. Da beim Wechsel natürlich keine klassische Anmeldung über das Porta erfolgt, scheint die Bestätigung von "Terms of Use" nicht zu funktionieren. Wenn also ihr Kunde hier eine solche Anzeige vorschaltet, klappt das nicht.

Der Kunde sollte dann seine Conditional Access-Regel für die "Service Provider Users" anpassen:

Dann funktioniert es auch wieder mit dem Zugriff der Service Provider.

Doch als Gast?

Ich habe an mehreren Stellen beschrieben, dass es neben DAP und GDAP noch eine dritte Option mit Gast-Konten gibt. Stellen Sie sich folgende Aktionen vor

  • CSP-Parter hat einen Admin mit dem UPN "frank@msxfaq.de"
    Das ist das Anmeldekonto, mit dem der namentlich bekannte Supporter bei Kunden aktiv werden soll.
  • Kunde lädt den Admin als Gast ein
    Auch das ist erst einmal keine besondere Aktivität. Der Admin kann sogar MFA in seinem Tenant vorschreiben.
  • Kunde addiere den Gast in Admin-Rollen
    Der Admin beim Kunden hat die komplette Kontrolle und Sichtbarkeit, welcher Gast welche Admin-Rollen ausüben kann. Soweit möglich könnten sogar Admin-Scopes und PIM eingesetzt werden.
  • frank@msxfaq.de nimmt die Einladung an.
    Ab sofort kann er den Kunden administrieren, wenn er den Weg zu den Portalen kennt.

Da stellt sich die Frage nach den Nachteilen und Einschränkungen:

  • Kein Adminportal im Partnercenter
    Es soll Administratoren geben, die über das Partner Center den Weg zum Tenant des Kunden suchen. Ein paar Zeilen weiter oben habe ich ihnen aber die Links beschrieben, mit denen ich direkt über die bekannte GUID des Kunden in sein Portal komme.
  • POR/DPOR etc.
    Die Delegierung von Admin-Rechten hat meines Wissens nichts mit den vertrieblichen Verbindungen zu tun.
  • Support Portal
    Als DAP/GDAP-Admin kann ich im Partner-Porta auch für den Kunden Supporttickets starten und bearbeiten. Das geht wohl mit einem Gast-Admin nicht.

Ich sehe eher die Vorteile, dass die Kontrolle komplett beim Kunden verbleibt. Notfalls kann ich mir als Partner auch einen Admin-Benutzer im Kundentenant (ohne Lizenz) anlegen, um ggfls. weitere Administratoren zu konfigurieren.

Aktuell habe ich aber auch keine richtigen Nachteile bei der Verwendung von Gast-Benutzern und Administrativen Rollen im Kundentenant gefunden. Gibt es hier Hinweise meiner Leser, warum dieser von DAP und GDAP unabhängige Weg nachteilig ist, mal abgesehen, dass der Kunde die Kontrolle behält und die Ersteinrichtung assistiert erfolgen muss?

Migration

Zuerst hat Microsoft GDAP bereitgestellt und es den Partnern überlassen, ihre Kunden manuell einzuladen. Mittlerweile ist GDAP aus verständlichen Sicherheitsgründen das zukünftige Modell und seit dem 8. Aug 2022 bis 31. Okt 2022 gibt es ein Migrationstool für Partner.
Um die Umstellung zu forcieren wird Microsoft ihrerseits nach dem 30. Sep 2022 anfangen, ungenutzte DAP-Einträge zu entfernen und minimale GDAP-Berechtigungen umzusetzen.

Important actions partners need to take to secure the partner ecosystem
https://docs.microsoft.com/en-us/partner-center/announcements/2022-august#4
Seit Anfang Aug 2022 bis 31. Okt 2022 gibt es das Partner Migrationstool.
Nach dem 30 Sep 2022 startet Microsoft mit dem Cleanup
"Microsoft will start removing DAPs that have been inactive for 90 or more days."
"Microsoft will transition active DAP connections to least privileged GDAP roles starting October 31, 2022"

Als Partner sind Sie also gut beraten, alle bestehenden Partner-Beziehungen möglichst schnell umzustellen.

Einschätzung

Aus meiner Sicht sind die neuen "Granular Delegated Admin Privileges" ein wichtiger Schritt die Verwaltung eines Kundentenants über einen Partner auf eine sichere und bessere Plattform zu stellen. Die Vergabe von Rechten über eine "AgentAdmin"-Gruppe ohne einer Segmentierung nach Kunde oder Admin ist schon lange nicht mehr zeitgemäß. Microsoft erzwingt auch MFA für diese Konten, was generell eine gute Idee ist. Das kann aber die eigene Arbeit im eigenen Tenant natürlich stören. Daher gibt es das Konstrukt einen CSP-Tenants, d.h. ein eigener Tenant mit eigenen Admin-Benutzern, die vom Partner dann zur Verwaltung bei Kunden genutzt werden sollen. Aktuell schreibt Microsoft aber einen separaten CSP-Tenant nicht vor. Etwas zu Kurz kommt mit in dem Fall aber die Nutzung von Gastkonten aus dem Partner oder CSP-Tenant im Kundentenant. Das geht nämlich auch problemlos und der Kunde könnte genau sehen, welche Person letztlich welche Berechtigungen hat.

Wenn sie aber GDAP einführen wollen, dann sollten Sie einige Fragen vorab machen:

  • In welchem Tenant liegen die administrativen Konten
    Das kann ihr Partner-Tenant oder ein eigens betriebener CSP-Tenant sein, auf dem MFA aktiv ist.
  • Namenskonzept für den "Relationship-Name"
    Überlegen Sie welche Rechte Sie von den unterschiedlichen Kunden anfordern und benennen Sie das Objekt so, dass der Kunde damit auch was anfangen kann. Sie brauchen für jeden Kunden-Tenant mindestens ein solches Objekte.
  • Sicherheitsgruppen zur Verknüpfung
    Diese Gruppen sind in ihrem Tenant und geben den Mitgliedern die Rechte auf alle "Relationships", in denen diese zugewiesen werden. Wer als Managed Service z.B. drei Exchange Supporter hat, die bei allen Kunden das Gleiche machen, dann könnte eine "CSP-Exchange-Support"-Gruppe mit diesen drei Mitgliedern reichen die sie an die verschiedenen Relationships mit den gewünschten Rechten binden. Wenn Sie aber pro Kunde eigene Personengruppen zuweisen wollen, dann brauchen sie mehrere Gruppen.
    Überlegen Sie, ob diese Gruppen als "Cloud Only" Gruppen im AzureAD separat gepflegt werden oder aus dem lokalen AD per ADSync aktualisiert werden.

Dokumentieren Sie die Einstellungen gut und informieren Sie auch den Kunden, denn der kann nicht sehen, welchen Personen Sie welche Berechtigungen eingeräumt haben. Er sieht es später nur bei Veränderungen durch den delegierten Administrator.

Die klassische alte Delegierung mittels DAP sollten Sie nicht neu einrichten und den Wechsel auf GDAP planen. In naher Zukunft soll es wohl ein Migrationswerkzeug geben, um einen Kunden von DAP auf GDAP umzustellen. Das Ende von DAP ist aber eingeläutet.

Weitere Links