Entra ID Gast Conditional Access Richtlinie, Externe Zusammenarbeitseinstellungen — Die Sechs Standardwerte, Die Gegen Sie Arbeiten

Ihre Entra ID Gast Conditional Access Richtlinie, externe Zusammenarbeitseinstellungen sind eigentlich zwei getrennte Kontrollebenen, die die meisten Tenants einmal bei der Ersteinrichtung konfigurieren und danach nie wieder anfassen. Conditional Access entscheidet, ob ein angemeldeter Gast zu MFA, einem konformen Gerät oder einer stärkeren Authentifizierungsmethode aufgefordert wird. Die externen Zusammenarbeitseinstellungen entscheiden, wer überhaupt Gast werden darf, was ein Gast sehen kann, sobald er drin ist, und wie lange dieses Gastkonto bestehen bleiben darf. Ein Tenant kann eine exzellente MFA-Abdeckung für Mitarbeiter haben und trotzdem jeden dieser gastspezifischen Standardwerte genau dort belassen, wo Microsoft sie ausliefert — was, bei mehreren von ihnen, die freizügigste Option ist.

Dieser Artikel geht sechs konkrete Lücken in dieser Gast-Kontrollebene durch, jede einem dokumentierten Microsoft-Standardwert oder -Mechanismus zugeordnet: Keine Conditional-Access-Richtlinie wertet Gastanmeldungen tatsächlich aus, Gäste können andere Gäste einladen, Gäste können das Verzeichnis durchsuchen, Gastkonten laufen nie ab, niemand bemerkt einen Gast, der sich nie angemeldet hat, und Gäste können auf Unternehmensanwendungen zugreifen, denen sie nie zugewiesen wurden. Keine dieser Lücken erfordert, dass ein Angreifer eine Schwachstelle ausnutzt — sie erfordern nur, dass ein Administrator die Werkseinstellungen des Tenants unangetastet gelassen hat. Für das vollständige Bild, wie man einen Tenant end-to-end prüft, siehe Microsoft Entra ID-Sicherheit auditieren: praktischer Leitfaden.

Entra ID Gast Conditional Access Richtlinie, Externe Zusammenarbeitseinstellungen, Definiert

Gastzugriff in Entra ID beginnt mit einer Einladung — B2B-Zusammenarbeit erstellt ein Benutzerobjekt mit UserType auf Guest gesetzt in Ihrem Verzeichnis, abgesichert durch Anmeldeinformationen im eigenen Heimat-Tenant des Gastes oder dessen Identitätsanbieter. Ab diesem Punkt regeln zwei unabhängige Einstellungsgruppen, was der Gast tun kann.

Einstellungen für die externe Zusammenarbeit (Entra ID > Externe Identitäten) steuern die Einladungsberechtigungen für Gäste, die Sichtbarkeit des Verzeichnisses für Gäste, die Selbstbedienungsregistrierung sowie Domänen-Zulassungs-/Sperrlisten. Conditional Access ist eine separate Richtlinien-Engine, die jede Anmeldung — einschließlich Gastanmeldungen — gegen Zuweisungsregeln auswertet, die auf bestimmte Gast- und externe Benutzertypen zielen können: B2B-Kooperationsgastbenutzer, B2B-Kooperationsmitgliedsbenutzer, B2B-Direct-Connect-Benutzer, lokale Gastbenutzer, Dienstanbieterbenutzer und andere externe Benutzer — jeder davon kann unabhängig eingeschlossen oder ausgeschlossen werden, für einen Tenant oder für alle Tenants.

Diese beiden Systeme kommunizieren nicht miteinander. Ein Gast kann unter den freizügigsten Zusammenarbeitseinstellungen eingeladen werden und trotzdem von einer strikten Conditional-Access-Richtlinie blockiert werden — oder unter strikten Zusammenarbeitseinstellungen eingeladen werden und trotzdem mühelos durch eine Conditional-Access-Richtlinie gleiten, die Gäste überhaupt nie auswertet. Das eine ohne das andere zu prüfen, ist nur die halbe Wahrheit — siehe Azure Gastkonten: Die Vergessene Angriffsfläche in Ihrem Tenant für das breitere Gast-Expositionsmodell, in das sich die sechs Lücken dieses Artikels einfügen.

