Effiziente Kollaboration unter Einhaltung von Sicherheitsstandards ist oft schwierig, gerade wenn es um das Endbenutzererlebnis geht. B2B ist gemacht für Zusammenarbeit in der Cloud. Die Cloud selbst ist aber ein gefährlicher Ort. Passwörter sollten hier längst nicht mehr als einziges Credential akzeptiert werden und Multifaktor-Authentifizierung (MFA) eigentlich Standard sein. In diesem Kontext ist es daher nicht optimal, dass der MFA-Status bisher nur innerhalb der Tenant-Grenzen gültig ist und anderen Tenants nicht vertraut wird. Haben sich zudem beide Geschäftspartner modernem Arbeiten und Zero-Trust-Ansätzen verschrieben, wird es noch schwieriger: Auch der Gerätestatus lässt sich nicht übertragen.

Chancen für Verbesserungen ergeben sich mit den "Cross-tenant access settings" (xTAS). Die Funktion soll Kollaboration über Tenant-Grenzen hinaus vollumfänglich steuern und Unternehmen die Kontrolle über eingehende und ausgehende Kollaboration erlauben, und zwar anhand der Definition mandantenweiter sowie partnerspezifischer Regeln.

Diese Policies beschreiben, wie genau Kollaboration mit Partnern aussehen soll. Sie bestimmen für Ihr Azure AD, für Ihre Ressourcen, Ihre Apps und Benutzer, welche Partnerunternehmen Sie unter welchen Bedingungen für Kollaboration zulassen wollen oder zu welchen Partnerunternehmen Ihre Mitarbeiter eingeladen werden dürfen. Beides war bisher nur eingeschränkt möglich. Welche Unternehmen zur Kollaboration erwünscht waren, ließ sich entweder frei, über eine Erlaubt-Liste oder eine Verboten-Liste bestimmen. Granularer ging es nicht. Wer aus dem eigenen Unternehmen Gast in anderen Unternehmen sein durfte, konnten Sie bisher gar nicht mit den B2B-Einstellungen steuern.

xTAS ändert das: In beide Vertrauensrichtungen können Sie pro Partnerunternehmen lenken, ob Kollaboration erwünscht ist – und das sogar auf Benutzer- und Gruppenebene. Soll etwa einzig und allein ein Projektteam mit einem Lieferanten im Office 365 des Lieferanten arbeiten können, der Rest der Organisation aber nicht, so bestimmen Sie das einfach anhand von Gruppenmitgliedschaften. Das schafft Granularität und hilft dabei, die Verwaltung in die Hände der Projektteams abzugeben, damit sie selbst die Gruppe steuern können.

Das Regelwerk erstellen Sie dabei auf zwei Ebenen. Zunächst definieren Sie eine unternehmensweite Standardrichtlinie, die Zusammenarbeit steuert: Dürfen eigene Mitarbeiter überhaupt ausgehende Kollaboration genießen oder nicht? Sollen generell andere Unternehmen eingeladen werden dürfen? Wenn Sie die Unternehmensrichtlinie erstellt haben, gehen Sie ins Detail und beschreiben Kollaboration mit einzelnen Partnerunternehmen: Welcher der eigenen Mitarbeiter, gesteuert durch Gruppenmitgliedschaft, darf mit Fabrikam zusammenarbeiten? Welche Projektteams dürfen mit Contoso kollaborieren – und wie soll Contoso im eigenen Tenant agieren dürfen? Die individuelle Konfiguration pro Partnerunternehmen regelt die Kollaboration feingranular. Sie steuern dabei immer zwei Aspekte: den eingehenden und den ausgehenden Zugriff. Existiert für einen Partner keine Regel, greift die Standardregel.

