Wenn Ihre Mitarbeiter Daten und Ressourcen mit externen Partnern und Zulieferern teilen oder Sie in einem Konzern mit mehreren Gesellschaften arbeiten, die eine eigenständige IT und Cloudmandanten besitzen, dann kennen Sie Kollaboration mit Azure AD B2B wahrscheinlich. Microsoft bindet Personen aus anderen Mandanten in Ihren Tenant auf Wunsch als "externe Identitäten" ein, die Sie dann zum Ressourcenzugriff berechtigen und gegebenenfalls verwalten und später wieder entfernen können. Dabei trennt Microsoft mit "External Identities" bisher noch die beiden Welten "Business-to-Business" (B2B) und "Business-to-Consumer" (B2C) – sie wachsen aber immer weiter zusammen.

Starten lässt sich die Kollaboration entweder von Mitarbeitern selbst oder von der zentralen IT. Kollegen können ihre Partner selbstständig zur Mitarbeit an ihren Ressourcen einladen, wenn es die Unternehmenseinstellungen in Azure AD erlauben. Dann wird eine Einladung ausgelöst, die der externe Partner annehmen kann und im Anschluss Zugang zu Daten erhält. Ansonsten muss die zentrale IT ran und über ein eigenes Portal entweder eigene Prozesse mit Synchronisation einrichten oder manuell externe Partner anlegen.

Im besten Fall geschieht das immer über das Einladungssystem von Azure AD B2B. Denn dann wird zwar ein Gastkonto für den Externen im eigenen Azure AD erstellt, jedoch geschehen Authentifizierung und Lifecycle-Management im Heimatunternehmen – Nutzer besitzen also ein Gastkonto, das eine Referenz auf das Heimatkonto des Externen darstellt, um Berechtigungen, Auditing und Suche im Home-Directory zu ermöglichen. Denn was Sie nicht wollen, sind die Verwaltung von Passwörtern und die zusätzlichen Kosten, die für das Neusetzen, Zuschicken und den Helpdesk für Externe entstehen.

Wenn die Einstellung "Guest invite settings" in "External Collaboration Settings" im Azure-AD-Portal Mitarbeitern erlaubt [1], selbst Einladungen auszusprechen, können nahezu alle Benutzerportale in der Microsoft-Cloud externe Partner einladen: SharePoint, Teams, die TODO-App sowie das Azure-AD-Portal selbst. Mitarbeiter geben dann die E-Mail-Adresse des Externen an, mit dem Sie kollaborieren wollen und Azure AD findet den richtigen Weg. Da die E-Mail-Adresse oft die einzige Kontaktoption darstellt, ist auch das B2B-System darauf ausgerichtet: Die Einladungen erreichen den Empfänger per E-Mail.

Wenn Azure AD erkennt, dass die einzuladende E-Mail-Domain auch in der Microsoft-Cloud existiert, wird die Einladung verschickt und AAD erwartet eine Anmeldung mit einem AAD-Konto. Das erlaubt echtes Single Sign-on (SSO) bei der Kollaboration. Ist die Domain nicht in Azure AD und besteht auch keine Föderierung zu einem Identity Provider (IDP) der Partnerorganisation, verschickt Azure AD One-Time-Passcodes (OTP) per E-Mail an den Geschäftspartner. OTP per E-Mail ist für Azure AD die letzte Chance, einen externen Partner automatisiert einzuladen – wenn Sie die entsprechende Einstellung in Azure AD deaktiviert haben, erhält Ihr Mitarbeiter beim Einlade-Versuch eine Fehlermeldung, dass sich der externe Gast nicht für Kollaboration hinzufügen lässt.

Sie bestimmen, ob und wen Ihre Mitarbeiter einladen können. Im Azure-AD-Portal definieren Sie in "External identities / External collaboration settings" die B2B-Einstellungen, etwa ob das E-Mail-OTP erlaubt sein soll, welche Berechtigungen Gäste im Tenant haben dürfen, wer Gäste überhaupt einladen darf und zu welchen Geschäftspartnern, identifiziert per E-Mail-Domain, sich Einladungen senden lassen.