Wie Gäste der Conditional-Access-Abdeckung entkommen

GUEST_NO_CA_POLICY [HIGH] schlägt an, wenn keine aktivierte Conditional-Access-Richtlinie explizit einen Gast- oder externen Benutzertyp einschließt. Die Prüfung liest die Include-Users-Zuweisung jeder aktivierten Richtlinie, sodass eine „Alle Benutzer"-Baseline nicht als Gastabdeckung zählt — genau diese Unterscheidung ist der Dreh- und Angelpunkt des restlichen Abschnitts.

Microsofts eigene Dokumentation besagt, dass die Zuweisungsoption Alle Benutzer in Conditional Access „alle Benutzer im Verzeichnis, einschließlich B2B-Gäste" einschließt — theoretisch deckt also eine einzelne Baseline-MFA-Richtlinie mit Scope auf Alle Benutzer bereits jeden Gast ab. In der Praxis erklärt dieselbe Dokumentation drei Wege, auf denen diese Abdeckung lautlos verschwindet.

Ausschlüsse überschreiben Einschlüsse, bedingungslos

Microsoft stellt es unmissverständlich fest: „Wenn Organisationen einen Benutzer oder eine Gruppe sowohl einschließen als auch ausschließen, wird der Benutzer bzw. die Gruppe von der Richtlinie ausgeschlossen. Die Ausschluss-Aktion überschreibt die Einschluss-Aktion in einer Richtlinie." Wird irgendeine Ausschlussgruppe, die zufällig Gäste enthält, an eine Richtlinie angehängt — aus welchem Grund auch immer, zu welchem Zeitpunkt auch immer —, schützt diese Richtlinie sie ab sofort nicht mehr, lautlos, ohne jede Warnung im Admin Center. Eine Richtlinie, die im Admin Center weiterhin als „Ein" angezeigt wird, während sie Ihre Gastpopulation still ausschließt, sieht auf den ersten Blick identisch aus wie die Report-Only-Richtlinien aus Conditional Access Report-Only-Modus, veraltete Ausnahmen: Richtlinien, die nicht wirklich durchgesetzt werden — beide vermitteln dem Tenant ein falsches Gefühl durchgesetzter Abdeckung.

Benutzerrisiko-Richtlinien lassen sich für externe Benutzer nicht auflösen — Microsofts eigene Empfehlung lautet daher, einen Ausschluss zu bauen

Benutzerrisiko erfordert ein Passwort-Reset, das der Ressourcen-Tenant bei einer externen Identität nicht durchführen kann, weshalb Microsofts dokumentierte Lösung lautet: „Sie können verhindern, dass risikobasierte Richtlinien externe Benutzer betreffen, indem Sie in Microsoft Entra ID eine Gruppe erstellen, die alle externen Benutzer Ihrer Organisation enthält. Fügen Sie diese Gruppe dann als Ausschluss zu Ihren auf Benutzerrisiko und Anmelderisiko basierenden Conditional-Access-Richtlinien hinzu." Beachten Sie, wie weit diese Empfehlung reicht: Nur die Benutzerrisiko-Richtlinie lässt sich für eine externe Identität nicht auflösen — Microsoft stellt ebenso deutlich klar, dass „die Anmelderisiko-Richtlinie durchgesetzt wird, wenn der externe Gastbenutzer die Grant-Kontrolle erfüllt." Wer die Anleitung wörtlich befolgt, wirft daher die funktionierende Anmelderisiko-Abdeckung zusammen mit der defekten Benutzerrisiko-Abdeckung über Bord. Diese Gruppe „alle externen Benutzer" ist, sobald sie aus einem legitimen Grund existiert, der nächstliegende Hebel, wenn beim nächsten Mal eine Gastanmeldung etwas kaputt macht — und sie gegen die MFA- oder Gerätekonformitäts-Baseline wiederzuverwenden (nicht nur gegen die Risikorichtlinie, für die sie gebaut wurde), ist der Weg, auf dem ein Tenant am Ende bei null Richtlinien landet, die Gastanmeldungen tatsächlich auswerten — obwohl „Alle Benutzer" sie technisch einschließt.

Scope auf Rollen oder Gruppen statt auf Alle Benutzer