Gerade wenn enge Zusammenarbeit mit ausgewählten Partnern die Norm darstellt oder andere Mandanten der gleichen Firmengruppe enger angebunden werden müssen, wollen Sie vermutlich auch einige Sicherheitskonfigurationen feinsteuern. Vertrauen Sie Kontenverwaltung, MFA und Credentials sowie der Geräteverwaltung des Partners, können Sie den MFA-Status eines Benutzers und die Gerätegesundheit aus Intune übernehmen und in Ihren Regeln für Conditional Access (CA) akzeptieren. Sie vertrauen dann nicht nur den Benutzern, sondern auch den Sicherheitseinstellungen und Prozessen des anderen Unternehmens.

Gerade wenn vertragliche Abstimmungen vorsehen, dass die jeweiligen IT-Prozesse offengelegt sind und gewissen Standards entsprechen, sollten Sie diese wahrscheinlich in den Kollaborationseinstellungen abbilden. Auch für die Mitarbeiter hat das einen Vorteil: Ist MFA zwingend erforderlich, müssen Mitarbeiter nicht doppelt MFA einrichten und durchführen, wenn sie über Tenant-Grenzen hinweg arbeiten. Ihre eigenen CA-Regeln können dadurch ebenfalls einfacher ausfallen: Sie müssen dann geringere MFA- oder Geräteausnahmen für Partner definieren und pflegen.

Per Default ist bei xTAS freie Zusammenarbeit erlaubt und eigene Mitarbeiter können woanders eingeladen werden. Weitergehende Richtlinien erstellen Sie im Azure-Portal unter "Azure Active Directory / External Identities / Cross-tenant access settings". Hier sehen Sie die beiden Reiter "Organizational settings" für die Detailkonfiguration für Partnerunternehmen und "Default settings" für die Standardregeln. Letztere vermitteln Ihnen mit der Unterteilung in "Inbound access settings" und "Outbound access settings" einen Überblick zu den Grundeinstellungen. Mit einem Klick auf "Edit" können Sie die Kollaboration komplett verbieten oder feingranular erlauben, indem Sie einzelne Benutzer oder Gruppen dafür freistellen.

In "Organizational Settings" konfigurieren Sie dieselben Einstellungen, jedoch für einen Partner. Ist noch keine Einstellung hinterlegt, starten Sie mit dem "Add Organization" den Erstellungsprozess. Am rechten Bildschirmrand geben Sie nun den AAD-Mandanten Ihres Geschäftspartners an: Hier reicht der Domänenname, also etwa "contoso.com". Haben Sie den richtigen Mandanten ausgewählt, erscheint dieser anschließend im Hauptfenster. Dabei gelten zunächst die Einstellungen "inherited from default" – sowohl für eingehenden als auch ausgehenden Zugriff.

Mit dem Klick auf einen der beiden Links wechseln Sie zur Seite für die Detaileinstellungen. Mit "Customize settings" definieren Sie, wer eingehend und ausgehend Kollaboration betreiben darf. Für die Inbound-Settings ist die Voreinstellung "All external users and groups", wonach alle Mitarbeiter bei Contoso bei Ihnen mitarbeiten dürfen und Zugriff erhalten – wenn sie denn von einem Ihrer Mitarbeiter eingeladen wurden. Ist dies nicht gewünscht und Sie wollen nur einer ganz bestimmten Gruppe von Contoso-Kollegen Kollaboration gewähren, unabhängig von Einladungen, nutzen Sie "Select external users and groups". Sie müssen dann mit Contoso vereinbaren, welche Benutzer und Gruppen erlaubt sein sollen. Die Objekt-IDs der erlaubten Collaboration-Partner aus dem Contoso-Tenant tragen Sie hier in eine Liste ein. Selbiges, nur umgekehrt, steht Ihnen für Outbound-Einstellungen zur Verfügung. Hier hinterlegen Sie die Objekt-IDs der Benutzer und Gruppen aus Ihrem eigenen Mandanten, die im Contoso-Tenant mitarbeiten dürfen.

