AzureAD Identitäten

Durch die Verlagerung von Daten auf Server in die Cloud sind nicht nur innerhalb der Firma neue Möglichkeiten der Zusammenarbeit entstanden. Da die Dienste generell "im Internet" stehen und oft auch ein Zugang per Browser möglich ist, können Sie auch Personen aus anderen Firmen einen Zugriff erlauben und eine engere Zusammenarbeit erlauben. Diese Seite betrachtet die verschiedenen Varianten von Internen Anwendern, "Gastbenutzer", "Federation", B2B Verzeichnissen und anonymen Anwendern.

Hintergründe

Wenn ein Anwender/Client auf eine Information oder einen Service zugreift, dann liefern Webseiten wie die MSXFAQ ihre Informationen anonym aus. Da auch anonyme Seiten mit Kosten verbunden sind, versuchen die Betreiber mit Werbung und den Verkauf von Tracking-Informationen den Aufwand zu finanzieren. Viel wichtiger sind aber Informationen, die nur nach erfolgter Authentifizierung bereitgestellt werden. Und für eine Authentifizierung braucht es mehrere Bausteine

  • Identität
    Wenn Sie Daten schützen, dann erfolgt dies über ACLs und damit sie in ihrem Tenant oder ihrer Anwendung einer Person und über Gruppenmitgliedschaften ein Recht zuweisen können, muss es dieses Objekt geben. On Premises was das dann ein Benutzer oder Dienstkonto in einem Active Directory oder einer "vertrauten" anderen Domäne oder Applikationsbezogen eine Identität einer Datenbank. Damit stellt sich auch die Frage nach dem Provisioning dieser Objekte, d.h. welcher Prozess legt diese an, aktualisierte diese z.B. bei Heirat, und wann werden die Konten wieder entfernt (Exit-Management)
  • Authentifizierung
    In der einfachsten Form ist bei dem Benutzer auch gleich das Kennwort hinterlegt, Dann kann der Anwender sich nach der Anlage des Kontos direkt anmelden. Das Problem dieser "Kennwort pro Dienst" ist aber nicht nur, dass sich der Anwender idealerweise pro Dienst ein Kennwort merkt, da ansonsten ein unsicherer Dienst den Benutzer auch bei anderen Diensten kompromittiert. Für den Betreiber der Plattform stellt sich aber auch noch die Frage bei einem "Kennwort Reset" oder auch die schnelle deaktivieren, wenn der Mitarbeiter das andere Unternehmen womöglich zu einem Mitbewerber verlassen hat und daher keinen Zugriff mehr erhalten darf.
    Bei einer interne "Vertrauensstellung" mussten Sie ja auch keine Kennworte pflegen, sondern vertrauten der andere Domäne.
  • Conditional Access
    Allein ein gültiger Benutzername und ein Kennwort reichen vielen Diensten nicht mehr aus. Besonders schützenswerte Daten bedürfen einem zweiten Faktor, da einfache Zugangsdaten und Kennworte doch zu schnell abgephisht werden. Das ist insbesondere dann von Interesse, wenn der vertraute Anmeldedienst kein MFA vorschreibt und Sie daher diese zusätzliche Überprüfung selbst anfordern müssen

Diese Herausforderungen sind übrigens nicht nur für B2B-Aufgaben von Belang sondern sind auch für B2C-Szenarien interessant. Wenn die Mehrzahl der Anwender z.B. sowieso über ihr SmartPhone ein "Google-Konto" oder "Apple-ID" hat, und über soziale Medien viele Firmen mit einem Facebook-Login, Twitter-Konto, LinkedIn-Konto aufwarten können, dann können Sie als Anbieter auch diese Anmeldedienste integrieren und für den Nutzer die Anmeldung vereinfachen. Wenn Sie sich heute bei einer Webseite mit einem anderen "Anmeldedienst" anmelden, dann bekommen Sie als Anwender ja gerade die Rückfrage (Consent), dass sie ausgewählte Daten zu ihrer Identität an den Anbieter übermitteln bzw. diesem den Zugriff auf diese Daten erlauben. So kann der Ziel-Service schon das "Provisioning" vorwegnehmen und einen Benutzer dynamisch anlegen.

Zudem senden Sie bei der nächsten Zugriff auf den Dienst neben ihrer ID (Meist die Mailadresse bzw. der gleichnamige und weltweit eindeutige UPN) auch ein vom Authentifizierungsdienst signiertes OAUTH-Token mit. Der Service kann durch den Trust zum Aussteller damit Sie als Person auch gleich identifizieren ohne je ihr Kennwort zu wissen.

