Trennung von Nutzern in Office 365 durch Synchronisation mehrerer Azure Active Directories

Identitäten und Rollen in einer Microsoft Azure AD Umgebung können dank der Office 365 Connector App für UCS sehr einfach provisioniert werden. Nutzer erhalten dabei einen unkomplizierten Zugriff per Single-Sign-On auf Office 365 Ressourcen, während die Kontrolle über die Informationen, die über die jeweiligen Identitäten übermitteltet werden, gewährleistet bleibt.

In einer UCS Umgebung werden darüber hinaus oft genaue Berechtigungen definiert, die die Sichtbarkeit von Benutzereigenschaften innerhalb einer Organisation regeln – gerade in großen Umgebungen ist es notwendig, dass nicht jeder Nutzer jeden anderen „sieht“. Beispielsweise werden die Datenschutzanforderungen an Schulen durch UCS@school umgesetzt: Nutzerkonten können durch den Schulträger schulübergreifend zentral administriert werden, die Nutzer „sehen“ sich selbst aber nur innerhalb der eigenen Schule gegenseitig. In einem einzelnen Azure AD ist eine solche Trennung grundsätzlich nicht vorgesehen, sondern es wird der Aufbau von mehreren Azure AD oder Tenants erwartet.

In diesem Artikel möchte ich Ihnen erklären, wie Sie seit dem letzten Update der Office 365 Connector App solche getrennten Setups mit UCS für Azure AD einfacher umsetzen können und wie die Szenarien aufgebaut sind.

Ausgangslage

UCS wird oft als Identity Management für große Umgebungen genutzt, da Nutzer und Berechtigungen mehrerer Unternehmen, Zweigstellen, Bildungseinrichtungen oder andere unter einer Dachorganisation verbundene Gruppen zusammengeführt werden. Dabei behalten sie gleichzeitig ihre verschiedenen Gruppenzugehörigkeiten und damit unterschiedliche Rechte. Die für Office 365 benötigte Nutzerdatenbank Azure AD dagegen unterstützt keine komplexen Berechtigungs-Szenarien – alle registrierten Nutzer haben vollen Lesezugriff auf das Azure AD (Ausnahme sind nur die deutlich eingeschränkten Gastzugänge). Damit unterscheidet sich Azure AD sehr deutlich vom bisherigen on premises Windows Active Directory.

Wenn Sie differenzierte Berechtigungsszenarien aufbauen wollen, muss der Betrieb von mehreren Azure AD als getrennte Nutzerdatenbanken umgesetzt werden, die wiederum sogenannten Tenants zugeordnet werden können. Da es für die Implementierung von UCS unerheblich ist, ob die verschiedenen Azure AD in einem oder mehreren Azure Tenants konfiguriert sind, ist im Folgenden immer von „Azure AD“ oder „Multi Azure AD“ die Rede. Der in der IT häufig verwendete Begriff „Multi Tenant“ für die Trennung in Mandanten meint oft die Funktionalität, die hier mit der Aufteilung der Nutzerkonten auf mehrere Azure AD realisiert wird – um Missverständnisse mit den Tenants von Azure zu vermeiden, nutze ich den Begriff im Folgenden aber nicht.

Herausforderung Single Sign-On

In UCS Umgebungen ist ein Single Sign-on (SSO), technisch umgesetzt über das SAML Protokoll, der Standardweg, um sich an Office 365 oder an anderen an Azure AD angebundenen Services zu authentifizieren. Dazu wird ein sogenannter SAML Identity Provider (IDP) mit UCS bereitgestellt, der in Azure als Authentifikationsquelle konfiguriert wird. Dazu wird unter anderem die URL des IDP, also die Adresse, auf die der Webbrowser der Anwender bei der Anmeldung zur Eingabe des Passworts verwiesen wird, im Azure AD hinterlegt.
Microsoft hat sich bei der Implementierung von SAML SSO in Azure AD dazu entschieden, die Konfiguration dieser URL aus Sicherheitsgründen einzuschränken: ein SAML IDP kann nur genau einem Azure AD zugewiesen werden – ein zweites Azure AD kann diesen nicht mehr nutzen. Genau diese Beschränkung steht aber im Widerspruch zu den eingangs beschriebenen Anforderungen: wir wollen ja gerade mehrere Azure AD zur Datentrennung einführen und gleichzeitig ein SSO mit UCS ermöglichen. Um hier einen für Anwender und Administratoren eines UCS Systems gangbaren Weg zu finden, war ein Umschiffen dieser Vorgaben innerhalb des SAML IDP von UCS notwendig. Daher haben wir uns in der Entwicklungsabteilung dafür entschieden, dass in UCS der IDP über Aliase auch unter zusätzlichen URLs erreichbar gemacht werden kann, die dann jeweils in einem Azure AD konfiguriert werden können.