Die Einstellung "Guest user access restrictions" hat Redmond jüngst um eine weitere restriktive Einstellung erweitert. Sie konnten bisher Gäste mit eingeschränkten Berechtigungen einladen, was die Voreinstellung ist, oder Gästen die gleichen Berechtigungen im Verzeichnis einräumen, die auch interne Mitarbeiter haben: andere Mitarbeiter und Gruppen durchsuchen, Anwendungen sehen et cetera. Neu ist ein sehr restriktives Setting: Gäste können mit der "most restrictive"-Einstellung nur das im Verzeichnis lesen, was ihnen direkt gehört oder wo sie direkt Mitglied sind.

Einige Unternehmen sehen Schwierigkeiten in der Verwaltung der externen Identitäten und befürchten, Mitarbeiter könnten unkontrolliert Externe einladen und nie mehr aufräumen. Sie können die Kollaboration mit Azure-AD-Bordmitteln aber mit Leitplanken versehen, sodass nur Externe bestimmter, erlaubter Domänen zugelassen sind und sich nur Daten von geringer Klassifizierung teilen lassen, niemals als "geheim" oder "vertraulich" eingestufte. Aufräumen können Sie mit Identity-Governance-Mitteln aus Azure AD, etwa mit "Access Reviews", wonach die Externen dann aus dem Mandanten entfernt werden. Reicht das alles nicht, muss doch die IT ran: entweder über ein eigenes Werkzeug, das mit der Graph-API von Azure AD spricht und die Externen einlädt und verwaltet, oder über das Anlegen von Benutzerkonten für Externe im Windows AD, die dann in die Cloud eine Synchronisierung erfahren.

Wer schon ein fertiges Werkzeug für die Verwaltung von Externen besitzt, kann Azure AD mit der Graph-API die Instruktionen zum Einladen, Ändern und Löschen schicken. Der Invitation Manager in Azure AD löst dann die Einladung aus. Sie senden einen POST-Request nach "https://graph.microsoft.com/v1.0/invitations" und geben im Request-Body wie in Listing 1 dargestellt die Daten für die Einladung an.

Die Graph-Anfragen lassen sich von einem Portal, Werkzeug oder Skript bei Bedarf ausführen. Wer schon Konten für externe Mitarbeiter in seinem Windows AD besitzt und diese für die Cloud weiterverwenden möchte, kann das Sync-Werkzeug Azure AD Connect so konfigurieren, dass die Konten der Externen als "Gäste" nach Azure AD abgeglichen werden [2]. AADConnect erkennt die Gäste dann anhand einer besonderen OU oder eines Attribut-Markers. Dann sind die Konten auch in der Cloud entsprechend hinterlegt und mit den Zugriffseinschränkungen versehen. In diesem Szenario wird keine Einladung ausgesprochen und die Externen melden sich über ihre Anmel-deinfrastruktur an, mit Credentials, die Sie ihnen ausgehändigt haben. Das ist aber kein B2B im modernen Sinne, wie Microsoft es für die Cloud vorsieht, weil Sie das Konto und die Anmeldung komplett selbst verwalten.

Die IT – oder mit der richtigen Delegation eventuell sogar der Helpdesk über eine Power App – können die Gastkonten nachträglich noch via Graph API oder PowerShell ändern. Das ist besonders interessant, wenn Gäste zunächst mit synchronisierten Konten starten, um sie später in "richtige" B2B-Gäste zu überführen; Das gilt ebenso für die Fälle, in denen Sie B2B-Gäste eingeladen haben, vielleicht mit E-Mail-OTP gestartet sind, aber das Partnerunternehmen inzwischen auch ein AAD hat und Sie die Gäste von OTP nach SSO mit AAD migrieren wollen.

