Externe Zusammenarbeit

Ein Gast ist ein Objekt bei dir, ein Konto woanders

Bei der Zusammenarbeit über Organisationsgrenzen hinweg entsteht in deinem Tenant ein Benutzerobjekt — aber kein Anmeldekonto. Die Person meldet sich weiterhin bei ihrer Organisation an; deine Seite hält nur die Hülle, an der Berechtigungen und Mitgliedschaften hängen.

Das Objekt kennst du aus dem ersten Modul: Der Anmeldename trägt die Form john_contoso.com#EXT#@fabrikam.onmicrosoft.com, und userType steht auf Guest. Wichtig ist die Folge daraus: Deine Kennwortrichtlinien, deine Anmeldeverfahren und dein Kontolebenszyklus greifen für diese Person nicht. Sie werden in ihrer Heimatorganisation entschieden.

B2B-Zusammenarbeit — Ein Verfahren, bei dem externe Personen mit ihren eigenen Anmeldedaten auf Ressourcen deiner Organisation zugreifen. Die Authentifizierung bleibt bei ihrer Organisation, die Autorisierung liegt bei deiner.

Zwei Ebenen von Einstellungen, und sie werden ständig verwechselt

Für externe Zusammenarbeit gibt es zwei Stellschrauben an verschiedenen Orten. Wer an der falschen dreht, wundert sich, dass nichts passiert.

Organisationsübergreifende Zugriffseinstellungen

Steuern die Zusammenarbeit mit anderen Microsoft-Entra-Organisationen — eingehend, ausgehend und mit Vertrauensstellungen für fremde Anmelde- und Gerätenachweise.

Einstellungen für externe Zusammenarbeit

Steuern den Rest: wer einladen darf, was ein Gast im Verzeichnis sieht, welche Domänen erlaubt oder gesperrt sind, und die Selbstregistrierung.

Die Trennlinie verläuft entlang der Frage, ob die Gegenseite selbst ein Entra-Tenant ist. Eine Partnerfirma mit eigenem Tenant fällt unter die erste Ebene; eine Einzelperson mit einer Mailadresse eines beliebigen Anbieters unter die zweite.

Die Standardwerte, die man kennen muss

Vieles an der externen Zusammenarbeit ist bereits eingeschaltet, bevor jemand eine Entscheidung getroffen hat. Diese vier Voreinstellungen stehen in der Dokumentation und bestimmen den Ausgangszustand jedes Tenants:

• B2B-Zusammenarbeit ist aktiviert. Alle internen Benutzer können externe Gäste einladen und selbst als Gast eingeladen werden.
• B2B Direct Connect ist gesperrt — eingehend wie ausgehend, für alle fremden Tenants.
• Fremde Anmelde- und Gerätenachweise werden nicht vertraut. Wer bei sich zu Hause eine mehrstufige Anmeldung bestanden hat, muss sie bei dir erneut bestehen.
• Es sind keine Organisationen einzeln eingetragen. Damit gilt für alle fremden Entra-Organisationen dieselbe Voreinstellung.

Die erste Zeile ist die folgenreichste. Zusammenarbeit ist der Standardzustand, nicht die Ausnahme — wer eine Organisation übernimmt, übernimmt einen Tenant, in dem alle Beschäftigten einladen dürfen, ohne dass jemand das entschieden hätte.

Standard oder organisationsspezifisch

Die organisationsübergreifenden Einstellungen gibt es in zwei Ausprägungen. Die Standardeinstellungen gelten für alle fremden Entra-Organisationen. Daneben lassen sich einzelne Organisationen mit eigenen Einstellungen eintragen — und für diese gilt laut Dokumentation: Organisationsspezifische Einstellungen haben Vorrang vor den Standardeinstellungen.

Die Zahl der eingetragenen Organisationen ist dabei nicht begrenzt. Das ermöglicht ein Vorgehen, das sich bewährt: den Standard eng fassen und für die wenigen Partner, mit denen tatsächlich zusammengearbeitet wird, gezielt öffnen.

Vertrauensstellungen: fremde Nachweise akzeptieren

Die interessanteste Einstellung der ersten Ebene sind die eingehenden Vertrauensstellungen. Sie bestimmen, ob deine Zugriffsregeln Nachweise anerkennen, die eine Person in ihrer Heimatorganisation bereits erbracht hat — mehrstufige Anmeldung, konformes Gerät, hybride Einbindung.

Die Dokumentation formuliert die Wirkung genau: Vertraust du der mehrstufigen Anmeldung, gelten deine Regeln weiterhin für externe Personen — aber wer sie zu Hause schon bestanden hat, muss sie bei dir nicht erneut bestehen. Die Anforderung bleibt also, nur die Doppelung entfällt.

