Gast-Identität

Die Anmeldung eines Benutzers an der Cloud erfolgt über den UPN. Ein Gast bringt seinen UPN aus seinem Heimattenant mit aber wird im Gast-Tenant natürlich als "Platzhalter" angelegt.

Einladung

Alles beginnt mit der Einladung eines Gasts im Tenant. Wer Gäste einladen kann, können Sie als Azure Administrator steuern und wenn es erlaubt ist, dann kann ein normaler Benutzer oder sogar ein anderer Gast eine bislang nicht vorhandene Person einladen. Im Azure Portal gibt es zwar zwei Punkte "New User" und "New Guest User", die aber beide den gleichen Dialog öffnen.

Normalerweise wir ein Gast "eingeladen" um eben auf die Anmeldung eines anderen Identity Providers zu setzen. Natürlich können Sie aber auch einfach einen normalen Benutzer in ihrem Tenant für eine externe Person anlegen. Der "Schlüssel" ist dabei die Mailadresse und nicht der UPN im Zielsystem. Sie können in der Ansicht der Benutzer einfach auf den "Invitation State" filtern.

Bei den Details des Benutzers sehen sie dann, dass er im Status "Invited User" ist und recht bei "Invitation accepted" ein "No" steht

Über den "Manage"-Link können Sie die Einladung jederzeit noch einmal generieren.

Interessanterweise sehen Sie den Link erst, nachdem Sie die Einladung noch mal versendet haben. Der Links relativ lange und enthält die GUID des Tenant.

https://login.microsoftonline.com/redeem?
      rd=https%3a%2f%2finvitations.microsoft.com%2f
      redeem%2f%3ftenant%3de<guid_des_tenant>
      %26user%<guid_zum_Benutzer>
      %26ticket%3xxxxxxxxxxxxxxxxxxxxxxxxx
      %26ver%3d2.0

Der Empfänger kann damit dann sein Konto "verbinden".

Bestätigung

Der Benutzer klickt auf den Link und meldet sich mit einem legitimen Konto an. Hier gibt es mehrere Optionen, die Sie dann als Administrator des Tenants auch sehen:

  • Office365/AzureAD-Konto
    Das kann ein AzureAD-Konto sein, was bei B2B-Beziehungen der Regelfall sein wird. Als "Source" steht dann ein "External Azure Active Directory" beim Gastkonto
  • Microsoft Konto
    Wenn der Empfänger sich mit einem privaten Microsoft Konto, vormals Passport oder LiveID, anmeldet, dann steht hier ein "Microsoft Account". Lassen sie sich nicht irritieren, dass der UPN hier ein "gmail.com" hat.
  • OneTimePassword
    Seit Anfang 2021 können Gäste sich auch über ein per Mail zugesendetes "Einmalkennwort" anmelden. Damit funktioniert dann wirklich jede Mailadresse als Gast.
  • Google Konto
    Der Gast kann sich auch mit einem Google Firmen-Konto anmelden. Allerdings sind dazu sowohl bei Google als auch in Azure weitere Einstellungen erforderlich:
    Hinzufügen von Google als Identitätsanbieter für B2B-Gastbenutzer
    https://docs.microsoft.com/de-de/azure/active-directory/external-identities/google-federation
  • Facebook-Konto
    Als Betreiber einen Tenants können sie auch Facebook als Identity-Provider vertrauen. Auch hierzu müssen Sie allerdings erst eine Einrichtung vornehmen
    Hinzufügen von Facebook als Identitätsanbieter für externe Identitäten
    https://docs.microsoft.com/de-de/azure/active-directory/external-identities/facebook-federation

Es sind noch weitere direkte Federation-Provider möglich, z.B. wenn eine andere Firma mit ADFS arbeitet.

Sie können, wenn dies gewünscht ist, sogar einen "Self Service" einrichten.

Funktionstest

Danach ist der Gast ein "fast" normales Konto in ihrem Azure Active Directory und kann auf Informationen und Apps zugreifen, für welche er berechtigt wird. Er kann auch in Gruppen und Teams aufgenommen werden. Eine einfache Kontrolle der Funktion ist z-B. über https://myapplications.microsoft.com/ möglich. Sie können sich hier mit ihrem primären Konto anmelde und sehen ihre Kontoeinstellungen und auch ein Wechsel in die andere Organisation ist schnell möglich.

Als Azure-Admin kann ich nun auch im Gasttenant sehen, dass sich der Gast angemeldet hat.