Wenn Sie bereits einige Gäste aus Ihrem Windows-AD per Sync-Werkzeug in die Cloud synchronisieren, können Sie sie mit der PowerShell oder der Graph-API konvertieren. Das Ergebnis sind dann weiterhin synchronisierte Gäste, die Sie im Windows-AD verwalten. Diese melden sich aber nicht mehr an Ihrer Infrastruktur an, sondern können SSO mit Azure AD von ihrem Heimat-Tenant nutzen. Für die Migration nutzen Sie erneut die Graph-API, verwenden aber nicht "invitedUserDisplayname" und "invitedUser­EmailAddress", sondern geben den bereits existierenden Benutzer im Tenant mit seinem "userPrincipalName" an:

 

Die weiteren Attribute der Graph-Anfrage können Sie wie gewohnt verwenden. Wenn Sie einen bestehenden B2B-Gast zurücksetzen möchten, weil sein Konto im Heimat-Tenant gelöscht und neu erstellt wurde oder sich die Anmeldeverfahren des Partner-Tenants geändert haben, nutzen Sie ebenfalls die Graph-API oder die PowerShell. Sie geben, wie im Beispiel zuvor, den bereits existierenden Gast mit dem UPN an, fügen aber dann der Anfrage "resetRedemption" hinzu. Das genaue Vorgehen zeigt Listing 2. Einmal erstellte Gastkonten für externe Partner sind also keine Einbahnstraße – sie lassen sich zu einem späteren Zeitpunkt beliebig anpassen.

Wenn weder IT noch eigene Benutzer Einladungen aussprechen können sollen, weil die externen Partner für Kollaboration nicht oder noch nicht bekannt sind, oder wenn ein Webportal oder eine Web­app für "freie" Partner freigegeben werden soll, ist der mitarbeitergesteuerte Ansatz eher schwierig.

Azure AD unterstützt einen Self-Sign-up-Prozess für Externe, den Sie für Anwendungen, die mit Azure AD für SSO integriert sind, einschalten können. Beim Zugriff auf die Anwendung bieten Sie neuen Benutzern, die noch kein Gastkonto im Tenant haben, einen Registrierungsprozess an, wonach dann ein Gastkonto erstellt wird. Der Prozess lässt sich an­passen: Sie zwingen neue Gäste, bei der Selbstregistrierung Fragen zu beantworten, deren Antworten dann in Attributen landen, die dem B2B-Gastkonto obliegen.

Den Self-Sign-up erlauben Sie in "External Identities / External Collaboration Settings" und "Enable guest self-service sign-up via user flows". Damit gestatten Sie die Registrierung generell, müssen aber noch weitere Konfigurationen vornehmen: In "External Identities" finden Sie den Menüpunkt "Custom user attributes", in dem Sie während des Sign-ups abgefragte Attribute definieren. Eine vordefinierte Liste existiert bereits – diese Attribute sind alle mit den Standardattributen aus Azure AD verknüpft und Antworten von Externen werden dort abgelegt. Das ist nützlich, wenn Sie Standarddaten wie "Vorname", "Nachname", "Jobtitel" oder "Land/Region" abfragen wollen. Wenn sie per "+ Add" ein neues Attribut definieren, geben Sie den Namen, den Datentyp und eine Beschreibung an. Für unser Beispiel legen wir "FullTimeContract" als Boolean an, das ausweisen soll, ob der Externe einen unbefristeten Arbeitsvertrag in seinem Heimatunternehmen hat. In "HomeCompany" wird das Heimatunternehmen gespeichert, sollte das aus der E-Mail-Domäne oder dem Benutzernamen nicht hervorgehen.

Für selbsterstellte Attribute speichert Azure AD die Antworten in einem neuen Attribut aus einer Schema-Extension, die an Benutzer automatisch angeheftet wird. Das Attribut heißt in jedem Azure AD ein wenig anders und richtet sich nach der folgenden Namensgebung: "extension_ <GUID>_<Attributname>", zum Beispiel "extension_ff0facac34124cfe8e8bb3f66121 9df4_FullTimeContract". Die Kurzform der GUID, ohne die Bindestriche, stammt aus der GUID einer Anwendung, die Microsoft für diese Schemaerweiterung im Tenant registriert hat. Sie finden diese unter "Application registrations" in Azure AD, wenn Sie nach "aad-extensions-app" suchen und davon die "Application (client) ID" in GUID-Form kopieren und die Bindestriche aus der GUID entfernen.

