Entra Gast-Adminrolle Cross-Tenant B2B Trust: Wie externe Benutzer Globaler Administrator werden

Entra Gast-Adminrolle und Cross-Tenant B2B Trust: Was diese Einstellungen wirklich steuern

Entra Gast-Adminrolle und Cross-Tenant B2B Trust gehören zu den am seltensten überprüften Schichten der externen Identitäts-Governance von Microsoft Entra ID, und ihre Kombination ergibt einen der leisesten Privilegien-Eskalationspfade der Plattform: ein externes Gastkonto mit einer direkt zugewiesenen Verzeichnisrolle, abgesichert durch Cross-Tenant-Zugriffseinstellungen, die anderen Microsoft-Entra-Organisationen standardmäßig Zugriff auf Ihren Tenant erlauben. Für sich genommen ist keine der beiden Hälften exotisch — B2B-Zusammenarbeit und die Zuweisung von Verzeichnisrollen sind beides dokumentierte Kern-Features von Entra — aber die Kombination wird selten als ein einziges Kontrollfeld geprüft.

Das ist ein anderer Blickwinkel als zwei verwandte Lücken, die Sie zuerst kennen sollten. Wenn Ihre Sorge ist, wer Gäste überhaupt einladen darf, ob sie MFA benötigen oder ob sich veraltete Konten ansammeln, siehe Azure Gastkonten: Die Vergessene Angriffsfläche in Ihrem Tenant. Wenn Ihre Sorge ist, dass ein Gast Privilegien erbt, weil er in einer Sicherheitsgruppe landet, die in eine rollenfähige Gruppe verschachtelt ist, siehe Entra ID: Verschachtelte privilegierte Gruppen, rollenfähige Gruppen und Gäste in Sicherheitsgruppen. Dieser Artikel behandelt etwas, das beiden vorgelagert ist: ein Gast mit einer Microsoft-Entra-Rolle direkt zugewiesen — keine Gruppe, keine Verschachtelung — und die Cross-Tenant-B2B-Trust-Konfiguration auf Tenant-Ebene, die entscheidet, welche externen Organisationen die Heimat-Identität dieses Gasts überhaupt erreichen können.

Fünf Prüfungen bilden diese Governance-Schicht:

Wie ein Gast eine Verzeichnisrolle erhält, und wie Trust-Einstellungen die Tür weiter öffnen

Die Zuweisung einer Rolle an einen Gast ist im Entra-RBAC kein Sonderfall

Das Rollenzuweisungsmodell von Microsoft Entra behandelt ein Gast-Principal in Bezug auf das Halten einer Verzeichnisrolle nicht anders als ein Mitglieds-Principal. Derselbe Rollenzuweisungs-Workflow — New-MgRoleManagementDirectoryRoleAssignment in PowerShell oder POST /roleManagement/directory/roleAssignments in Microsoft Graph — der einem internen Mitarbeiter die Rolle Helpdesk-Administrator zuweist, weist einem externen Gast-Objekt genauso bereitwillig die Rolle Globaler Administrator zu. Microsofts eigene API-Dokumentation zum Auflisten von Rollenzuweisungen zeigt das explizit: Das Beispiel zum Erweitern des principal-Felds einer Rollenzuweisungsantwort enthält Gastbenutzer ("userType": "Guest") mit einer Verzeichnisrolle genau neben Mitgliedsbenutzern, ohne jede Sonderbehandlung.