Vor allem im B2B-Geschäft möchte man nicht nur aus Bequemlichkeitsgründen vermeiden, dass Benutzer sich mehrfach anmelden und getrennte Zugangsdaten bei verschiedenen Diensten nutzen. Viel wichtiger ist hier auch das EXIT-Management, d.h. dass ein Benutzer nicht mehr auf Daten bei einem verbundenen Unternehmen zugreifen kann, wenn er im eigenen Unternehmen geblockt wurde.

Azure Active Directory

Mit der Verlagerung von Diensten in die Cloud verändern sich natürlich auch die Plattformen zur Identitätsverwaltung und Authentifizierung. Mit Office 365 oder Azure-Diensten ist der Dreh und Angelpunkt immer das Active Directory in der Cloud oder je nach Situation auch weitere Verzeichnisdienste. Dis auf wirklich ganz wenige Ausnahmen (z.B. anonyme Meeting-Teilnehmer) ist für die Nutzung von Diensten in der Cloud immer eine Authentifizierung erforderlich und damit ein Konto in einem der möglichen Tenants.

Jeder Office 365 Tenant hat automatisch ein zugeordnetes Azure Active Directory mit der "Basic-Lizenz". Für erweiterte Aufgaben wie z.B. Multi Faktor Authentifizierung, Conditional Access, Azure Information Protection sind zusätzliche Lizenzen wie "Azure AD Plan1" oder "Plan2" erforderlich. Für jeden Zugriff ist zu unterscheiden, wo und durch wen das entsprechende Konto angelegt wurde und mit welchem Konto die Authentifizierung erfolgt. Das ist nicht nicht immer das gleiche Konto:

Aus Vereinfachungsgründen haben ich von ADSync ebenfalls übertragene Computerkonten (Devices) und Gruppen nicht aufgeführt. Die verschiedenen Exchange Benutzer (MailUser, MailboxUser, RemoteMailboxUser) zählen als "Benutzer". Für die weitere Betrachtung sind folgenden Identitäten relevant, die von Benutzern oder als Dienstkonto in einem Tenant auf Daten zugegriffen haben.

User KontoTyp Verwaltung im Tenant 1

1

Cloud Benutzer

Der erste Benutzer in einem Office 365 Tenant ist immer ein Administrator mit einem "Cloud Only"-Konto und einer "@%tenantname%.onmicrosoft.com-Adresse. Sie sind gut beraten diesen Administrator gut zu sichern und nicht im Tagesgeschäfts zu verwenden.

Aber auch sonst kann es in einem Tenant noch weitere "Cloud only" Benutzer geben. Dies gilt für alle Umgebungen ohne ADSync. Die Authentifizierung erfolgt ebenfalls in der Cloud und Conditional Access ist möglich. Das Konto kann natürlich auf Daten und Dienste im eigenen Tenant zugreifen.

2

DirSync Benutzer

Die weit häufigere Benutzerklasse sind "DirSync"-Benutzer, die durch ADSync aus einem lokalen Active Directory synchronisiert werden. Die Authentifizierung kann per Password Hash Sync (PHS) in der Cloud erfolgen. Alternativ ist auch eine OnPremises Anmeldung über Pass-Through Authentifizierung (PTA) oder ADFS möglich. Conditional Access-Regeln sind in der Cloud oder einen lokalen ADFS-Service möglich.

Die Konten können auf Daten im eigenen Tenant zugreifen.

3

externer Gast-Benutzer

Sie können in ihrem Tenant über die "Gast-Benutzer" einen Verweis auf aktive Anmeldekonten in einem anderen Tenant verwalten. Über den Gast-Zugriff können Sie diesen fremden Benutzern explizite Berechtigungen auf z.B. Microsoft Teams, Daten in SharePoint etc. gewähren. Natürlich muss es zu einem Gast-Konto in ihrem Tenant einen entsprechenden Benutzer in einem anderen Tenant geben. Das Gast-Konto hat kein Kennwort, sondern der Anwender meldet sich in seinem Home-Tenant an.

Das beschreibt auch die Situation, wenn ihre eigenen Anwender (Typ 1 und 2) sich in anderen Tenants anmelden.

4

Tenant2-Benutzer

Benutzer in einem anderen Tenant2 können natürlich auf ihre eigenen Daten zugreifen. Aber ohne entsprechendes Gast-Konto in ihrem Tenant1 ist kein authentifizierter Zugriff möglich. Der Admin von Tenant1 kann einstellen, ob Gast-Konten quasi "still" im Hintergrund angelegt werden, wenn ein Anwender in Tenant 1 einen Benutzer aus Tenant2 zur Zusammenarbeit einlädt.

5

interne Gast-Benutzer