Implementierung

Wir haben den Office 365 Connector in UCS mit App Version 3 so erweitert, dass mehrere Azure AD eingerichtet und diese anschließend in der Management Console (UMC) an den zu synchronisierenden Nutzern und Gruppen ausgewählt werden können. Direkt nach der Installation ist dazu ein erstes „Default“ Azure AD vorbereitet, das Sie interaktiv über den Wizard im Webinterface von UCS konfigurieren können. Dabei werden Sie als Administrator schrittweise sowohl durch die Konfiguration der Synchronisation mit Azure AD als auch durch die des Single Sign-on über SAML geführt. Wird an Nutzern oder Gruppen in UCS die Synchronisation mit O365 aktiviert, werden sie per Voreinstellung in dieses erste Azure AD synchronisiert – bis hierher gibt es also keine wesentliche Änderung gegenüber der Funktionsweise des bisherigen Connectors.
Soll ein weiteres Azure AD eingerichtet werden, können Sie dieses über einen einfachen Befehl auf dem UCS System vorbereiten. Dabei geben Sie dem zusätzlichen Azure AD einen sprechenden Namen im UCS, der später bei der Zuordnung an Benutzern und Gruppen auch im Webinterface angezeigt wird. Der interaktive Wizard im Webinterface wird in diesem Zuge auch auf die Konfiguration dieser Azure AD Verbindung vorbereitet.
Um die Konfiguration abzuschließen, ist es durch die eingangs beschriebenen Vorgaben von Microsoft zur Integration des SAML IDP aber noch notwendig, eine zusätzliche URL für den IDP bereitzustellen. In größeren Umgebungen ist es üblich, den SAML IDP auf einem (oder auch auf mehreren) anderen Systemen zu betreiben als den O365 Connector selbst. Auf diesen Systemen können seit UCS 4.4 Errata 358 „Aliase“ registriert werden, aus denen zusätzliche URLs für den Zugriff auf den SAML IDP generiert werden. Empfehlenswert ist es, hier das gleiche Namensschema wie bei der Benennung der Azure AD Verbindungen zu verwenden.
In der durch den O365 Wizard begleiteten Konfiguration werden dann diese Elemente wieder zusammen geführt. Das zusätzliche Azure AD wird durch den Connector mit Identitäten provisioniert sowie eine eindeutige SAML IDP URL zugeordnet. Welche Nutzer auf welches Azure AD Zugriff bekommen, können Sie danach bequem über das Webinterface von UCS konfigurieren.

Endanwender

Für den Anwender bleibt diese Komplexität im Verborgenen. Der Zugriff auf O365 wird durch den SAML SSO geschützt – die unterschiedlichen Azure AD oder SAML URLs sind für die Nutzer dabei völlig transparent und der Nutzer hat den gewohnten Komfort von Single Sign-on. Über die Integration mit dem Loginvorgang an Arbeitsplätzen in der UCS Domäne kann dabei sogar auf eine erneute Anmeldung im Webbrowser verzichtet werden.
Jedem Nutzer wird im Office 365 bzw. Azure AD ein individueller Login („User Principal Name“) zugeordnet. Das kann zu Verwirrung bei den Anwender führen, wenn mehrere Azure ADs freigeschaltet wurden und die Anmeldung direkt auf den Login-Seiten von Microsoft gestartet wird. Um zu vermeiden, dass sich Anwender Login und URL des Azure AD merken müssen, ist es empfehlenswert, diese über das Univention Portal zu verknüpfen. Anwender sehen dann nur die Ressourcen, auf die sie Zugriff haben, und können dank Single Sign-on ohne Eingabe Azure AD spezifischer Logins direkt loslegen.
Die Trennung von Nutzergruppen in eigene Azure AD oder eigene Azure Tenants ist durch die Neuerungen im Office 365 Connector mit UCS bei gleichzeitiger einfacher Nutzung durch die Endanwender somit jetzt einfach möglich.

Dokumentation der Einrichtung:

• Einrichtung mehrerer Azure AD im O365 Connector
• Einrichtung von Aliasen für den SAML Login