Wird eine Richtlinie auf Verzeichnisrollen oder bestimmte Gruppen statt auf Alle Benutzer eingegrenzt, schließt das Gäste strukturell aus, sobald diese Rollen oder Gruppen aus internen HR- oder Rollendaten befüllt werden, die Gastobjekte nicht tragen.

Verwandte, nicht gastspezifische Baseline-Abdeckungslücken behandelt Conditional Access Baseline Richtlinienluecken Entra ID: Keine Richtlinie für Admins, alle Benutzer oder alle Apps, die breitere Prüfung von Ausschlüssen und Scope in Entra ID bedingter Zugriff Luecken: welche Fehlkonfigurationen reale Angriffsflaechen lassen.

Die Externen Zusammenarbeitseinstellungen, Die Weit Offen Ausgeliefert Werden

Zwei der sechs Lücken liegen vollständig in den externen Zusammenarbeitseinstellungen, und beide stehen standardmäßig am freizügigen Ende einer Skala mit vier bzw. drei Optionen.

GUEST_TO_GUEST_INVITE — Gäste können standardmäßig Gäste einladen

Die Gasteinladungseinstellungen haben vier Optionen, von „Jeder in der Organisation kann Gastbenutzer einladen, einschließlich Gästen und Nicht-Admins (am inklusivsten)" bis hinunter zu „Niemand in der Organisation kann Gastbenutzer einladen, einschließlich Admins (am restriktivsten)." Microsofts Dokumentation ist eindeutig, mit welcher ein Tenant startet: „Standardmäßig können alle Benutzer in Ihrer Organisation, einschließlich B2B-Kooperationsgastbenutzer, externe Benutzer zur B2B-Zusammenarbeit einladen." Das ist die inklusivste Option der Liste. Sofern ein Administrator sie nicht manuell eingeschränkt hat, hatte jeder Gast, den Sie je eingeladen haben, stets die stehende Berechtigung, weitere Gäste in Ihren Tenant einzuladen — keine Genehmigung, keine Benachrichtigung an Sie, kein Nachweis außer dem Audit-Log-Eintrag für die Einladung selbst. Azure Tenant-Härtung: Unsichere Defaults behandelt dies zusammen mit den anderen Zusammenarbeits-Standardwerten, die Tenants unangetastet lassen.

GUEST_DIRECTORY_VISIBILITY — der Standardwert ist nicht die restriktive Option

Der Gastbenutzerzugriff kennt drei Stufen: gleicher Zugriff wie Mitglieder, eingeschränkter Zugriff, oder beschränkt auf nur das eigene Profil. Microsoft markiert die mittlere Option als Standard: „Gastbenutzer haben eingeschränkten Zugriff auf Eigenschaften und Mitgliedschaften von Verzeichnisobjekten: (Standard) Diese Einstellung blockiert Gäste von bestimmten Verzeichnisaufgaben, wie dem Aufzählen von Benutzern, Gruppen oder anderen Verzeichnisressourcen. Gäste können die Mitgliedschaft aller nicht ausgeblendeten Gruppen sehen." Das Standardverhalten erlaubt jedem Gast, die Mitgliedschaft jeder nicht ausgeblendeten Gruppe in Ihrem Verzeichnis aufzuzählen — einschließlich, falls Sie dies nicht separat gesperrt haben, Gruppen mit rollenfähiger oder privilegierter Mitgliedschaft; siehe Entra ID: Verschachtelte privilegierte Gruppen, rollenfähige Gruppen und Gäste in Sicherheitsgruppen, was ein Gast allein aus dieser Sichtbarkeit lernen kann.

Beide Einstellungen befinden sich auf derselben Admin-Center-Seite (Externe Identitäten > Einstellungen für die externe Zusammenarbeit). Microsoft dokumentiert speziell für die Gastzugriffsebene eine Verzögerung bei der Verbreitung: Nach dem Speichern der restriktiven Einstellung „kann es bis zu 15 Minuten dauern, bis die Änderungen für Gastbenutzer wirksam werden."

Gäste, Die Niemand Verwaltet

GUEST_NO_EXPIRATION_POLICY — ein direkt eingeladener Gast hat überhaupt kein Ablaufdatum