Das ist relevant, weil die Basis-Verzeichnisberechtigungen eines Gasts absichtlich eng gefasst sind. Die Gast-Berechtigungsstufe von Microsoft Entra (die Einstellung authorizationPolicy.guestUserRoleId) ist standardmäßig auf Eingeschränkter Zugriff (GUID 10dae51f-b6af-4016-8d66-8c2a99b929b3) gesetzt und kann auf Stark eingeschränkter Zugriff (2af84b1e-32c8-42b7-82bc-daa82404023b) verschärft werden, was einen Gast daran hindert, überhaupt Gruppenmitgliedschaften über seine eigenen hinaus aufzulisten. Aber diese Einstellung regelt die Standard-Sichtbarkeit von Verzeichnisobjekten für jeden Gast — sie ist keine Obergrenze für das, was eine explizite Rollenzuweisung einem einzelnen Gast gewähren kann. Ein Gast mit der Rolle Globaler Administrator besitzt vollständige administrative Berechtigungen für den gesamten Tenant, unabhängig davon, wie restriktiv die Basis-Gastberechtigungsstufe ist. Microsofts eigene Zero-Trust-Sicherheitsleitlinien führen Gästen werden keine hochprivilegierten Verzeichnisrollen zugewiesen als benannte Empfehlung, mit der Warnung, dass ein kompromittiertes Gastkonto mit einer erhöhten Rolle Angreifern einen Weg gibt, Privilegien zu eskalieren, Backdoor-Konten zu erstellen und im Tenant zu persistieren — und auch Third-Party-Posture-Tools führen dies als eigenständigen Befund: Tenables Exposure-Katalog listet „Guest Account With a Privileged Role" explizit auf und nennt reduzierte Auditierbarkeit und eine schwächere Sicherheitslage des Heimat-Tenants als Kernrisiko.

Cross-Tenant-Zugriffseinstellungen entscheiden, welche externen Identitäten diese Zuweisung überhaupt erreichen können

Eine Verzeichnisrollenzuweisung an einen Gast ist nur so eingedämmt wie die externe Identität dahinter. Die Cross-Tenant-Zugriffseinstellungen von Microsoft Entra steuern das aus der anderen Richtung — es sind Standard-Tenant-weite Regeln, die für jede andere Microsoft-Entra-Organisation gelten, sofern Sie keine organisationsspezifischen Überschreibungen konfigurieren. Gemäß Microsofts dokumentierten Ausgangswerten:

• B2B-Zusammenarbeit (b2bCollaborationInbound / b2bCollaborationOutbound): Alle Ihre internen Benutzer sind standardmäßig für B2B-Zusammenarbeit aktiviert — sie können externe Gäste einladen und anderswo als Gäste eingeladen werden, ohne dass eine organisationsspezifische Allowlist erforderlich ist.
• Inbound Trust (inboundTrust): MFA- und Geräte-Claims (konformes Gerät, Microsoft Entra Hybrid Join) von externen Organisationen werden standardmäßig nicht vertraut. Aktiviert ein Admin später „MFA von Microsoft-Entra-Tenants vertrauen" im Standard-Scope statt pro Partner, wird der MFA-Claim jeder externen Microsoft-Entra-Organisation akzeptiert — Conditional Access prüft MFA für keinen Gast mehr erneut, egal aus welchem Tenant, einschließlich solcher, von denen Sie noch nie gehört haben. Das ist B2B_INBOUND_TRUST_ALL.
• B2B Direct Connect (b2bDirectConnectInbound / b2bDirectConnectOutbound): standardmäßig in beide Richtungen tenant-weit blockiert — Microsoft dokumentiert dies als die einzige Einstellung in dieser Familie, die standardmäßig geschlossen ausgeliefert wird: „Ausgehender B2B Direct Connect ist für Ihren gesamten Tenant blockiert, und eingehender B2B Direct Connect ist für alle externen Microsoft-Entra-Organisationen blockiert." B2B_DIRECT_CONNECT_ENABLED schlägt an, wenn eine Änderung im Standard-Scope — nicht eine gezielte pro Partner — dies öffnet.
• Outbound-Zugriff: ebenfalls standardmäßig offen — Ihre Benutzer können in die Ressourcen jeder externen Microsoft-Entra-Organisation eingeladen werden, sofern der Outbound-Zugriff nicht eingeschränkt wird. B2B_OUTBOUND_UNRESTRICTED markiert genau diesen uneingeschränkten Outbound-Standard.

Sowohl Allow-/Block-Listen als auch Cross-Tenant-Zugriffseinstellungen werden zum Einladungszeitpunkt geprüft, aber wenn eine externe Domain auf keiner der Listen steht, fällt Microsoft Entra auf den konfigurierten Cross-Tenant-Zugriffsstandard zurück — der out of the box offen für Zusammenarbeit ist.

Die Eskalationskette

Schritt 1 — Eine externe Organisation lädt ein oder wird eingeladen, ohne organisationsspezifische Einschränkung