Für eingehenden Zugriff finden Sie in "Trust settings" für Contoso die Einstellungen für MFA- und Gerätedaten. Haben Sie Gewissheit, dass das Partnerunternehmen Identitätsverifikation und Geräteverwaltung gemäß Ihrer Ansprüche durchführt, vertrauen Sie per "Customize settings" und der Auswahl der jeweiligen Option den Daten aus Contosos Mandanten: "Trust multi-factor authentication from Azure AD tenant", "Trust compliant devices" und "Trust hybrid Azure AD joined devices" stehen hier zur Auswahl. Sie können die Einstellungen beliebig mischen, gemäß dem Maß an Vertrauen, das Sie in die Verwaltung von Contosos IT haben. Die Auswahl eines dieser Settings führt dazu, dass Conditional-Access-Regeln in Ihrem Tenant die erfolgreiche Prüfung bedingen – vorausgesetzt, der Contoso-Tenant hat MFA und Geräteprüfung ausgeführt.

Um im Bereich B2B-Collaboration mittels xTAS automatisieren zu können, müssen Sie die Vertrauenseinstellungen für B2B für eingehende und ausgehende Kollaboration definieren. Dies funktioniert über die Graph-API. Die Einstellungen sind im "crossTenantAccessPolicy"-Objekt zu finden. Das Hauptobjekt enthält allerdings nur Steuerdaten. Die Tenant-weiten Settings beherbergt das Unterobjekt "default", die partnerspezifischen Einstellungen bringen Sie unter "partners" in Erfahrung:

Die erste Informationsbeschaffung, bevor Sie mit der Automatisierung starten, können Sie wie gewohnt mit PostMan oder dem Graph Explorer [1] unternehmen. Das erlaubt Ihnen, die API-Struktur zu erkunden. Eine genauere Beschreibung von Microsoft zum Thema "Cross-tenant Access Settings API" gibt es unter [2].

Sämtliche Settings aus der Administrationsoberfläche spiegeln sich auch in der API: "inboundTrust" für die MFA- und Geräteeinstellungen, "b2bCollaboration-Outbound" und "b2bCollaborationInbound" für die Grundkonfiguration zu eingehender und ausgehender Kollaboration. Wer nur an Detailaspekten der Standard-Settings interessiert ist, kann mit "$select" wie gewohnt die Details abrufen:

Die Übersicht aller partnerspezifischen Einstellungen finden Sie via:

Die Auflistung zeigt alle definierten Partner und deren Sonderoptionen. Ist eine Einstellung mit "null" gekennzeichnet, bedeutet das, dass die Tenant-Default-Settings aus dem "default"-Objekt greifen. Sind Sie an einem bestimmten Partner interessiert, fragen Sie den Graphen mit der Tenant-ID an:

Das Resultat könnte dann so aussehen wie im Kasten "Tenant-Settings über Graph-API abfragen".

Um einzelne Einstellungen, etwa in den MFA- und Geräteeinstellungen, zu ändern, wenden Sie die PATCH-Funktion auf das inboudTrust-Objekt an:

Als Payload im Request-Body übergeben Sie dem Graphen die Details zur Änderung. Selbst wenn Sie nur eine der drei Optionen in "inboundTrust" ändern wollen, müssen Sie alle Einstellungen nochmals beschreiben, also den Wunschzustand des inboundTrust-Objekts:

Hat Ihr Unternehmen sehr viele Partner und wollen Sie die Auflösung von einer Domäne wie contoso.com zur Tenant-ID, die für die B2B-Einstellungen in Graph erforderlich ist, vereinfachen, fragen Sie Azure AD und dessen OpenIDConnect-Configuration-Endpunkt um Hilfe. Der Standard schreibt vor, dass Metadaten zu Domänen verfügbar sein müssen. Wenn Sie also

im Browser oder innerhalb eines Skripts abrufen und die Antwort parsen, können Sie die Tenant-ID bequem aus der Antwort herauslesen.

Haben Sie erst einmal Überblick zu den möglichen Einstellungen gewonnen, müssen Sie nur noch entscheiden, für welche Geschäftspartner Sie eine Detaileinstellung definieren wollen und wie diese aussehen soll. Eine Übersicht zur bestehenden Kollaboration mit Partnerunternehmen stellt das Azure AD in einem Workbook bereit, das die Zusammenarbeit in eingehende und ausgehende Kollaboration unterteilt.

