Teil 1 des Workshops hatte das Einladungssystem zum Thema, gesteuert durch die IT-Administration oder den Endbenutzer selbst. Wenn niemand eine Einladung aussprechen soll, können sich externe Gäste auf Wunsch selbst registrieren – zumindest wenn eine Anwendung auch für "Self-Service Sign-up" konfiguriert wurde. Mit einer Variante davon steigen wir in den zweiten Workshopteil ein: von Admins oder Unternehmenseinheiten definierte Zugriffspakete, die externe Gäste anfragen können.

Geht es um mehr Kollaboration als mit einer einzigen App und um Zugriff auf unterschiedliche Ressourcen, wie etwa Diskussionsgruppen oder SharePoint-Seiten, hilft das Entitlement Management im Azure AD (AAD): Dort schnüren Sie Zugriffs-pakete für interne und externe Anwender, mit denen sich dann Ressourcen zusammenfassen und freigeben lassen. Eigene Mitarbeiter können die Zugriffspakete über manuelle Zuweisung erhalten oder per Katalog-Shopping finden und anfragen. Geben Sie Zugriffspakete explizit für externe Gäste frei, können Partner mit einer eindeutigen URL den Zugriff selbst beantragen – egal, ob sie bereits Gast im Unternehmen sind oder nicht. Falls nicht, legt AAD bei der Genehmigung des Zugriffs-pakets einfach ein neues Gastkonto an.

Sie können den Externen beim Beantragungsprozess zum Beantworten von Fragen zwingen. Wie bereits bei der Selbstregistrierung über die freigegebene Anwendung werden die Antworten auf Wunsch nicht nur dem Genehmiger zur Einsicht zur Verfügung gestellt. Weiterhin lassen sich die Angaben dem neu angelegten Gastkonto im Azure AD als Attribute hinzufügen.

Zugriffspakete sind nur dann mit Externen teilbar, wenn der Katalog, also die Sammlung der Zugriffspakete, auch für externes Teilen konfiguriert ist. Sie können einen bestehenden Katalog editieren, indem Sie im AAD bei "Identity Governance / Catalogs" in der Übersicht auf "Edit" klicken und "Enabled for external users" aktivieren. In "Resources" sehen Sie die Ressourcen des Katalogs, die entweder schon durch bestehende Zugriffs-pakete hinzugefügt wurden oder die Administratoren vordefiniert haben. Wählen Sie eine oder mehrere Ressourcen aus und klicken Sie auf "Require attributes (Preview)", um Fragen und Antworten für alle Zugriffspakete zu definieren, die diese Ressourcen nutzen sollen. Der Editor erlaubt die Auswahl von "Built-in", also Standardattributen des Azure AD, sowie eigens definierte, die Sie dem Verzeichnis später hinzugefügt haben. Wenn Sie dem Beispiel des ersten Teils gefolgt sind, können Sie die damals erstellten Attribute über "Attribute type: Directory schema extension" und das Dropdown "Attribute" auswählen. Bleibt Ihre Auswahl bei "Attribute type: built-in", sehen Sie eine Standardauswahl von Benutzerattributen.

Sie konfigurieren hier, welche Fragen externe Gäste beantworten sollen und in welchen Attributen Sie diese ablegen wollen. Sie geben für jedes Attribut in "Default display string" an, was der externe, neue Gast als Frage zu Gesicht bekommt. Hierzu zählt etwa eine Angabe wie "Partner ID" oder "Your home company". Definieren Sie das Antwortformat entweder als "Long text", "Short text" oder "Multiple Choice", wenn Sie endliche Antwortmöglichkeiten vorgeben wollen, wie etwa Teams, Kostenstellen oder Büros, in denen Gäste arbeiten sollen. In "Attribute is editable" entscheiden Sie sich für "Yes", damit Gäste die Antworten tatsächlich geben und diese dann ins Directory fließen können. Wollen Sie die Eingaben in den Attributen am Gastkonto behalten, auch wenn das Zugriffspaket entzogen wird oder ausläuft, nutzen Sie "Keep value when assignment is removed: Yes".

Sind Sie mit Ihrer Auswahl zufrieden, können Sie ein neues oder bestehendes Zugriffspaket konfigurieren, das die Fragen, Antworten und die Ressourcen, für die Sie sie bestimmt haben, beinhaltet: Für ein neues Zugriffspaket klicken Sie im Azure AD bei "Identity Governance / Access Packages" auf "+ New Access Package", vergeben einen sprechenden Namen, eine Beschreibung und wählen den zuvor editierten Katalog aus. Bei "Resource Roles" fügen Sie die Ressourcen hinzu, für die Sie zuvor die Fragen und Attribute konfiguriert hatten – neben anderen Inhalten, die Sie ebenfalls als Element des Zugriffspakets verteilen wollen.