Weil die Standard-Einstellungen für B2B-Zusammenarbeit Inbound- und Outbound-Zugriff zu jeder externen Microsoft-Entra-Organisation erlauben, kann ein Gastkonto aus praktisch jedem Tenant in Ihren eingeladen werden — oder ein kompromittiertes Mitarbeiterkonto kann eines einladen — ohne eine Allowlist-Prüfung auszulösen.

Schritt 2 — Inbound-Trust-Einstellungen unterdrücken eine frische MFA-Abfrage

Ist Inbound Trust so konfiguriert, dass MFA-Claims externer Organisationen im Standard-Scope akzeptiert werden, prüft Microsoft Entra das Token des Gasts auf einen bereits im Heimat-Tenant erfüllten MFA-Claim — einem Tenant, den Sie weder kontrollieren noch prüfen können. Ist dieser Claim vorhanden, wird in Ihrem Tenant keine neue Abfrage ausgelöst, unabhängig davon, wie schwach oder stark die MFA-Durchsetzung des Heimat-Tenants tatsächlich ist.

Schritt 3 — Dem Gast-Objekt wird direkt eine Verzeichnisrolle zugewiesen

Irgendwo in der Historie des Tenants — ein einmaliges Vendor-Engagement, ein Break-Glass-Workaround, ein Admin, der „dem Gast vorübergehend Global Admin zuweisen" als Abkürzung nutzte, die nie zurückgenommen wurde — wurde die Objekt-ID des Gasts an einen Rollenzuweisungs-Aufruf übergeben. Nichts im RBAC von Entra ID blockiert dies auf API-Ebene, und sofern nicht jemand gezielt die Rollenmitgliedschaft für Gast-Principals abfragt, taucht es in einer routinemäßigen „Wer sind unsere Admins"-Prüfung, die Namen visuell durchgeht, nicht auf.

Schritt 4 — Die privilegierte Sitzung bleibt über den Heimat-Tenant des Gasts bestehen

Weil die Authentifizierung für diesen Gast weiterhin in seinem Heimat-Tenant stattfindet, sehen Ihre Conditional-Access-Richtlinien, Sign-in-Risikoerkennungen sowie Passwort-/MFA-Durchsetzung in Ihrem Tenant nur das, was die Trust-Einstellungen durchlassen. Eine Kompromittierung der Zugangsdaten im Heimat-Tenant des Gasts wird transitiv zu einer Kompromittierung einer privilegierten Identität in Ihrem.

Erkennung

# Microsoft Graph — aktuelle Standardhaltung der Cross-Tenant-Zugriffseinstellungen
GET https://graph.microsoft.com/v1.0/policies/crossTenantAccessPolicy/default

# Microsoft Graph — jede partnerspezifische Überschreibung
GET https://graph.microsoft.com/v1.0/policies/crossTenantAccessPolicy/partners

# Microsoft Graph — alle Verzeichnisrollenzuweisungen mit erweitertem principal;
# client-seitig nach principal.userType eq 'Guest' filtern
GET https://graph.microsoft.com/v1.0/roleManagement/directory/roleAssignments?$expand=principal

// Microsoft-Entra-Audit-Logs — Rollenzuweisungen, die auf einem Gast-UPN landen
AuditLogs
| where OperationName in ("Add member to role", "Add eligible member to role")
| where TargetResources[0].userPrincipalName contains "#EXT#"
| project TimeGenerated, OperationName, InitiatedBy = tostring(InitiatedBy.user.userPrincipalName), Target = tostring(TargetResources[0].userPrincipalName)

// Microsoft-Entra-Audit-Logs — Änderungen an der Standard-Cross-Tenant-Zugriffseinstellung
AuditLogs
| where Category == "CrossTenantAccessSettings"
| where OperationName has "default"
| project TimeGenerated, OperationName, InitiatedBy = tostring(InitiatedBy.user.userPrincipalName)

Behebung