Ich habe noch keinen Weg gefunden, wie ein Admin des Heimattenant solche Anmeldung am Gast-Tenant nachhalten kann. Allerdings kann ein Anwender ermitteln, in welchem anderen Tenant er als Gast Mitglied ist. Daher sollte es auch für den Admin möglich sein, solche "Fremd-Aktivitäten" zu verfolgen.

Lizenz

Jeder authentifizierte Zugriff eines Kontos auf Dateien durch einen Benutzer muss durch eine gültige Lizenz abgedeckt sein. Eine natürlich Person muss aber natürlich nicht doppelt lizenziert sein. Wer mit einem Heimatkonto schon eine Office 365 Lizenz hat, ist damit auch für die Mitarbeiter als Gast in einem anderen Tenant lizenziert. Allerdings gibt es schon unterschiede, wenn die beiden Tenants unterschiedliche Anforderungen an die Sicherheit haben. Wenn der Heimat-Tenant "nur" Office 365 E3 hat aber der Gasttenant z.B. eine höhere Sicherheit per Conditional Access erzwingt, dann muss man schon genauer hinschauen.

Früher gab es nur eine 1:5-Rate für Gäste, d.h. auf einen aktiven lizenzierten Benutzer sollten nicht mehr als 5 Gäste kommen. Gerade kleine Firmen mit wenigen Benutzern stoßen hier schnell an ihre Grenzen. Dann kann der Wechsel zu eier "Linked Subscription" sinnvoll sein


Quelle https://portal.azure.com/#blade/Microsoft_AAD_IAM/CompanyRelationshipsMenuBlade/B2BLinkedSubscriptions

So können Sie die ersten 50.000 MAUs  (Monatlich aktiven Gastbenutzer) sogar kostenfrei betreiben und für weitere Benutzer kosten dann 0,2 oder 1,2ct/MAU/Monat. Das ist interessant, wenn sie die Gäste mit AzureAD P1 oder P2-Funktionen versehen müssen.

Ich bin kein Lizenzspezialist und die Informationen können schon wieder veraltet sein. Bitte informieren Sie sich über ihren Vertriebsweg

Lifecycle und Exit-Management

Zu einem sauberen und sichereren Betrieb gehört auch eine klare Definition des Lebenszyklus eines Konto. Wenn für eine B2B Zusammenarbeit die Person in der Stammfirma seinen Arbeitgeber verlässt, dann sollte davon ausgegangen werden, dass auch das Anmeldekonto in dem anderen Tenant deaktiviert oder gelöscht wird.

ViVielleicht müssen Sie sich dieses Verhalten von der anderen Firma aber auch bestätigen lassen.

Zumindest sollte es auch eine Information an sie geben, dass hier ein Konto entfernt werden könnte. Dies gilt insbesondere, wenn Sie dem Gast sogar eine Lizenz zugewiesen haben. Eine Auswertung auf die Anmeldungen von Gästen ist daher durchaus sinnvoll und genauso könnten Sie die Gäste regelmäßig anschreiben und ihre Existenz bestätigen.

Wer erst gar kein "Self Provisioning" von Gästen durch Anwender zulässt und einen eigenen Prozess aufgesetzt hat, wird hier sicher auch das Deprovisioning abdecken. Sie müssen natürlich ihre vorhandenen Prozesse zur Anlage von Benutzer, Freigabe von Diensten etc. entsprechend erweitern. Es gibt Firmen, bei denen ein Gast-Benutzer ein ganz normaler IT-Auftrag mit "Beantragender Person", Freigabe-Prozess und Protokollierung ist. Andere nutzen Workflow-Lösungen, um den Prozess möglichst zu automatisieren und zu beschleunigen. All dieses Prozesse haben natürlich den Nachteil, dass die Anwender den Einstiegpunkt kennen müssen.

Da kann es doch wieder einfacher sein, die Funktion "Guest Access" einfach auf Teams, SharePoint und OneDrive freizugeben aber über entsprechende Regeln wie Conditional Access zusätzlich abzusichern. Auch der Schutz von Dokumenten durch Azure Information Protection kann ein Weg sein, Gäste einfach zuzulassen und die Informationen besser zu schützen.

Über die Nutzung der Gast-Benutzer führt das AzureAD natürlich Protokoll, d.h. die IT-Security kann Berichte anfertigen, in denen die Nutzung dargestellt wird. Solche Auswertungen sind auch die Basis um die Konten auch wieder zu entfernen. Oft bekommen Sie als Firma gar nicht mit, dass das Gastkonto gar nicht mehr verwendet wird, weil das dazugehörige Anmeldekonto in dem anderen Azure AD Directory schon gar nicht mehr existiert. Es gibt hier leider keinen Abgleich und den darf es so auch nicht geben. Stellen Sie sich vor, ein Benutzer im anderen Tenant wird gelöscht und damit würde auch das Gast-Konto in ihrem Tenant verschwinden. Sie könnten dann z.B. gar nicht mehr die "Audit Logs" nach diesem Benutzer durchsuchen oder in Teams erkennen, ober der Gast hier eingeladen war. Solange mit dem Gast also noch Berechtigungen und Protokolleinträge verbunden sind, muss zumindest das Gast-Konto in ihrem Tenant bestehen bleiben.