Ein Gast, der direkt per E-Mail eingeladen wird, außerhalb der Berechtigungsverwaltung (Entitlement Management), ist das, was Microsofts eigene Terminologie ungoverned (nicht verwaltet) nennt. Microsofts Dokumentation zur Berechtigungsverwaltung zieht die Grenze präzise: Gäste, die über ein Zugriffspaket Zugriff anfordern, können in governed (verwaltet) umgewandelt werden, was bedeutet, dass „ihr Konto eine bestimmte Anzahl von Tagen, nachdem ihre letzte Zugriffspaket-Zuweisung abgelaufen ist, gelöscht oder deaktiviert wird." Aber „Gastbenutzer, die durch Einladung bereits in Ihrem Tenant existierten, sind ungoverned", und sobald ein ungoverned Gast seine letzte Zugriffspaket-Zuweisung verliert, „bleiben sie unbegrenzt im Tenant." Ein direkt eingeladener Gast, der nie an ein Zugriffspaket angehängt war, hat überhaupt keinen Ablaufmechanismus — keinen langen Standardwert, keinen kurzen, gar keinen. Er besteht fort, bis ein Mensch ihn bemerkt und von Hand entfernt, oder bis ein Administrator nachträglich einen Lifecycle-Prozess baut, der ihn erfasst.

GUEST_NEVER_SIGNED_IN — unsichtbar für eine Standard-Zugriffsüberprüfung, bis das Inaktivitätsfenster verstrichen ist

Entra IDs Bericht über inaktive Gäste (ID Governance > Dashboard > Gastzugriffs-Governance) ist das Werkzeug, das genau dafür gebaut wurde, und er behandelt nie angemeldete Gäste als eigene Kategorie: Der Bericht trennt explizit „Gäste, die sich nie angemeldet haben, von solchen, die sich mindestens einmal angemeldet haben", und für die Gruppe der nie Angemeldeten „werden die inaktiven Tage anhand des Erstellungsdatums berechnet" statt anhand der letzten Anmeldung, da es keine gibt. Der Standard-Inaktivitätsschwellenwert liegt bei 90 Tagen. Operativ zählen zwei Haken: Dieser Bericht erfordert eine Entra-ID-Governance- oder Entra-Suite-Lizenz, sodass Tenants ohne diese Lizenz ihn überhaupt nicht öffnen können, und Zugriffsüberprüfungen, die zum Entfernen inaktiver Gäste gebaut wurden, überspringen bewusst jeden Gast, der jünger ist als das konfigurierte Inaktivitätsfenster — „dies stellt sicher, dass sich Gäste einmal anmelden können, bevor sie entfernt werden" —, sodass ein frischer, nie angemeldeter Gast so lange für die Bereinigung unsichtbar bleibt, wie dieses Fenster läuft.

Anwendungszugriff, Dem Gäste Nie Zugewiesen Wurden

GUEST_APP_ACCESS_UNRESTRICTED [MEDIUM] — Microsoft nennt den Standardwert unmissverständlich, in seiner Anleitung zur Einschränkung einer App auf eine bestimmte Benutzergruppe: „Anwendungen, die in einem Microsoft-Entra-Tenant registriert sind, stehen standardmäßig allen Benutzern des Tenants zur Verfügung, die sich erfolgreich authentifizieren." Die Kontrolle, die dies ändert, ist Benutzerzuweisung erforderlich, und sie ist pro Anwendung Opt-in, nicht standardmäßig aktiviert. Sobald ein Gast eingeladen wurde — für ein Projekt, ein geteiltes Dokument, ein Meeting — ist er „ein Benutzer des Tenants" für jede andere Anwendung, die die Zuweisung nicht aktiviert hat, unabhängig davon, ob das beabsichtigt war.

Warum diese Lücke eine Portalprüfung übersteht

Die Lücke ist bei einer Portalprüfung leicht zu übersehen, wegen der Art, wie sie versagt: „Wenn keine Benutzerzuweisung erforderlich ist, sehen nicht zugewiesene Benutzer die App nicht in ihren Meine Apps, können sich aber dennoch bei der Anwendung selbst anmelden (auch bekannt als SP-initiierte Anmeldung) oder die Benutzerzugriffs-URL verwenden." Eine App, die abgesichert wirkt — weil kein Gast in ihrer Liste zugewiesener Benutzer auftaucht und kein Gast sie auf seiner Meine-Apps-Seite sieht —, kann trotzdem für jeden Gast erreichbar sein, der den direkten Anmeldelink hat, was oft schlicht die normale Login-URL der App ist. Zuweisungsstatus und Sichtbarkeit sind nicht dasselbe, und nur die Zuweisung kontrolliert den Zugriff tatsächlich.

