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. OnPremises 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>

Falle "Domain"

Normalerweise trennen Anwender ihr privaten und geschäftlichen Konten streng voneinander. Leider gibt es aber auch hier einen "historischen" Hintergrund, der bei Bestandkonten zu Problemen führen kann. Ich kann das aus eigener Erfahrung berichten.

  1. 1990: Ich registriere meine Domain "carius.de"
    Da war von Microsoft und Internet noch nichts zu sehen und an Office 365 hat niemand gedacht. In dem Zuge habe ich auch ein Postfach bei meinem Provider (Damals hieß IONOS noch "Puretec"
  2. Microsoft "Passport"-Konto
    Einige Jahre später habe ich ein "Microsoft Konto" (damals noch "Passport" und danach "LiveID" genannt) und dazu natürlich meine Mailadresse genutzt und kein "outlook.de" oder "msn-de"-Konto. Mit dem Konto habe ich dann auch OneDrive (Consumer) betrieben.
  3. Und dann kam Office 365.
    Natürlich habe ich meinen Tenant angelegt und meine Domain dort registriert. Aber meine Mails laufen immer noch bei meinem Internet-Provider auf, d.h. das Exchange Postfach in dem Tenant ist nicht "live". Aber bei der Nächsten Anmeldung an "OneDrive" war dann die erste sichtbare Konfliktsituation zu sehen:

    Ich muss nun entscheiden, welche Identität ich nutzen möchte. Die Lösung für Firmen bedeutet hier, dass das "persönliche Konto" eben nicht mit der Mailadresse der Firma verbunden wird. Ich sollte mein persönliches Konto dann besser auf ein "outlook.de"-Konto oder wirklich eine "private Domäne" umziehen.
  4. Und dann kam die Tochter
    Ich habe natürlich ein "Office 365 Family"-Paket und dazu benötigt mein Familienmitglied ein "Microsoft Konto". Sie konnte nun aber kein Konto mit der Mailadresse "<kindname>@carius.de" anlegen, da die Domain schon in einem Firmen-Tenant registriert ist. Also hat sie eine vorname.nachname@outlook.de-Adresse bekommen und damit ihren PC, das Smartphone etc. verwendet. Ein Konto in meinem Firmen-Tenant braucht sie dafür nicht
  5. Externe Einladung an vorname@carius.de
    Und dann kam der Moment, als sie im Rahmen von SchubsIT (https://www.innozent-owl.de/nachwuchskraefte-entwickeln/schubs-informatik/) von einer Firma in deren Teams-Tenant eingeladen wurde. Die Organisatoren hatten ja die Mailadresse zur Kommunikation und damit ging die Einladung an die Mailadresse. Leider konnte sich meine Tochter damit aber nicht anmelden, denn es gab zwar die Mailadresse beim Provider aber kein "Microsoft Konto" und auch kein AzureAD Konto. Entsprechend war eine Anmeldung auch nicht möglich.

    Denn der einladende Tenant hat ja die Mailadresse genutzt um den "Gast" einzuladen. Die Einladung kann nur funktionieren, wenn es auch einen solchen Benutzer gibt

Damit ist klar, dass mittlerweile eine Domäne, die in einem Office 365 Tenant registriert ist, nicht mehr ohne Probleme mit einem Microsoft Koto genutzt werden kann.

Aus Sicht einer Firma ist dies sogar wichtig, damit Mitarbeiter sich nur noch mit dem AzureAD-Konto bei anderen Firmen anmelden und eben nicht mehr mit einem Konto einer anderen Plattform zugriff erhalten

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.

Sonderfall Gastkonten

Siehe dazu die Seite Gast-Identität

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.

Devices

Übrigens gibt es auch Geräte als Konten im lokalen Active Directory als auch in AzureAD.

Weitere Links