Das ist eine echte Abwägung und keine Formalie. Ohne Vertrauen bestehen externe Personen die Prüfung zweimal, was Reibung erzeugt und regelmäßig scheitert — denn sie müssen dafür ein Verfahren in deinem Tenant registrieren. Mit Vertrauen übernimmst du die Qualität der Anmeldeverfahren einer fremden Organisation, über die du nichts bestimmst.

Über Microsoft Graph sind die drei Vertrauensstellungen einzeln schaltbar und heißen dort isMfaAccepted, isCompliantDeviceAccepted und isHybridAzureADJoinedDeviceAccepted. Sie liegen unter inboundTrust im partnerspezifischen Eintrag, neben b2bCollaborationInbound und b2bDirectConnectInbound, und der Partner selbst wird über seine tenantId bezeichnet.

Dass es drei getrennte Schalter sind, ist eine nützliche Feinheit. Man kann der mehrstufigen Anmeldung einer Partnerorganisation vertrauen und ihren Gerätenachweisen trotzdem nicht — was meist die richtige Kombination ist, denn über die Geräteverwaltung einer fremden Organisation weiß man in aller Regel noch weniger als über ihre Anmeldeverfahren.

Die dokumentierte Sackgasse

An dieser Stelle steht in der Dokumentation ein Hinweis, den man einmal gelesen haben muss, weil er einen kompletten Stillstand erklärt.

Wenn du der mehrstufigen Anmeldung externer Personen vertraust und gleichzeitig eine Registrierungsrichtlinie des Identitätsschutzes für die mehrstufige Anmeldung greift, können externe Personen die Anforderungen für den Zugriff laut Dokumentation nicht mehr erfüllen. Die Empfehlung lautet, externe Benutzer von dieser Registrierungsrichtlinie auszunehmen.

Die Ursache ist ein Widerspruch zwischen zwei Anforderungen: Die eine sagt, die Person müsse in deinem Tenant ein Verfahren registrieren; die andere sagt, ihr zu Hause erbrachter Nachweis genüge. Beide zusammen ergeben eine Bedingung, die niemand erfüllen kann — die Registrierung setzt den Zugriff voraus, den sie selbst verhindert.

Solche Sackgassen erkennt man am Beschwerdebild: Es trifft alle Personen einer Gruppe gleichzeitig und vollständig, nicht einzelne mit besonderen Umständen. Wo niemand aus einer klar abgrenzbaren Gruppe hineinkommt und alle dieselbe Aufforderung sehen, an der sie scheitern, lohnt die Frage nach zwei sich widersprechenden Anforderungen mehr als die Suche nach einem Defekt.

Wer einladen darf — und der überraschende Standard

In den Einstellungen für externe Zusammenarbeit steht, wer Gäste einladen darf. Vier Stufen sind wählbar, und die Voreinstellung ist die offenste.

Alle, einschließlich Gästen

Die Voreinstellung. Auch eingeladene Gäste dürfen weitere Gäste einladen.

Mitglieder und bestimmte Verwaltungsrollen

Interne Personen und benannte Rollen; Gäste nicht mehr.

Nur bestimmte Verwaltungsrollen

Nur User Administrator oder Guest Inviter.

Niemand, auch keine Verwaltenden

Die restriktivste Stufe.

Die erste Zeile ist der Befund. Standardmäßig darf laut Dokumentation jeder Benutzer der Organisation einschließlich der B2B-Gäste externe Personen einladen. Ein Gast kann also einen weiteren Gast einholen, den niemand in deiner Organisation je gesehen hat — und dieser wiederum den nächsten.

Was ein Gast im Verzeichnis sieht

Die zweite folgenreiche Einstellung betrifft nicht den Zugriff auf Ressourcen, sondern die Sicht auf das Verzeichnis selbst. Drei Stufen stehen zur Wahl.

Gleiche Rechte wie Mitglieder

Die offenste Stufe: Gäste sehen Verzeichnisdaten wie interne Personen.

Eingeschränkter Zugriff (Voreinstellung)

Gäste können Benutzer, Gruppen und andere Verzeichnisressourcen nicht aufzählen — sehen aber die Mitgliedschaft aller nicht verborgenen Gruppen.

Nur eigene Objekte

Die restriktivste Stufe: Gäste sehen ausschließlich ihr eigenes Profil, keine anderen Personen, keine Gruppen, keine Mitgliedschaften.

Der Zusatz bei der Voreinstellung verdient Aufmerksamkeit. Aufzählen ist gesperrt, aber die Mitgliedschaft nicht verborgener Gruppen bleibt sichtbar. Wer Gruppennamen sprechend wählt — etwa nach Projekten, Kunden oder anstehenden Vorhaben —, gibt damit unter Umständen mehr preis als beabsichtigt.