Gäste mit erhöhten Verzeichnisrollen verschärfen genau diese Lücke; siehe Entra Gast-Adminrolle Cross-Tenant B2B Trust: Wie externe Benutzer Globaler Administrator werden dafür, was passiert, wenn ein unterzugewiesener Gast sich zusätzlich als Inhaber administrativer Berechtigungen herausstellt.

Erkennung

Keine dieser sechs Lücken zeigt sich als Angriffssignatur — es sind Konfigurationszustände, die Sie direkt abfragen müssen.

Eine Überprüfung auf Ihre Gastpopulation eingrenzen

Um eine Zugriffsüberprüfung ausschließlich auf Ihre externe Population einzugrenzen, lautet die dynamische Gruppenregel, die Microsoft als Beispiel angibt:

(user.userType -eq "Guest") and (user.mail -contains "@contoso.com") and (user.accountEnabled -eq true)

Tauschen Sie den Domänenfilter gegen Ihren eigenen aus, oder lassen Sie ihn weg, um alle Gasttypen zu erfassen.

Behebung (Remediation)

1. Gasteinladungen einschränken

Bewegen Sie sich in den Einstellungen für die externe Zusammenarbeit vom Standardwert „Jeder... einschließlich Gästen" weg. Wenn eine Handvoll Personen tatsächlich Einladungsrechte braucht, ohne eine volle Admin-Rolle, weisen Sie ihnen stattdessen die Rolle Guest Inviter zu, statt Einladungen für alle offen zu lassen:

Import-Module Microsoft.Graph.Identity.DirectoryManagement

$roleName = "Guest Inviter"
$role = Get-MgDirectoryRole | where {$_.DisplayName -eq $roleName}
$userId = "<user object ID or UPN>"

$DirObject = @{
  "@odata.id" = "https://graph.microsoft.com/v1.0/directoryObjects/$userId"
  }

New-MgDirectoryRoleMemberByRef -DirectoryRoleId $role.Id -BodyParameter $DirObject

Ein Haken, bevor Sie es ausführen: Get-MgDirectoryRole „gibt nur Rollen zurück, die aktiviert wurden", und „nicht alle integrierten Rollen sind anfänglich aktiviert." In einem Tenant, in dem Guest Inviter noch nie über das Admin Center zugewiesen wurde, kommt $role leer zurück, und die letzte Zeile schlägt fehl. Weisen Sie die Rolle einmal im Portal zu — was sie implizit aktiviert — oder aktivieren Sie sie zuerst mit der Activate-directoryRole-API.

2. Sichtbarkeit des Verzeichnisses für Gäste verschärfen

Wechseln Sie zu „beschränkt auf Eigenschaften und Mitgliedschaften der eigenen Verzeichnisobjekte", sofern nicht ein bestimmtes Zusammenarbeitsszenario tatsächlich erfordert, dass Gäste Gruppenmitgliedschaften durchsuchen können.

3. Geben Sie Gästen eine dedizierte, aktivierte Conditional-Access-Richtlinie

Zielen Sie explizit auf „Gast- oder externe Benutzer" (alle von Ihnen verwendeten Subtypen), mit mindestens MFA als Anforderung — verlassen Sie sich nicht allein auf eine „Alle Benutzer"-Baseline. Prüfen Sie anschließend die Ausschlussliste jeder bestehenden aktivierten Richtlinie auf eine Gruppe „Gast- oder externe Benutzer" oder „alle externen Benutzer", und bestätigen Sie für jede, dass sie beabsichtigt und weiterhin nötig ist — nicht ein Risikorichtlinien-Ausschluss, der in Ihre MFA-Baseline durchgesickert ist.

4. Gäste in verwaltete (governed) Zugriffspakete umwandeln