Im nächsten Schritt "Requests" nutzen Sie die Option "For users not in your directory", um Azure AD zu signalisieren, dass das Paket von externen Gästen angefragt werden kann. Sie können das Paket dann besonderen Unternehmenspartnern zur Verfügung stellen, die Sie zuvor über "Connected organizations" identifiziert und hinterlegt haben, oder "All users (All connected organizations + any new external users)" freigeben. Außerdem bestimmen Sie, ob vor dem Erstellen eines Gastkontos und der Genehmigung noch einmal jemand darüberschaut – entweder ein einstufiges oder zweistufiges Approval-Verfahren sind möglich. Damit Gäste das Paket anfragen können, müssen Sie noch "Enable new requests" mit "Yes" bestätigen.

Im Schritt "Requestor information" spielt nun endlich die Musik: Sie finden zwei Reiter, "Questions" und "Attributes (Preview)". In "Questions" können Sie optional weitere Fragen definieren, deren Antworten die Überprüfer und Genehmiger der Zugriffspakete sehen und auswerten können – die Eingaben landen aber nicht im Verzeichnis. Im Reiter "Attributes (Preview)" sehen Sie die zuvor definieren Fragen und deren Attributzuweisung, die Sie gerade getätigt hatten.

Mit "Next: Lifecycle" gehen Sie zum nächsten Schritt über, in dem Sie Ablaufkriterien und Zugriffsüberprüfungen definieren. Zum Schluss erstellen Sie das Zugriffspaket, wenn Sie via "Create" den Prozess anstoßen. Sobald das Paket fertig ist, sollten Sie in die Paketübersicht zurückkehren und die URL im Feld "My Access portal link" kopieren. Dieser eindeutige Link zeigt auf das Portal "myaccess.microsoft.com", über das alle Self-Service-Anfragen, auch für Gastbenutzer, laufen. Der Link enthält Ihre Tenant-Kennung sowie die eindeutige Paketnummer, sodass Ihre Unternehmenspartner über diesen eindeutigen Link direkt zum Paket finden und es anfragen können.

Wer die Zugriffspakete für interne und externe Mitarbeiter nutzen möchte, muss für Azure AD die notwendigen Premium-P2-Lizenzen vorrätig haben – eine Lizenz ist für jeden Internen und Externen fällig, der Zugriffspakete anfragt oder erhält.

Auch bei B2B-Kollaboration über das Azure AD sind Authentisierung und Autorisierung geteilt: Während das Einladungsverfahren steuert, dass sich Gäste mit dem Login in ihrer Heimatorganisation auch in Ihrem Netzwerk bewegen können, heißt das nicht, dass Gäste wirklich Daten lesen und nutzen können – hierzu müssen Sie weiterhin ein Modell zur Autorisierung etablieren. Die eben beschriebenen Zugriffspakete erleichtern beide Schritte und erteilen Gästen bereits einen Satz von Berechtigungen auf Ressourcen. Bestehenden Gäste oder solchen aus anderen Einladungsverfahren müssen Sie Erlaubnisse erteilen.

Die Autorisierung findet in zwei Phasen statt: Wenn der Gast sich im Heimat-Tenant anmeldet und zurück in Ihren Tenant kommt, überprüft Conditional Access (CA), ob die Zielanwendung, zu der der Gast möchte, überhaupt freigegeben ist. Falls ja, greifen die In-App-Berechtigungen. Damit haben Sie auch für Gastbenutzer eine zweistufige Autorisierung: einmal durch den IT-Admin, der definiert, ob Gäste SharePoint, Teams oder die Kantinenmenü-App benutzen dürfen und unter welchen Voraussetzungen. Danach bestimmen die jeweiligen Ressourcenbesitzer, also der Teams-Besitzer, der SharePoint-Site-Owner oder das Kantinenteam, wer auf die jeweiligen Daten zugreifen darf.

Somit können Sie trotz Erlaubnis für Gastzugriffe die wichtigsten Anwendungen schützen und verbieten, dass Gäste die hochsensiblen Kundendaten auf einem SharePoint-Server oder im CRM überhaupt ansehen dürfen – oder nur dann, wenn Sie von einem Ihrer Netzwerke kommen und eine Multifakor-Authentifizierung (MFA) durchgeführt haben. Conditional Access greift auch für alle Gastkonten, die Sie bei der Konfiguration einer Richtlinie explizit als Zielbenutzer angeben können: "All guest and external users" – oder genauso mit "Exclude" von anderen Richtlinien ausschließen können.