Daneben stehen die Zusammenarbeitsbeschränkungen, mit denen sich Einladungen an bestimmte Domänen ausdrücklich erlauben oder sperren lassen. Beides ist möglich, aber nicht gleichzeitig: Man führt entweder eine Erlaubnisliste oder eine Sperrliste. Die Erlaubnisliste ist die strengere Wahl und die einzige, die verlässlich wirkt — eine Sperrliste kennt immer nur die Domänen, an die schon jemand gedacht hat.

Ergänzend gibt es die Selbstregistrierung über Benutzerflows: Für selbst entwickelte Anwendungen können sich Personen ein Gastkonto selbst anlegen. Das ist für offene Angebote gedacht und sollte in einem Tenant, der nur mit benannten Partnern zusammenarbeitet, abgeschaltet bleiben — sonst entsteht eine zweite, unbeaufsichtigte Quelle für Gastobjekte.

B2B Direct Connect: beide Seiten müssen wollen

Neben der Einladung als Gast gibt es einen zweiten Weg, bei dem gar kein Objekt in deinem Verzeichnis entsteht. B2B Direct Connect stellt eine gegenseitige Vertrauensbeziehung zwischen zwei Entra-Organisationen her; die Personen der Gegenseite greifen zu, ohne bei dir als Gast geführt zu werden.

Zwei Eigenschaften sind entscheidend. Erstens ist das Verfahren standardmäßig gesperrt — in beide Richtungen, für alle fremden Tenants. Zweitens muss es laut Dokumentation von beiden Organisationen eingerichtet werden: Jede setzt ihre eingehenden und ausgehenden Einstellungen, und erst wenn beide zustimmen, funktioniert es.

Eine dritte Einstellung gehört in dieselbe Familie: die automatische Einlösung von Einladungen, in Graph als automaticUserConsentSettings geführt. Ist sie gesetzt, entfällt für die Beteiligten die Zustimmungsabfrage beim ersten Zugriff. Laut Dokumentation sind die zugehörigen Werte für eingehend und ausgehend andernfalls leer und erben aus den Standardeinstellungen, die stets false lauten — die Abfrage erscheint also, solange niemand sie ausdrücklich abschaltet.

Das ist bequem und verdient trotzdem eine bewusste Entscheidung: Die Zustimmungsabfrage ist der einzige Moment, in dem eine Person sieht, dass sie gerade Zugang zu einer fremden Organisation erhält. Wer sie abschaltet, gewinnt einen glatteren Ablauf und verliert den einzigen Hinweis an die Betroffenen.

Der Lebenszyklus, den niemand beendet

Gäste entstehen aus einem Anlass — ein Projekt, eine Prüfung, eine befristete Zusammenarbeit. Der Anlass endet, das Objekt bleibt. Das ist der strukturelle Unterschied zu internen Konten: Für die gibt es einen Austrittsprozess, für Gäste selten.

Verschärfend kommt hinzu, dass die Heimatorganisation eines Gasts sein Konto deaktivieren kann, ohne dass dein Tenant davon erfährt. Das Objekt bei dir bleibt bestehen, samt Berechtigungen — es kann sich nur niemand mehr damit anmelden. Bis jemand in der fremden Organisation den Namen erneut vergibt.

• Beim Einladen ein Ende mitdenken: Wofür, wie lange, und wer bemerkt das Ende?
• Das Attribut für die einladende Person nutzen — es beantwortet später die Frage, wen man fragen kann.
• Wiederkehrende Überprüfungen der Gastbestände ansetzen; das Werkzeug dafür steht im Modul zur Governance.
• Gäste ohne Anmeldung seit längerer Zeit als Erstes prüfen — sie sind der günstigste Aufräumfall.

Zwei Attribute helfen dabei, die aus dem ersten Modul bekannt sind. externalUserState zeigt mit dem Wert Pending Acceptance, dass eine Einladung nie angenommen wurde — solche Objekte sind der einfachste Aufräumfall, weil nie jemand damit gearbeitet hat. Und das Attribut Sponsor trägt standardmäßig die einladende Person; es ist die Antwort auf die Frage, wen man fragen kann, wenn der Anlass unklar geworden ist.

Durchgerechnet: eine Partnerfirma anbinden

Der Preis ist Vorlauf: Vier Einstellungen an zwei Orten dauern länger als eine Einladung. Und die Vertrauensstellung ist eine Entscheidung, die man verantworten muss — sie übernimmt das Anmeldeniveau einer fremden Organisation. Wer das nicht verantworten will, lässt sie weg und nimmt die doppelte Prüfung in Kauf; das ist eine vertretbare Wahl, solange sie eine Wahl ist.

Die Reihenfolge, die alles zusammenhält

Externe Zusammenarbeit ist der Bereich mit der größten Lücke zwischen Voreinstellung und Absicht. Fast alles ist offen, bis jemand es schließt, und das Objekt, das dabei entsteht, hat seinen Lebenszyklus in einer Organisation, über die du nichts bestimmst.