Allerdings "altert" dieses Konto natürlich schon. Wenn der reale Benutzer z.B. heiratet und seinen DisplayNamen ändert, dann ändert sich diese Bezeichnung nicht im Gast-Konto. Durch die natürliche Fluktuation bei Mitarbeitern und befreundeten Unternehmen sollten Sie also schon prüfen, welche Gäste noch erforderlich sind. Es gibt hier, wie auch bei Active Directory Konten, verschiedene Ansätze:

  • Last Login Date
    Wenn ein Konto sich längere Zeit nicht mehr anmelden, könnte es obsolet sein und sollte zumindest überprüft werden.
  • Keine ACLs mehr
    Wenn das Konto nur noch als Hülle existiert aber keine Rechte mehr hat, dann könnte es auch entfernt werden. Ich kenne viele Gäste, die nur in genau einem Team für die Dauer eines Projekts einen Zugriff bekommen haben und nach Abschluss des Projekts wird das Teams archiviert und später gelöscht. Spätestens dann könnt der Gast entfernt werden. Wobei es gar nicht so einfach ist, eine Liste der Zugriffsrechte eines AzureAD-Kontos zu erhalten.
  • Regelmäßige Erneuerung
    Ein anderer Weg besteht darin, dass die Person gefragt wird, die damals die Neuanlage des Gast-Kontos beantragt hat. Wobei das knifflig sein kann, denn ein einmal angelegter Gast kann natürlich auch von anderen Nutzern referenziert werden. Oft ist die erste Person gar nicht mehr alleine zuständig. Daher sind die beiden ersten Punkte vermutlich ein besserer Ansatz.
  • Deaktivieren vor Löschen
    Sie können als Tenant Administrator ein Gast-Konto aber jederzeit erst einmal deaktivieren. So verhindern Sie die Nutzung erst einmal und können den "Cleanup" dann ohne Risiko noch etwas in die Zukunft verschieben.

Eine "Pflicht" zum Aufräumen oder Löschen gibt es seitens Microsoft nicht. Aber es könnte eine Lizenzfrage als auch eine Sicherheitsüberlegung sein, nicht mehr benötigte Gastkonten zu entfernen.

Denken Sie auch an den Datenschutz. Wenn ihr Gastkonto auch Vorname, Nachname, die MFA Mobilfunknummer oder andere "personenbezogene Daten" hat, dann müssen Sie diese vielleicht zügig löschen.

Anwender löscht eigenen Gast

Der Fall dürfte eher selten passieren, dass ein Anwender seinen Zugang in einem anderen Tenant selbst löscht. Aber als Anwender können Sie natürlich auch selbst steuern, ob sie noch länger Gast in einem anderen Tenant sein wollen. Das geht über die eigene Kontoverwaltung unter:

https://myaccount.microsoft.com/organizations

Sie sehen dann alle Organisationen, in denen Sie ein Gastkonto haben und können die Organisation auch verlassen.

In der anderen Organisation wird das Gastkonto wie ein normales Benutzerkonto für 30 Tage nach "gelösche Objekte" verschoben, ehe es komplett entfernt wird. Der Azure-Admin kann das Gastkonto dort natürlich auch beschleunigt löschen

Stammdaten-Management

So ein Gastkonto hat ja durchaus einige interessante Felder, die ein Admin bei der Einladung mit ausfüllen kann. Ich habe daher im Heimattenant alle sichtbaren Felder ausgefüllt.

Der Gast wurde dann von einem Tenant eingeladen und schon bei der Content-Anfrage ist deutlich, welche Informationen der anderen Tenant vom Anwender abfragt:

Das sind natürlich deutlich weniger Informationen. Nach dem Abschluss der Einladung habe ich dann im Gasttenant die Eigenschaften angeschaut. Mich hat interessiert, welche Felder beim Gastkonto nun vom Heimattenant übernommen wurden:

Das Ergebnis ist ernüchternd. Es wurde überhaupt nichts mitgenommen.

Aus Datenschutzüberlegungen ist dies natürlich perfekt, weil das Gast-Konto damit keinerlei Informationen aus dem Heimattenant bekommt.