Bei der Anwendung von CA-Regeln ist allerdings bei einigen Optionen Vorsicht geboten: Während die Netzwerk- und IP-Adressregeln problemlos klappen, vertraut ihr Azure AD einer MFA aus einem anderen Azure AD noch nicht. B2B-Gäste müssen, wenn Conditional Access auf Multifaktor-Authentifizierung besteht, eine Neuregistrierung von MFA-Methoden in Ihrem Tenant durchführen. Das ist unschön, weil das Benutzererlebnis leidet. Leider ist es noch nicht möglich, ein erfolgreiche MFA oder den Gesundheitszustand von Geräten zwischen Azure-AD-Tenants zu übertragen. Solange Microsoft daran noch arbeitet, müssen Sie also ohne "device compliance" bei Gästen auskommen und diese müssen MFA-Optionen in Ihrem Tenant registrieren.

Natürlich sollten externe Gäste nicht ungehindert und für alle Zeit im eigenen Tenant verweilen dürfen. Nur solange sie eine Daseinsberechtigung haben, sollten sie tatsächlich bleiben dürfen. Immerhin: Mit der Einladung erhalten Gäste nur das Recht, sich anmelden zu dürfen, nicht, beliebige Ressourcen oder Daten einzusehen.

Zudem schränkt die Einstellung "Guest user access restrictions" ein, was Gäste sehen dürfen. Solange Mitarbeiter, Anwendungsverantwortliche und Daten-Admins den Partnern keine Berechtigungen zuweisen, besteht kein höheres Risiko, wenn Gäste auch bei Nichtbenutzung im Tenant bleiben. Ein Problem aber besteht weiter: Mitarbeiter könnten versehentlich das Gastkonto bei Berechtigungsentscheidungen auswählen und die falsche Person zum Projekt in Teams oder zur Kalendereinsicht hinzufügen.

Wer also aufräumen will, sollte die gewählte Methode der Einladung der Gäste nicht außer Acht lassen: Denn wer alle externen Mitarbeiter im Windows-AD anlegt und als Gäste synchronisiert oder eingeladene Personen später mit einem Konto im Windows-AD verbindet, kann das Gastkonto auch nur dort verwalten und löschen. Das Aufräumen lagern Sie dann mit der AADConnect-Synchronisation in die Cloud aus.

Sind sie auf der Suche nach Wegen für automatisches Aufräumen, gibt die Graph-API in Verbindung mit der PowerShell einige Hinweise. Jedes Gastkonto erhält bei seiner Erstellung Attributwerte, die sich abfragen und auswerten lassen: "createdDateTime" etwa verrät, wann das Gastkonto erstellt wurde, und "externalUserState" zeigt an, ob der Partner die Einladung überhaupt angenommen hat oder nicht. "Accepted" weist auf funktionierende Kollaboration hin, "PendingAcceptance" heißt, dass eine Einladung ausgesprochen, aber nicht angenommen wurde. Nutzer in diesem Status mit einem "createdDateTime"-Wert, der eine Weile zurückliegt, wurden wohl schon länger eingeladen, wollten aber bisher nicht kollaborieren und sind deshalb wohl verzichtbar.

Wann sich der Einladungsstatus geändert hat, hält "externalUserStateChangeDateTime" fest. Ein Indikator für inaktive Gäste ist das Property "lastSignInDateTime" im Objekt "signInActivity" [1]. Wenn Sie das Attribut prüfen, sollte für jeden Gast ein Datum auftauchen – fehlt es, hat sich der Gast entweder nie oder vor April 2020 zuletzt angemeldet, als Microsoft begann, das Attribut zu befüllen. Eine Beispielanfrage an den Microsoft-Graphen etwa mit dem Tool Graph Explorer [2] sieht so aus:

Wollen Sie untersuchen, ob Ihre Gäste privilegierte Rollen oder Gruppenmitgliedschaften besitzen, können Sie ebenfalls den Graphen bemühen – und die Logik so anwenden, wie Sie das auch für Ihre eigenen Benutzer schreiben würden. Die Syntax ist identisch. Ein Beispielskript ist in [3] zu finden. Die Gruppenmitgliedschaft für einen Benutzer ist einfach über "memberOf" zu erlangen:

Bevor Sie Gastkonten löschen, können Sie die Gäste für einige Zeit an der Anmeldung an Ihrem Azure-AD hindern – damit sind für diese dann keine Dienste wie Teams, SharePoint oder andere Apps erlaubt. Verwenden Sie das Attribut "accountEnabled", um das Gastkonto bei sich zu sperren, und warten Sie ab, ob sich jemand beschwert. Mit der "PATCH"-Methode von Graph können Sie das Attribut ändern:

Wenn Sie Gäste wie eingangs beschrieben über Zugriffspakete einladen, können Sie Azure AD die Gäste automatisch aufräumen lassen, wenn diese ihre Assignments verlieren oder diese zeitlich ablaufen und nicht erneuert werden. Dafür kennt AAD im Entitlement Management die Einstellung "Manage the lifecycle of external guests" in Menü "Settings". Dort definieren Sie, ob Gäste ohne Assignments im Tenant gesperrt und nach einer bestimmten Anzahl von Tagen gelöscht werden sollen.

Verwenden Sie entweder das Self-Service-Sign-up über eine App oder Zugriffspakete, sind die Frage-und-Antwort-Funktionen ebenfalls für das Aufräumen nutzbar. Ist es nicht vorgesehen, dass selbstregistrierte Partner außerhalb der Anwendung Zugriff im Tenant haben, bewerten Sie Inaktivität über die Zugriffe zur App: Sie markieren mit den Fragen und Antworten die jeweiligen Benutzer und prüfen dann Inaktivität in der App.

Wer wen eingeladen hat, erfahren Sie über das Auditlog im Azure AD, wo alle Änderungen am Verzeichnis niedergelegt sind – die Analyse geht entweder über den fortlaufenden Export aus Azure AD in ein Log-Tool oder SIEM oder ad-hoc im AAD-Portal. Filtern Sie nach "Service: Invited Users" und "Category: UserManagement", worauf Events zu allen ausgesprochenen Einladungen und deren Annahme auftauchen. "Activity Type: Invite external user" informiert in den Feldern "objectID", "user principal name" und "invitedUserEmailAddress" über den Mitarbeiter, der die Einladung ausgesprochen hat, und wohin sie geschickt wurde. Die Information können Sie dann entweder im Azure AD, beispielsweise im "manager"-Feld des Gastes, hinterlegen, in jedem anderen Attribut im AAD oder in einem anderen System. Automatisch geht das leider noch nicht.

Selbst die manuelle Lösung ist allerdings nur bedingt hilfreich, weil viele Gäste mehrere Kollaborateure haben können oder ihre Projekte und Ansprechpersonen wechseln. Sie müssen sich also einen Prozess überlegen, wie Sie das Sponsoring, falls unbedingt notwendig, aktuell halten. Und was passiert, wenn der Sponsor das Unternehmen verlässt? Wer übernimmt? Fragen, die gute Unternehmensprozesse und eine Abwägung von Kosten-Aufwand-Nutzen erfordern.

Einen etwas anderen Ansatz verfolgt Access Reviews im Azure AD, das mit dem Premium-P2-Paket verfügbar ist: Anstelle von einzelnen Sponsoren lassen Sie Teambesitzer, Daten-Admins und Anwendungsverantwortliche Zugriff auf ihre Ressourcen überprüfen – und nicht mehr benötigte Benutzer, darunter auch Gäste, hinauswerfen. Haben Gäste nirgendwo Zugriff zu Ressourcen, fallen Sie irgendwann einer Überprüfung auf Inaktivität zum Opfer und werden irgendwann automatisch gelöscht. So nehmen Sie die Besitzer von Anwendungen, Sites und Teams in die Pflicht, die Mitglieder zu kennen und aktuell zu halten, notfalls mit einem wiederkehrenden Review in periodischen Abständen – auf Wunsch nur auf die externen Gäste fokussiert.

Vor Kollaboration mit anderen Unternehmen muss sich heute niemand mehr fürchten. Das B2B-System im Azure AD für Office 365 und eingebundene Anwendungen bietet einiges an Flexibilität und Transparenz. Etwas Planung und Konfiguration ist dennoch gefragt. Denn der Lebenszyklus der Gastkonten und aller Berechtigungen für Gäste will geplant und umgesetzt sein. Das Einladesystem hat zuletzt einige Änderungen erfahren, die Hoffnung auf mehr machen: Es existieren gerade in Unternehmen mit mehreren Mandanten in Office 365 oder bei Unternehmensübernahmen Szenarien, in denen ein Heranrücken mehrerer Tenants wünschenswert wäre – etwa beim Auswerten der Gerätegesundheit oder bei MFA aus dem Heimat-Tenant.