1. Inventarisieren Sie jede Verzeichnisrollenzuweisung, die ein Gast hält, und entscheiden Sie für jede: braucht das dauerhaften Zugriff, braucht es überhaupt eine Rolle, oder wurde es nach einem kurzfristigen Engagement nie zurückgenommen. Behandeln Sie „wir wissen nicht, warum dieser Gast diese Rolle hat" als Vorfall, nicht als Konfigurationsnotiz.
2. Verschieben Sie jeden legitimen privilegierten Gastzugriff in PIM als eligible, zeitlich begrenzte Zuweisung mit erforderlicher Genehmigung, statt einer dauerhaften direkten Zuweisung. Siehe Azure Privilegierter Zugriff: Zu Viele Globale Admins dafür, warum dauerhafter privilegierter Zugriff schon bei Mitgliedskonten ein häufiger Befund ist, und Azure AD Premium P2 Funktionen: PIM, Identity Protection und Access Reviews, die niemand aktiviert hat dafür, was PIM zur Aktivierung benötigt.
3. Setzen Sie den Standard-Inbound- und -Outbound-Zugriff für B2B-Zusammenarbeit auf Blockieren, und fügen Sie organisationsspezifische Einstellungen nur für die externen Tenants hinzu, mit denen Sie tatsächlich zusammenarbeiten. Microsofts eigene Empfehlung ist, zunächst Inbound-/Outbound-Sign-ins zu identifizieren, damit eine Umstellung auf Standard-Blockieren keinen aktiven Geschäftszugriff kappt.
4. Verschieben Sie Inbound-MFA- und Geräte-Trust aus dem Standard-Scope. Wenn Sie MFA von einem bestimmten Partner vertrauen müssen, konfigurieren Sie das als organisationsspezifische Überschreibung nur für diesen Partner — nicht als pauschalen Standard, der für jeden jemals eingeladenen Microsoft-Entra-Tenant gilt.
5. Lassen Sie B2B Direct Connect standardmäßig blockiert — Microsofts eigene Ausgangshaltung — und aktivieren Sie es nur pro Organisation für Partner, die Sie über gegenseitige Konfiguration validiert haben.
6. Grenzen Sie den Outbound-Zugriff ein auf die Benutzer und Gruppen, die tatsächlich extern zusammenarbeiten müssen, statt standardmäßig alle internen Benutzer für Outbound-B2B zuzulassen.
7. Führen Sie Access Reviews durch, die gezielt auf privilegierte Rollenmitgliedschaft abzielen, nicht nur auf Gruppenmitgliedschaft — eine Review, die nur prüft „wer ist in der Gruppe der Globalen Admins", übersieht einen Gast mit einer direkten Rollenzuweisung außerhalb jeder Gruppe. Härten Sie die Standard-Tenant-Einstellungen breiter mit Azure Tenant-Härtung: Unsichere Defaults als begleitender Checkliste.

So erkennt EtcSec dies

EtcSecs Entra-ID-Audit prüft diese Governance-Schicht direkt. Gastbenutzer mit administrativer Rolle (GUEST_ADMIN_ROLE) markiert jeden Gast-Principal mit einer Verzeichnisrollenzuweisung. Cross-Tenant-Zugriff offen (B2B_CROSS_TENANT_OPEN) und Outbound-B2B-Zugriff uneingeschränkt (B2B_OUTBOUND_UNRESTRICTED) prüfen die Standard-Inbound-/Outbound-Haltung für B2B-Zusammenarbeit gegen organisationsspezifische Überschreibungen. Inbound Trust für alle Organisationen (B2B_INBOUND_TRUST_ALL) markiert MFA-/Geräte-Trust, der im Standard-Scope statt pro Partner konfiguriert ist. B2B Direct Connect aktiviert (B2B_DIRECT_CONNECT_ENABLED) bestätigt, dass Direct Connect nicht über Microsofts standardmäßig blockierte Haltung hinaus geöffnet wurde.

Für die angrenzenden Gast-Governance-Blickwinkel, die dieser Artikel nicht abdeckt, siehe Azure Gastkonten: Die Vergessene Angriffsfläche in Ihrem Tenant für Einladungsrichtlinien, MFA-Anforderungen und die Bereinigung veralteter Konten, sowie Entra ID: Verschachtelte privilegierte Gruppen, rollenfähige Gruppen und Gäste in Sicherheitsgruppen für Gäste, die Privilegien über Gruppenverschachtelung statt über eine direkte Zuweisung erreichen. Für die breitere Prüfung, in die diese Checks eingebettet sind, siehe Microsoft Entra ID-Sicherheit auditieren: praktischer Leitfaden.