Analog zum Benutzer Typ3 "Externer Gast-Benutzer" gibt es aber auch noch die Möglichkeit über das AzureAD-Portal einen Gast-Benutzer samt Kennwort anzulegen. So können Sie Benutzern außerhalb ihres Tenant Zugriff auf einzelne Bereiche geben, auch wenn diese noch kein eigenes AzureAD haben. Sie erscheinen dann als "Member" aber im Office 365 Portal sehen Sie wie "Cloud Benutzer" aus und können sogar Lizenzen bekommen.

6

Microsoft Konto, Google Konto u.a.

Ein Gast-Konto muss nicht immer auf ein Konto in einem anderen Tenant verweisen. Es gibt auch andere Identity-Provider, wie z.B. "Microsoft Konten", auch bekannt als Passport-Konto oder LiveID, die als Authentifizierungsdienst erlaubt sind. Es ist abzusehen, dass sogar jede Mailadresse als Gast-Konto genutzt werden kann, wenn Office 365/Azure beim Zugriff ein Einmal-Kennwort z.B. per Mail zustellt. Denkbar sind aber alle OAUTH-Dienste wie Facebook, Google etc.)

7

Application eigener Tenant

Der Zugriff auf Daten kann aber nicht nur an Benutzer im Tenant gewährt werden, sondern auch direkt an Applikationen gebunden werden.

8

Application anderer Tenant

Die Applikationen müssen dazu nicht einmal in Office 365 Tenant des Nutzers veröffentlich sein, sondern können auch in anderen Dienste gehostet werden, die dann durch den Benutzer oder den Administrator den Zugriff darauf erhalten.

9

Anonymer Benutzer

Beim Zugriff auf Daten ist meines Wissens ein Benutzer oder Gastbenutzer im Tenant erforderlich, in dem die Daten liegen. Nur so kann der Zugriff dauerhaft gesteuert und auch nachverfolgt (Auditing/Compliance) und blockiert werden. Allerdings gibt es auch einige Zugriffe auf Daten, bei denen keine explizite Anmeldung erforderlich ist. Fast immer sind es dabei aber sehr flüchtige Informationen:

  • Federation in Teams und Skype for Business
    Die Präsenzanzeige aber auch die Übertragung von Kurzmitteilungen machen es nicht erforderlich, einen Gast-Benutzer zu haben. Die beiden Endpunkte sind hier identifizierbar
  • Meeting Join
    Auch die Teilnahme eines Anwender in einem Meeting, der weder Skype for Business oder Teams bislang nutzt, legt kein Gast-Konto an. Der Anwender kann ja nur in einem aktiven Meeting mit den Teilnehmern kommunizieren und erhält sonst keinen Zugriff
  • OneDrive -Link
    Etwas anders sieht es bei Dateifreigaben über OneDrive aus. Hier kann ich, wenn der Admin es erlaubt, auch einen Link senden, der wahlweise "Nur Lesen" oder auch "Editieren" enthält.

Insofern stehen anonyme Teilnehmer etwas außerhalb der Reihe an Konten

Die Menge an Objekten mit möglichen Zugriffsfunktionen kann schon verwirren. Allerdings sind nur wenige Konten tatsächlich relevant.

Das Anmeldekonto (UPN) eines Gast-Benutzers entspricht dem UPN im Konten-AzureAD. Ich habe aber auch schon Schreibweise nach folgender Regel gesehen

upnuserpart_upndomain#ext#@<tenantdomain.tld>

Gäste in meinem Tenant

Für die weitere Betrachtung von Zugriffen aus anderen Tenants oder anderen Verzeichnisdiensten sind nur die "Gäste", d.h. die Benutzer vom Typ 3, 6 und vielleicht 5 in der obigen Tabelle relevant. Alle anderen Konten haben entweder ganz normal direkten Zugriff oder eben ohne Gastkonto keinen Zugriff.

Als Tenant Administrator kann ich vorgeben, wie Gäste angelegt werden können. Es gibt nämlich auch hier ein "Self Provisioning", welche standardmäßig in Azure eingeschaltet ist. Das bedeutet aber nicht, dass es damit immer auch sofort funktioniert. Diverse Apps, wie z.B. Teams, haben noch einmal eine eigene Einstellung dafür und in Teams ist die Funktion normalerweise "AUS".

Wenn die Freigaben aber aktiv sind und ein Anwender ein Konto aus einem anderen Tenant einlädt. dann legt AzureAD im Hintergrund ganz einfach ein Gastkonto an. Sie können diese gleich an mehreren Stellen sehen

  • Office 365 Portal
  • AzureAD Portal
    Ich habe in der Liste einen Filter auf "User type = Guest" gesetzt und hier sehen wir dann auch die Quelle

    Der "Cloud Only Gast" mit dem Namen "Create Guest" erscheint hier bei den Gästen während er im Office 365 Portal als Benutzer erscheint.
  • MSOLUser Powershell
    Bei größeren Umgebungen und automatisierten Prozessen ist natürlich die PowerShell und zukünftig die Graph-API das Mittel der Wahl. Wobei ich noch nicht genau ermittelt habe warum einige Konten weder Guest noch Member sind.