Bei registrierten Benutzern lassen sich die Antworten mit der Graph-API abrufen oder auch für Filterkriterien für dynamische Gruppen oder Administrative Units verwenden. Die eigens erstellten Attribute sind mit ihrem Attributnamen über "$select" in einer Graph-Abfrage zu erhalten, wobei "9d67333e..." die Objekt-ID des neuen Gastkontos ist (Listing 3).

Sind die Attribute definiert, prüfen Sie in "External Collaboration Settings / All identity providers", ob alle relevanten Identity-Provider registriert sind, die Sie für die Selbstregistration vorsehen. Bereits vordefiniert sind "Azure AD" für B2B sowie "Microsoft Account" für Externe, die kein AAD besitzen, denen Sie aber soziale Konten gestatten wollen und – falls erlaubt – E-Mail-OTP. Wenn Sie andere IDPs zulassen wollen, können Sie Facebook, Google oder eine eigene Föderierung zu einem Identity-Provider erstellen und aktivieren. Sie definieren die IDPs einmalig und bestimmen später pro Anwendung und Registrations-Flow, welche der Provider Sie für welche App erlauben wollen.

In "Custom user flows" starten Sie mit "+ New user flow" den Assistenten. Benennen Sie den Flow so wie die App, die Sie für Selbstregistration zur Verfügung stellen wollen, wählen Sie die erlaubten Identity-Provider zur Authentifizierung aus und definieren Sie, welche Attribute Sie bei neu registrierten Externen verwalten wollen. Mit "Create" erzeugen Sie dann Ihren ersten Flow, den Sie gleich weiterbearbeiten: Unter "Page Layouts" definieren Sie die Anzeigereihenfolge der Anwendungen. Im linken Menü unter "Use" wählen Sie "Applications" und legen fest, für welche Anwendungen die Selbstregistrierung gestattet sein soll.

Fortan, wenn Besucher die Anwendung öffnen und die Azure-AD-Anmeldeseite erscheint, können Externe unter dem Benutzernamenfeld den Punkt "Don't have an account? Create one!" anklicken, um den Registrierungsprozess zu starten. Der Assistent bietet dann die Identity-Provider zur Auswahl, die der unterliegende Flow auch unterstützt. Ist die Anmeldung am Ziel-IDP vollzogen, zeigt Azure AD danach die Liste der Attribute an, die der Benutzer auszufüllen hat, und erst dann wird das B2B-Gastkonto erstellt und der Zugriff auf die App gewährt.

Sollten Sie bei der Selbstregistrierung auf zusätzliche Überprüfungen bestehen, können Sie eine eigene Genehmigungslogik erstellen, die Azure AD aufruft. Sie definieren die API und wie sich Azure AD mit der API authentifiziert in "All API Connectors". Dort legen Sie einen Connector für Ihre API an, von der Azure AD von der Genehmigung lernen soll, bevor die B2B-Gäste wirklich erzeugt werden [3].

In diesem Workshop haben wir geschildert, wie B2B-Gäste und externe Partner für Kollaboration in Office 365 und alle AAD-SSO-Apps kommen. Die IT oder Benutzer sprechen Einladungen aus, denen Externe folgen können. Der Self-Sign-up-Prozess gibt Externen die Chance, selbst die Initiative zu ergreifen, wenn in einem beschränkten Umfang – innerhalb einer App – freie Kollaboration herrschen soll. Einen weiteren "Self-Service"-Fall für B2B behandeln wir im zweiten Teil dieses Tutorials – und widmen uns der erweiterten Verwaltung von Gastkonten in Azure AD.