In diesem Artikel möchte ich euch zeigen, was man mit Azure AD Connect und Gastbenutzern anstellen kann. 🙂
Normalerweise wird Azure AD Connect dazu genutzt, um die Mitarbeiter/Gruppen aus dem lokalen Active Directory in das Azure AD zu synchronisieren. Um mit Externen zusammenarbeiten zu können, werden Gastbenutzer genutzt, die entsprechend eingeladen werden. Diese Gastbenutzer „leben“ normalerweise nur im Azure Active Directory. Aber was ist, wenn wir aus Gründen diese Externen bereits im lokalen AD angelegt haben und diese von den Externen bereits genutzt werden? Können wir dann nicht diese Benutzer auch als Gastbenutzer in Microsoft 365 nutzen? Also zum Beispiel um eine Datei in SharePoint für einen Externen zum Bearbeiten freizugeben.
Natürlich kann man so ein Szenario mit Azure AD Connect und Gastbenutzern realisieren (sonst wäre der Artikel auch schon jetzt zu Ende 🙂 ).
Gehen wir von folgender Struktur in unserem Active Directory aus.
In der OU Guest Users haben wir unsere Benutzer, die wir als Gastbenutzer in unserem Microsoft 365 Tenant nutzen möchten.
Lassen wir uns also den Azure AD Connect anpassen, damit die Benutzer in dieser OU als Gastbenutzer ins Azure Active Directory synchronisiert werden. Zuerst müssen wir das entscheidende Attribut userType in unserem Cloud-Connector hinzufügen. Dieses Attribut steuert, ob der Benutzer ein „Normaler“ oder ein Gastbenutzer wird. Dazu aber später mehr. Die Anpassung wird im Synchronization Service Manager durchgeführt. Dann die Eigenschaften (Properties) des Connectors mit dem Namen eures Microsoft 365 Tenants öffnen und das Häkchen beim Attribut setzten.
Sobald wir das Attribut hinzugefügt haben, können wir dieses nun nutzen. Für die Unterscheidung ob wir einen Gastbenutzer oder einen „Normalen“ synchronisieren wollen, benötigen wir eine entsprechende Regel. Diese legen wir neu im Synchronization Rules Editor an. Wichtig ist dabei, dass wir vorher die Direction auf Outbound festlegen, bevor wir eine neue Regel erstellen.
Danach legen wir ein paar grundlegende Eigenschaften fest. Der Name kann selbstverständlich frei gewählt werden. Wichtig ist, dass wir als Connected System den Cloud-Connector ausgewählt haben und die Typen auf user bzw. person gesetzt haben. Die Precedence ist in unserem Beispiel auf 41 gesetzt. Diese muss laut Microsoft zwischen 1 und 99 liegen.
Weiterhin setzten wir noch zwei Filter, damit die Regel auch nur auf unsere gewollten AD Objekte angewendet wird und wir keine Probleme mit anderen Szenarien (z.B. Azure AD User writeback feature) bekommen.
Als letzter und wichtigster Punkt kommt nun unsere Regel, die die Unterscheidung der Benutzertypen vornimmt.
userType attributeDie Unterscheidung erfolgt durch folgende Werte:
- Normaler Benutzer:
Member - Gastbenutzer:
Guest
Wenn als userType also Guest gesetzt wird, wird dieser Benutzer als Gastbenutzer in das Azure Active Directory synchronisiert. In unserem Beispiel nutzen wir die Unterscheidung anhand der OU, indem sich das Benutzerobjekt befindet:
IIF(IsPresent([distinguishedName]),IIF(CBool(InStr(LCase([distinguishedName]),"ou=guest users,ou=aad connect,dc=frankeisel,dc=de")=0),"Member","Guest"),Error("distinguishedName is not present to determine UserType"))
Eine Anmerkung zur LCase Funktion, dadurch muss der Distinguished Name ausschließlich in Kleinbuchstaben notiert werden. Dadurch kann die Groß- und Kleinschreibung der lokalen OU geändert werden, ohne eine Änderung an der Regel im AAD Connect vornehmen zu müssen.
Danach muss eine vollständige Synchronisation erfolgen und man erhält folgendes Ergebnis.
Dieser synchronisierte Gastbenutzer kann dann ganz normal in der Microsoft 365 Welt genutzt werden, z.B. als Mitglied in einem Team hinzugefügt werden.
Somit wisst ihr nun, wie Azure AD Connect und Gastbenutzer technisch umgesetzt werden können und was dabei zu beachten ist.
Sehr gut – realy good guide. I have now implemented it and can asure you that it works. Having difficulties to find anything more substantial to do it on OU’s, I stumpled across this in german. My german is not good but having searched for long, this is really usefull and describes in details how to make it work. Very important as the article expressly says: only one rule is needed and this needs to be outbound!
Hallo Frank,
sehr guter Artikel. Kannst du mir sagen, ob bei der oben genutzten Expression auch Benutzerkonten enthalten sind, die in Sub-OUs von „Guest Users“ liegen? Also wenn bspw. Unterhalb der OU „Guest Users“ weitere OUs (bspw. Firma A, Firma B) angelegt werden, in denen sich dann jeweils die Benutzerkonten befinden.
Vielen Dank und Gruß
Stefan
Hallo Stefan,
es wird zur Prüfung die InStr Funktion genutzt, deshalb sollten weitere Sub OUs ebenfalls mit einbezogen werden. Durch die Sub OUs wird der Distinguishedname nur „länger“, die InStr Funktion findet aber weiterhin den angebebenen Teil vom Distinguishedname.
Viele Grüße
Frank
Hallo Frank,
vielen Dank für deine Rückmeldung. Ich habe gestern die bestehenden Regeln angepasst (ich hatte den usertype vorher auf Basis des Domain-Namens setzen lassen) und dein Setup funktioniert wie gewünscht (inkl. Benutzerkonten in Sub-OUs).
Vielen Dank nochmal und Gruß
Stefan
Hi Frank,
schonmal vorab: Danke für die Anleitung! Bei mir werden die User aus der OU auch synchronisiert, aber immer als normale Mitglieder. Nicht als Gäste.
Hast du da ggf. einen Denkanstoß? :/
Hallo,
dann kann es eigentlich nur an den Regeln liegen. Hast du noch weitere angepasste Regeln im Einsatz? Oder es hat sich der Fehlerteufel in den Ausdruck eingeschlichen.
Viele Grüße
Frank
Klappt bei uns sehr gut. Allerdings musst der Benutzer trotzdem als B2B-Benutzer im Entra ID Portal eingeladen werden und den versendeten Link klicken, um als Benutzer dann aktiv zu werden.
Ist dies by design?
Meiner Kenntnis nach, ist das mittlerweile „by Design“.