Tun Sie dies überall dort, wo ein Gast einem definierten Projekt oder Engagement zugeordnet ist, damit die Lifecycle-Richtlinie tatsächlich ein Ablaufdatum anhängt. Bauen Sie für Gäste, die nie durch die Berechtigungsverwaltung laufen werden, eine wiederkehrende Zugriffsüberprüfung gegen die oben genannte dynamische Gastgruppe, mit einem Inaktivitätsschwellenwert und einer automatisch angewendeten Entscheidung „Blockieren, dann Entfernen".

5. Bericht über inaktive Gäste aktivieren

Dies erfordert eine Entra-ID-Governance-/Entra-Suite-Lizenz. Prüfen Sie die Kategorie der nie Angemeldeten nach einem festen Zeitplan — diese Konten sind für eine Standard-Zugriffsüberprüfung unsichtbar, bis sie Ihr Inaktivitätsfenster durchlaufen haben.

6. Zuweisung bei Unternehmensanwendungen erfordern

Setzen Sie „Zuweisung erforderlich" auf Ja bei jeder Unternehmensanwendung, die nicht für den gesamten Tenant offen sein sollte, und weisen Sie dann explizit die Benutzer oder Gruppen zu — nicht standardmäßig Gäste —, die sie benötigen. Überprüfen Sie erneut Apps, die außerhalb Ihres Standard-Onboarding-Prozesses hinzugefügt wurden; SAML-SSO-Apps, Application-Proxy-Apps mit Microsoft-Entra-Vorauthentifizierung und OAuth-2.0-/OpenID-Connect-Apps, denen ein Benutzer oder Administrator zugestimmt hat, unterstützen diese Kontrolle alle.

Wie EtcSec Dies Erkennt

EtcSec prüft jedes Azure-/Entra-Audit gegen alle sechs dieser Befunde: GUEST_NO_CA_POLICY, GUEST_TO_GUEST_INVITE, GUEST_DIRECTORY_VISIBILITY, GUEST_NO_EXPIRATION_POLICY, GUEST_NEVER_SIGNED_IN und GUEST_APP_ACCESS_UNRESTRICTED. Sie funktionieren nicht alle auf dieselbe Weise, und dieser Unterschied ist wichtig, wenn Sie entscheiden, was ein sauberes Ergebnis tatsächlich beweist.

Drei werden gegen den tatsächlichen Zustand Ihres Tenants ausgewertet, sodass sich ihr Ergebnis ändert, wenn Sie die zugrunde liegende Einstellung beheben. GUEST_NO_CA_POLICY liest die Include-Users-Zuweisung jeder aktivierten Conditional-Access-Richtlinie. GUEST_TO_GUEST_INVITE liest die Gasteinladungsrichtlinie des Tenants. GUEST_NEVER_SIGNED_IN zählt Gastkonten ohne interaktive oder nicht-interaktive Anmeldung auf und meldet die Anzahl. Diese drei sind es, die Ihnen sagen, ob die Korrektur vom letzten Quartal noch besteht, nachdem der nächste Administrator die externen Zusammenarbeitseinstellungen oder Conditional Access angefasst hat.

Die anderen drei — GUEST_DIRECTORY_VISIBILITY, GUEST_NO_EXPIRATION_POLICY und GUEST_APP_ACCESS_UNRESTRICTED — werden bei jedem Azure-Audit als Hinweise auf Tenant-Ebene ausgegeben, statt von einem einzelnen Tenant-Flag umgeschaltet zu werden. Lesen Sie sie als ständige Aufforderung, diese Kontrolle im Portal erneut zu verifizieren — nicht als Beleg dafür, dass sie derzeit falsch konfiguriert ist.

Primärquellen

• Einstellungen für die externe Zusammenarbeit konfigurieren
• Conditional Access: Benutzer, Gruppen, Agents und Workload-Identitäten
• Authentifizierung und Conditional Access für B2B-Benutzer
• Gastbenutzer-Lifecycle in der Berechtigungsverwaltung umwandeln
• Veraltete Gastkonten überwachen und bereinigen
• Zugriff auf Apps verwalten
• Eine Microsoft-Entra-App auf eine Benutzergruppe einschränken
• Zugriffsberechtigungen von Gastbenutzern einschränken
• directoryRoles auflisten (Microsoft Graph)
• Aktivitätsprotokolle in Microsoft Entra ID anpassen und filtern