Das Workbook ist unter "Azure Active Directory / Workbooks" bei "Cross-tenant access activity" zu finden. Als Voraussetzung für sinnvolle Einblicke und Daten müssen Sie die Sign-in-Logs aus Azure AD in einen Log-Analytics-Workspace exportieren. Dann kann das Workbook auch auf Daten zurückgreifen, die länger zurückliegen als die letzten 30 Tage [3]. Sie entnehmen dem Workbook Informationen zu Anmeldungen von Externen an Ihrem Tenant – oder eigenen Mitarbeitern in Partner-Tenants.

Volle Kontrolle über Collaboration und die Gastkonten im eigenen Mandaten bedeutet, dass Sie regelmäßig aufräumen müssen. Über Microsoft Graph und die PowerShell bringen Sie etwa die letzten Anmeldedaten aller Gäste in Erfahrung und können Gäste bei längerer Inaktivität löschen. Sind Sie nicht nur interessiert daran, Gäste loszuwerden, sondern wollen auch deren Berechtigungen im Tenant überprüfen, bietet Azure AD Access Reviews einige Möglichkeiten: Sie können damit einzelne Ressourcen wie Mitgliedschaften in Gruppen oder Teams, privilegierten Rollen, Applikationen oder ganzen Zugriffspaketen überprüfen – falls gewünscht auch gezielt nur für Gäste.

Neu ist in Access Reviews, dass die Überprüfung mehrstufig mit bis zu drei Stufen erfolgen kann. Nur wenn am Ende alle zustimmen, darf ein Benutzer die Gruppenmitgliedschaft oder Berechtigung behalten. Das ist gerade für Gastkonten interessant, wenn Mitarbeiter von den Überprüfungen "ihrer" Gästen überfordert und sehr viele Zugriffsüberprüfungen zu tätigen sind.

In der ersten Stufe können Sie die Gäste dazu bringen, zu bestätigen, dass sie weiterhin Mitglieder von Projekten sind und damit Zugriff auf Arbeitspakete und Teams haben müssen. Nur wenn die Gäste das bestätigen, werden Sie einem internen Mitarbeiter vorgelegt, der dann über den Zugriff entscheidet. Alle, die nicht antworten oder dankend ablehnen, kommen gar nicht erst in die zweite Runde.

Dasselbe klappt mit der von Access Reviews gebotenen Funktion "Block Sign-in and remove after 30 days" auch für Gäste. Anstelle diese also aus einer Gruppe zu werfen, können Sie die Gäste am Sign-in zu Ihrem Tenant hindern und, wenn sie sich nicht beim Helpdesk gemeldet haben, nach 30 Tagen entfernen und das Gastkonto löschen. Hier funktionieren "Multi-Stage Reviews" ebenso. Sie lassen zunächst alle Gäste fortlaufendes Interesse an Kollaboration bekunden – und nur die, die das bestätigen, unterliegen einer genaueren Überprüfung durch Ihre Mitarbeiter.

Das Anlegen einer mehrstufigen Überprüfung ist einfach: Sie navigieren zu "Azure Active Directory / Identity Governance / Access Reviews" und legen mit "+ New Access Review" eine neue Review an. Für das Beispiel einer Prüfung für Gastkonten, die Mitglieder einer Gruppe sind, wählen Sie "Teams + Groups" für "Select what to review" aus und bestimmen anschließend die Gruppe und "Guest users only" als Scope. Im Schritt "Reviews" entscheiden Sie sich für die Checkbox "(Preview) Multi-stage review".

Damit zeigt das Portal die Optionen "First stage review" und "Second stage review" an, für die Sie jeweils einen Reviewer und eine Überprüfungslänge in Tagen angeben. Bedürfen Sie einer dritten Überprüfungsstufe, aktivieren Sie diese mit "+ Add a stage".

