BestPractise: How to provision B2B-User in AzureAD Enterprise Applications
Wenn man über externe Identitäten in Azure spricht, sind es meistens all jene Gastbenutzer, ob sie zu Partnerorganisationen, Tochtergesellschaften oder Dienstleistern gehören spielt hier mal keine Rolle.
Möchte man diese sogenannten B2B-Benutzer in bestimmte Enterprise Applikationen im AzureAD provisionieren (Benutzerbereitstellung der B2B-AzureUser in SAAS-Anwendung), stellt das die Azure-Administration vor so manche Herausforderungen. Umso wichtiger ist es, die Auswahl der zukünftigen Anwendung und das Anforderungsmanagement auf solche Herausforderungen anzupassen.
Um das besser zu verstehen, ein kurzer "DeepDive" in den Prozess einer solchen Provisionierung im AzureAD. Sollte dir das vorgehen schon bekannt sein, kannst du auch direkt zum How-To springen
Um User über den Azure AD Provisionierung-Service für SAAS-Applikationen bereitzustellen benötigt es ein SCIM (Cross-Domain-Identity-Management- Endpunkt) auf Seitens des SAAS-Anbieters. Ist das nicht gegeben, ist es für den Provisionierung-Service nicht möglich, mit der Gegenseite über diese API zu sprechen. Wir gehen nun mal von aus, dass das SCIM in der SAAS-Anwendung vorhanden ist.
Ausgangs-Szenario: Unsere Gastbenutzer wurden schon manuell über einen Einladungslink bzw. über zuvor konfigurierte Automatisierungen zum Azure-Tenant hinzugefügt. Ebenso befinden sich diese User in den vorgesehenen Gruppen, die später für die Provisionierung ausgewählt werden. Wichtig ist noch zu erwähnen, die Gastbenutzer sollten keine M365-Lizenz bekommen. Eine mögliche Bereitstellung einer AzureAD P1 oder P2 Lizenz (z. B. für MFA etc.) sind jedoch möglich, aber nicht zwingend notwendig. Microsoft hat hier ein neues Lizenzverfahren "MAU", welches Gastbenutzer lizenziert.
Um die SAAS-Applikation mit den von ihr benötigten Attributen des AzureAD-Gastbenutzer zu versorgen, werden ihr diese Daten über das vom Administrator konfigurierte Attributs-Mapping im Bereich der Enterprise Applikationen bereitgestellt. Die Benutzerdaten werden - wie in der Abbildung oben ersichtlich - über die GraphAPI an den Provisioning Service gesendet. Dieser führt im Hintergrund im Mapping die Verlinkung mit den erhaltenen Benutzerdaten auf die benötigten Attribute in der SAAS-Applikation durch und sendet die Benutzerdaten über den Target-API-Connector an die SAAS-Applikation weiter. Neben der Synchronisierung der reinen Werte hinter den Attributen lassen sich auch Werte-Manipulationen im Synchronisation-Prozess durchführen. Das ist hilfreich, falls die SAAS-Anwendung die Attributwerte in anderer Form benötigt. Es kann aber auch das Risiko bergen, das doppelte, identische Werte in die SAAS-Applikation fließen und Verlinkung nicht mehr stimmen, sofern es keinen Kontrollprozess auf der Anwendungsseite oder im Mapping gibt, die auf Eindeutigkeit des Wertes prüft. Um diesem Problem aus dem Weg zu gehen, sollte man schon im Voraus im AzureAD ein Attribut für das Mapping des Benutzers finden, welches eindeutig ist uns als UserIdentifier-Attribut fungieren kann. In meiner nachfolgenden BestPractise Lösung für die Gastbenutzer-Bereitstellung ist das in den meisten Fällen mit dem AzureAD-Attribut OriginalUserPrincipalName zu erreichen.
In meinem Arbeitsalltag als IT-Architekt habe ich schon verschiedenste SAAS-Anwendungen für die Benutzerbereitstellung an ein AzureAD angebunden. Aber jede SAAS-Anwendung fordert andere Voraussetzungen, wie die Userdaten in der Anwendung ankommen. Ein gutes Beispiel ist hier die SAAS-Anwendung Atlassian Cloud des Softwareherstellers Atlassian. Anhand der Atlassian Cloud möchte ich Euch meine BestPractise-Strategie für die Userbereitstellung über das AzureAD zeigen, mit Fokus auf B2B-Benutzer. Denn möchte man in SAAS-Anwendungen mit über das AzureAD eingeladenen Partner oder Dienstleistern zusammenarbeiten, kommt man um eine gut durchdachte Strategie nicht herum.
Die BestPractise-Strategie für eine Benutzerbereitstellung anhand der Atlassian Cloud
(Hinweis: In der BestPractise-Strategie gehe ich aus Zeitgründen nicht auf jeden Punkt zur vollständigen Konfiguration einer solchen Integration in das AzureAD ein. Weitere Informationen erhaltet ihr in der offiziellen Dokumentation von Microsoft oder über den Hersteller der SAAS-Lösung.)
Liest man sich das Tutorial zum Konfigurieren der automatischen Benutzerbereitstellung für Atlassian Cloud in der Microsoft Dokumentation durch, wird beim Benutzer-Mapping folgendes, wichtigstes Attribute für ein erfolgreiches Mapping von der Atlassian Cloud verlangt:
emails[type eq "work"].value
Dieses Attribut nutzt die Atlassian Cloud zum eindeutigen Authentifizieren des durch das AzureAD bereitgestellten Benutzers beim Login. Aktiviert man später die SSO-Funktionalität, referenziert dort der Claim nameidentifier auf das Attribut.
Zurück bei der Benutzerbereitstellung ist dieses Attribut aber nicht das einzige Kriterium, welches erfüllt sein muss, dass die provisionierten Benutzer aus dem AzureAD in der Atlassian Cloud zum einen sichtbar und zum anderen voll funktionsfähig sind.
So müssen die Benutzer noch zusätzlich mit einer domain-verifizierten Emailadresse im schon erwähnten "emails"-Attribut in der Atlassian Cloud ankommen.
Das klingt im ersten Moment recht einfach, wenn einem die Domain gehört und somit der benötigte TXT-Rekord-Eintrag für die Validierung schnell gesetzt ist.
Bei eingeladene Gastbenutzer (Azure B2B-Gastbenutzer) gestaltet sich das aber etwas schwerer. Externe Gastbenutzer haben nach dem erfolgreichen Onboarding in Azure erst einmal die externe Email-Adresse auf dem Attribut userprincipalname, über die sie ursprünglich eingeladen wurden. Und genau den Wert dieses Attributs möchte die Atlassian Cloud laut Microsoft Dokumentation auch erhalten.
Führt man die Benutzerbereitstellung testweise durch, stellt man schnell fest, dass die Gastbenutzer in der Atlassian Cloud nicht auffindbar sind, jedoch der Bereitstellungsdienst im AzureAD nicht unbedingt ein Fehler gemeldet hat.
Die Ursache ist schnell erklärt. Der Bereitstellungsdienst konnte in diesem Fall die Benutzerdaten erfolgreich über die API-Schnittstelle an die Atlassian Cloud übermitteln, auf der Gegenseite hatte die Atlassian Cloud aber hier keine validierte Domains in den bereitgestellten Emailadressen der User gefunden und somit den Prozess mit folgendem Fehler im Log übersprungen:
User with ID 6903457-1a8c0-4a34-8ef8-78763423038b7, primary email mustermann@muster-gastfirma.de, is not a managed user
Ab diesem Moment heißt es sprichwörtlich "break the rules". Die Dokumentation hilft uns da nicht mehr viel weiter und der Atlassian Support vertröstet einen aktuell nur mit einem Link zu einem offenen Feature-Request.
Folgende Möglichkeiten stehen uns auf der Seite von Azure noch zu Verfügung:
- Transformation des Azure-Attributs zur gewünschten validierten Domain
oder
- Zuweisung eines anderen AzureAD-Userattributs auf dem Atlassian Attribute "email"
Eine Transformation ist bei diesem, für die Atlassian Cloud eindeutigen Attribut nicht die beste Lösung. Es könnten, wie schon vorher kurz angesprochen, mehrere Mappings auf eine Atlassian-Identitäten stattfinden, weil keine Kontrollstruktur zur Überprüfung vorhanden ist.
Somit bleibt nur noch letztere Möglichkeit, die Zuweisung eines anderen AzureAD-Userattributs auf dem Atlassian Attribut "email"
Und hier hat uns Microsoft eine Lösung im Gepäck, die meiner Meinung nach für viele solcher Probleme ins Auge gefasst werden kann.
Jeder Benutzer, egal ob Gastbenutzer oder Benutzer bekommt beim Onboarding in Azure eine Emailadresse mit der die initialen Tenant-Domain bereitgestellt.
Bei Gästen sieht der Aufbau wie folgt aus:
mustergast_musterfirma_de#EXT@muster-tenant.onmicrosoft.com
Da die initiale Tenant-Domain uns gehört und wir Zugriff auf die DNS-Einstellungen haben, können wir diese neben unseren anderen Custom-Domains ebenfalls in der Atlassian Cloud validieren. Mit dieser Lösung haben nun alle AzureAD-Benutzer eine validierte Email-Adresse und können in der Atlassian Cloud erfolgreich bereitgestellt werden.
Bleiben nur noch die Fragen offen, hinter welchem AzureAD-Attribut verbirgt sich die Email-Adresse mit der initialen Standard-Domain und wie ist ein vollständiger Emailfluss für Benachrichtigungen aus Atlassian Produkten heraus sichergestellt?
Mit der gefundenen Stelle in der Microsoft-Dokumentation ist das Attribut-Thema auch schnell vom Tisch. Da das Attribut "userPrincipalName" bei Gastbenutzer-Objekten kein #EXT# enthält sollte man stattdessen das Quellattribut "originalUserPrincipalName" nutzen. Der Wert bleibt hier unversehrt und zusammengebaut erhalten.
Das die Benachrichtigungen aus den Atlassian Produkten die externen Postfächer der Gastbenutzer erreichen, muss der Mail-Flow für die Gast-User etwas angepasst werden.
Wichtig ist hier aber zu beachten: bevor der Befehl ausgeführt werden kann, muss der Gast-User beim Attribut "UserType" auf "Member" gesetzt sein. Nachträglich kann man den Wert des UserTypes aus sicherheitstechnischen Gründen wieder auf Guest zurückstellen.
Connect-AzureAD
Set-AzureADUser -ObjectId XX -UserType Member
Dadurch wird der User ein "Email-User", kann nun im Exchange bearbeitet werden und wird so auch unter den Kontakten im Admin-Center des Exchange gelistet.
Um nun den Mail-Flow über Exchange Online zum Externen Postfach des Gast-User möglich zu machen, muss das Attribut "PrimarySMTPEmailAddress" folgenden Standard-Wert haben.
PrimarySMTPEmailAddress: mustergast_musterfirma_de#EXT@muster-tenant.onmicrosoft.com
Zum Übeprüfen, ob das der Fall ist, können wir uns das MailUser-Objekt nur mit dem einzelnen Wert ausgeben lassen.
Connect-ExchangeOnline (sofern keine aktuelle Session mehr aktiv ist)
Get-MailUser -Identity (kann UPN,Emailadresse oder der Name sein) | select PrimarySmtpAddress
Falls nicht der erwartete Wert angezeigt wird, kann er nachträglich angepasst werden.
$PrimarySmtpAddress = Get-MailUser -Identity (kann UPN,Emailadresse oder der Name sein) | select PrimarySmtpAddress
Set-MailUser -Identity (kann UPN,Emailadresse oder der Name sein) -PrimarySmtpAddress $PrimarySmtpAddress
Da das Attribut "ExternalEmailAddress standardmäßig den gleichen Wert wie die PrimarySmtpEmailAdresse hat, muss der Wert hier abschließend auch noch geändert werden.
$ExternalEmailAdress = Get-MailUser -Identity (kann UPN,Emailadresse oder der Name sein) | select OtherMail
Set-MailUser -Identity (kann UPN,Emailadresse oder der Name sein) -ExternalEmailAddress
Etwas Geduld ist dabei jedoch gefragt. Der Mailflow funktioniert meistens nicht sofort. Es kann also bis zu 30 min. dauern, dass eine Testmail über die SMTP-Emailadresse das externe Postfach erreicht.