Microsoft beschreibt das Verhalten zumindest für das Feld "Mail".

Wenn ein Gastbenutzer Ihre Einladung annimmt und danach seine E-Mail-Adresse ändert, wird die neue Adresse nicht automatisch im Gastbenutzerobjekt in Ihrem Verzeichnis synchronisiert. Die E-Mail-Eigenschaft wird über die Microsoft Graph-API erstellt. Sie können die Maileigenschaft über die Microsoft Graph-API, das Admin Center von Exchange oder Exchange Online-PowerShell aktualisieren. Die Änderung wird im Azure AD-Gastbenutzerobjekt widergespiegelt.
Quelle: https://docs.microsoft.com/de-de/azure/active-directory/external-identities/user-properties#can-i-update-a-guest-users-email-address

UPN-Änderung

Bei der Recherche zur Seite UPNChange und Applikationen hat mich natürlich auch das Verhalten bei Gastkonten interessiert. Ich habe das bestehende Testkonto genommen, und den UPN geändert. Dann habe ich mich als Anwender wieder mit dem neuen UPN an "myapplications.microsoft.com" angemeldet und den Tenant-Wechsel vollzogen. Ich hatte zwar weiter keine Apps aber das Logo und der Firmenname zeigt es mir an:

Wenn ich dann aber die Eigenschaften des Gasts im AzureAD anschaue, dann sehen Sie hier noch den alten UPN als Bestandteil des Gast-UPNs.

Der neue UPN wurde nicht übertragen und auch die zeitgleich geänderte Mailadresse, Vorname und Nachname wurde nicht aktualisiert.

Details im Hintergrund

Damit stellt sich die Frage, wie das eine AzureAD mit dem Gastkonto die Verbindung zum Anmeldekonto im Heimatforest aufrecht erhält. Der mit #EXT#@<tenantname>.onmicrosoft.com erweiterte Anmelde-UPN des Heimatforest kann es nicht sein. Eine Ausgabe mit Get-AzureADUser liefert:

PS C:\> Get-AzureADUser -SearchString test1 | fl *

ExtensionProperty              : {[odata.type, Microsoft.DirectoryServices.User], [createdDateTime, 17.02.2021
                                 11:50:43], [employeeId, ], [onPremisesDistinguishedName, ]...}
DeletionTimestamp              :
ObjectId                       : d23521d9-cfc7-4201-94d2-de71e2b49cb1
ObjectType                     : User
AccountEnabled                 : True
AgeGroup                       :
AssignedLicenses               : {}
AssignedPlans                  : {}
City                           :
CompanyName                    :
ConsentProvidedForMinor        :
Country                        :
CreationType                   : Invitation
Department                     :
DirSyncEnabled                 :
DisplayName                    : test1
FacsimileTelephoneNumber       :
GivenName                      :
IsCompromised                  :
ImmutableId                    :
JobTitle                       :
LastDirSyncTime                :
LegalAgeGroupClassification    :
Mail                           : test1@msxfaq.net
MailNickName                   : test1_msxfaq.net#EXT#
Mobile                         :
OnPremisesSecurityIdentifier   :
OtherMails                     : {test1@msxfaq.net}
PasswordPolicies               :
PasswordProfile                :
PhysicalDeliveryOfficeName     :
PostalCode                     :
PreferredLanguage              :
ProvisionedPlans               : {}
ProvisioningErrors             : {}
ProxyAddresses                 : {SMTP:test1@msxfaq.net}
RefreshTokensValidFromDateTime : 17.02.2021 11:50:43
ShowInAddressList              : False
SignInNames                    : {}
SipProxyAddress                :
State                          :
StreetAddress                  :
Surname                        :
TelephoneNumber                :
UsageLocation                  :
UserPrincipalName              : test1_msxfaq.net#EXT#@netatwork.onmicrosoft.com
UserState                      : Accepted
UserStateChangedOn             : 2021-02-17T11:51:36Z
UserType                       : Guest

PS C:\> (Get-AzureADUser -SearchString test1 ).ExtensionProperty

Key                         Value
---                         -----
odata.type                  Microsoft.DirectoryServices.User
createdDateTime             17.02.2021 11:50:43
employeeId
onPremisesDistinguishedName
userIdentities              []

Ich habe hier kein Feld gefunden, welches als Link auf das eigentliche Anmeldeobjekt dient. Insofern ist auch unklar wie mein Gast-Tenant den Anwender wiedererkennen kann, wenn er von seinem Heimattenant mit einem neuen UPN kommt.

Weitere Links