Für die erste Stufe bietet sich "Users review their own access" an, für die zweite "Group ow­ner(s)" oder "Selected user(s) or group(s)". In "Reveal review results” bestimmen Sie, ob die Reviewer späterer Schritte die Entscheidungen von zuvor sehen können sollen. Zum Abschluss legem Sie fest, welche Gäste von einer Stufe zur nächsten weitergereicht werden und im Überprüfungspool bleiben.

Die Einstellung "Reviewees going to the next stage" bietet Checkboxen, mit denen Sie die gewünschten Antworten bestimmen. "Accepted reviewees" allein würde nur die Gäste weiterreichen, die ihre Zustimmung bereits erteilt hatten. Wenn Sie Nicht-Antworter auch in der zweiten Stufe überprüfen lassen wollen, nehmen Sie "Not reviewed reviewees" mit. Die weiteren Einstellungen in "Settings" sind nicht so wichtig und beeinflussen die Multi-Stage-Einstellungen nur wenig. Abschließend vergeben Sie einen Review-Namen und legen los.

Wenn Sie in Ihrer Review nur B2B-Gäste überprüfen, taucht im vorletzten Schritt bei der Erstellung einer Access Review eine zusätzliche Einstellung auf: "Action to apply on denied guest users". Mit Ihr stellen Sie ein, dass Gäste einfach aus der Gruppe oder Anwendung entfernt werden. Möglich ist auch "Block user from signing-in for 30 days, then remove user from the tenant". Dies ist zwar eine Holzhammermethode, die in Kombination mit einer mehrstufigen Review mit dem Entfernen des Gastes endet. Aber wenn sich der Externe nicht gemeldet hat und ein interner Zweitprüfer sich nicht sicher ist, kann ein Löschen ein probates Mittel sein.

Mehrstufige Überprüfungen sind für drei Einsatzbereiche sinnvoll: Quorum finden, Überprüfungen eskalieren und Review-Arbeit delegieren. Sie erreichen ein Quorum, wenn Sie Benutzer überprüfen und dabei mehrere Stufen hintereinander attestieren lassen. Nur wenn sich alle einig sind, dass bestimmte Benutzer weiterhin Zugriff genießen sollen, steht am Ende der weitere Zugriff.

Eskalationen können Sie mit Multi-Stage-Reviews abbilden, wenn Sie abgelehnte, mit "don't know" markierte oder Benutzer ohne Antwort des ersten Reviewers von einem zweiten gegenprüfen lassen wollen. Dieser kann dann Meinungen korrigieren oder überhaupt erst eintragen – ist kein Eintrag vorhanden, entfällt der Zugriff.

Kein Admin verbringt jedoch gern Zeit mit repetitiven Tätigkeiten und klickt sich Zeile für Zeile durch eine Vielzahl von zu attestierenden Benutzern. Alternativ können Sie die Hauptarbeit erst einmal an die eigentlichen Nutznießer von Gruppenmitgliedschaften oder Anwendungszugriff delegieren: die Anwender selbst. Indem sie bei der Review selbst Hand anlegen, fallen für die zweite oder dritte Stufe alle Benutzer heraus, die sich nicht gemeldet oder abgelehnt haben. Für den Zweit- und Dritt-Reviewer verringert sich damit die Arbeit.

Wer die Kollaboration in der Cloud lebt und diese seinen Mitarbeitern ermöglicht, stellt mit steigender Anzahl an Partnern fest, dass das entgegengebrachte Vertrauen nicht immer gleich weit reicht. Beziehungstiefen zu Geschäftspartnern wollen auch in B2B-Umgebungen zumindest grob granular abgebildet werden. Die Cross-tenant access settings in Azure AD ermöglichen dies. Und um es sich beim Aufräumen der Geschäftspartner einfacher zu machen, sollten Sie mit mehrstufigen Reviews die Anwender zuerst selbst in die Pflicht nehmen und bekunden lassen, ob eine weitere Zusammenarbeit gewünscht und notwendig ist.