PS C:\> Get-msoluser -all | group usertype -NoElement

Count Name
----- ----
10 Guest
6 Member
4

Hinweis:
Auch OnPremises gibt es solche "Foreign Security Principals" in ihrem lokalen Active Directory, wenn Benutzer über einen Trust auf ihrer Umgebung arbeiten.

6.1.1.4.10 Foreign Security Principals Container
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/5aa09c90-c5db-4e97-98d0-b7cdd6bc1bfe
"These objects represent security principals from trusted domains external to the forest, and allow foreign security principals to become members of groups within the domain. "

Wo bin ich Gast?

Umgekehrt ist es natürlich auch interessant, in welchen anderen Tenants ich selbst als "Gast" angelegt bin. Ich habe bislang noch keinen Weg gefunden, wie ich als Administrator dazu einen Bericht ermitteln kann. Aber der Benutzer kann es sehr wohl, indem er über seine Account-Seite im Azure Active Directory geht:

Hier ein partieller Auszug aus meinem Konto. Es sind bei mir schon einige andere Tenants, in denen ich ebenfalls zugreifen kann.

Damit sehen Sie aber auch, dass diese Funktion sinnvoll genutzt werden kann und ich bei keiner der anderen Firma ein Konto mit Kennwort verwalten muss. Ich nutze einfach meine Identität in meinem Stamm-Active Directory, um die Dienste in anderen Tenants zu nutzen. Wenn ein Benutzer irgendwann so ein Firmen-Konto nicht mehr nutzen darf oder kann (Rente, Kündigung, Tod, andere Funktion), dann sind auch alle anderen Tenants "sicher", dass dieser Benutzer nicht legitimierte Zugriffe tätigt.

Das ist übrigens auch ein deutlicher Hinweis, dass Sie ihr "Microsoft Konto", d.. ihre LiveID mit der sie privat auch XBox, Skype u.a. Dienste nutzen, nicht mit der gleichen Mailadresse betreiben sollten, wie ihr Firmenkonto. So können Sie besser unterscheiden, wann Sie ihr "Firmenkonto" und wann das private Konto verwenden.

Gast Provisionining Add/Remove

Ich habe schon weiter vorne geschrieben, dass je nach Konfiguration die Gastbenutzer sogar automatisch angelegt werden, wenn ein Anwender ein Konto aus einem anderen AzureAD-Directory referenziert. Wenn diese Funktion abgeschaltet ist, dann müssen Sie einen anderen Prozess zur Anlage der Gast-Konten etablieren. Für das wie gibt es keine vorgegebene Verfahrensweise. Hier müssen Sie ihre vorhandenen Prozesse zur Anlage von Benutzer, Freigabe von Diensten etc. entsprechend erweitert. 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.
  • Deaktiveren 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. Allerdings gibt es eine 1:5-Rate für Gäste, d.h. auf einen aktiven lizenzierten Benutzer sollten nicht mehr als 5 Gäste kommen. In der Regel reicht das locker aus.

Account Provisioning zu anderen Diensten

Auf einen weiteren Aspekt von Identitäten in Azure möchte ich noch eingehen. Wenn immer mehr Firmen ihre Benutzer unterschiedlichster Firmen heute schon als Identitäten in einem AzureAD vorhalten und das AzureAD auch die Authentifizierung durchführt, dann bietet es sich ja geradezu an, diese Informationen auch für weitere Dienste zu nutzen. Genau das ist über mehrere Wege möglich

  • AzureAD API-Zugriff
    Der andere Service kann sich die Informationen über die Benutzer und Gruppen per Graph o.a. einfach holen. Als AzureAD-Admin müssen Sie der Applikation einfach die Berechtigungen einräumen. Zur Authentifizierung muss die Applikation dann einfach den Anwender zum AzureAD senden, damit er mit einem ausgefülltem OAUTH-Token zurück kommt.
  • OnThyFly-Provisoining
    Die zweite Option ist, dass die Applikation erst dann etwas über den Benutzer erfährt, wenn er erstmalig mit einem OAUTH-Token kommt. In dem Token können auch einige Informationen enthalten sein und die Applikation kann hier den Benutzer fragen (Consent), damit sie weitere Informationen über den Benutzer anfordern kann

Wie ich auf der Seite AzureAD Cloud Provisioning schon beschrieben habe, geht Microsoft ja noch weiter, und möchte zukünftig AzureAD sogar zur Verwaltung eines lokalen Active Directory heranziehen.

Weitere Links