Identitäten für Microsoft 365: nur Cloud, synchronisiert oder föderiert


    Tags: , , ,

    Hybride Identitäten für Microsoft 365Microsoft 365 nutzt Azure Active Directory (AAD) zur Verwaltung der Benutzer­konten, die Zugriff auf die Cloud-Dienste erhalten sollen. Wenn Unter­nehmen bereits ein AD on-prem betreiben, dann können sie die Accounts zwischen den Ver­zeichnissen getrennt halten oder einheitliche Iden­titäten ein­richten.

    In der Praxis erstellen Anwender erst einen neuen M365-Tenant und fügen eine eigene Domain plus entsprechende DNS-Einträge hinzu. Danach existieren in dem Mandanten außer dem Administrator selbst keine weiteren User. Diese kann man manuell im Admin Center oder per PowerShell anlegen. Zudem gibt es noch den Import von einer CSV-Datei, den man im Admin Center starten kann.


    Diesen Beitrag als Podcast anhören


    Cloud-Identitäten

    Die solcherart erzeugten User sind Cloud-Identitäten. Diese lassen sich bearbeiten, man kann an sie Passwort-Richtlinien vergeben oder für sie Single Sign-On (SSO) und Multifaktor-Authentifizierung (MFA) einrichten. Darüber hinaus lassen sich ihnen Lizenzen zuweisen und ihre Informationen sowie  Beschreibungen ändern. Ihre Verwaltung erfolgt im Admin Center, in der Admin Center App oder per PowerShell.

    Reine Cloud-Identitäten existieren nur im Azure AD, und die Authentifizierung erfolgt gegen dieses Directory

    Solche reinen Cloud-Identitäten können für kleine Unternehmen passen oder solche, die in der Cloud gegründet wurden (Stichwort "Cloud-born"). Die Identitätsform ist im Admin Center in der Spalte Synchronisierungs­status zu erkennen, eventuell muss diese eingeblendet werden. Hier steht dann In der Cloud, und die Konten sind somit unabhängig von einem lokalen AD. Die Authen­tifizierung übernimmt in diesem Fall Azure AD.

    Der Synchronisierungsstatus zeigt, dass es sich bei diesem Account um eine reine Cloud-Identität handelt.

    Falls doch ein lokales AD existiert und dieses nicht mit Azure AD synchronisiert wird, dann haben die User zwei Identitäten, eine in der Cloud (AAD) und eine on-prem in der Windows Server AD. Jeder Benutzer verfügt dann zudem über zwei voneinander unabhängige Passwörter, und Richtlinien werden ebenfalls für die Cloud sowie on-prem separat definiert. Insgesamt bedeutet dieses Modell also eine doppelte Verwaltung.

    Diese Konstellation ist nach Möglichkeit zu vermeiden, da sie mehr Nach- als Vorteile bietet. Daher ist ein reines Cloud-Identitätsmodell nur zu empfehlen, wenn es keine Umgebung mehr vor-Ort gibt.

    Synchronisierte Identität

    Das zweite und vermutlich häufigste Modell ist das der synchronisierten Identität. Dabei handelt es sich um eine Hybrid-Identität, weil sie sowohl lokal als auch in der Cloud zur Verfügung steht. Diese Variante ist für viele Szenarien geeignet und nutzt die Vorteile beider Welten.

    Meist beginnt die Reise in Richtung Cloud mit dem SaaS-Angebot von Office 365. Typischerweise sind dies die Commodity-Services wie Exchange, SharePoint, OneDrive und natürlich Teams.

    Die synchronisierten Identitäten können auch ein Zwischenschritt auf dem Weg zur vollständigen Migration in die Cloud sein, wenn im Anschluss die lokale Infrastruktur abgelöst werden soll.

    In dieser Variante wird das lokale Active Directory mit Azure AD synchronisiert, und zwar mit Hilfe von Azure AD Connect. Bei der Vorbereitung fügt man die verwendete Domäne als weiteres Suffix dem lokalen AD hinzu. Die User sollten den entsprechenden User Principal Name (UPN) erhalten. Im Idealfall entspricht er gleich der Mail-Adresse.

    Bei der Synchronisierung werden User-Objekte und deren Hashes in die Cloud übertragen

    Die AD-Objekte werden mittels Synchronisierung als Kopie in der Cloud angelegt. Wenn die lokale Infrastruktur nicht verfügbar ist, stehen die Cloud-Dienste trotzdem weiter zur Verfügung, weil das Azure AD die Authentifizierung übernimmt. Wichtig hierbei ist, dass das lokale Active Directory die Source of Authority bleibt.

    Dies bedeutet, dass die AD-Objekte weiterhin in der lokalen AD verwaltet und neue Mitarbeiter beispielsweise dort angelegt werden. Einige Änderungen, die sich im Admin Center von M365 oder per PowerShell an den Usern vornehmen lassen, werden von der Synchronisation überschrieben.

    Passwörter werden standardmäßig ebenfalls lokal verwaltet, es sei denn, das Zurück­schreiben von Kennwörtern wurde eingerichtet. Dies erfordert eine entsprechende Lizenzierung.

    Föderierte Identität

    Wenn neben den Cloud-Accounts weiterhin ein lokales AD existiert, dann gibt es zwei Varianten von Hybrid­identitäten. Neben der oben besprochenen synchronisierten sieht Microsoft noch die föderierte Identität ("Federated Identity") vor. Auch hier werden Benutzer nur einmal und zentral verwaltet.

    Hierzu muss man allerdings eine AD FS-Umgebung (Verbunddienste) implementieren. Mit Hilfe einer so genannten Vertrauens­stellung kann sich beispielsweise ein User aus der Domäne A bei der Domäne B authentifizieren. Dadurch darf er auf Ressourcen aus der Domäne B zugreifen.

    Auch kann Software angebunden werden, um Single Sign-On zu ermöglichen. Dabei handelt es sich um ein Konstrukt, das meist von größeren Unternehmen genutzt wird, weil es recht komplex ausfällt.

    Die föderierte Identität ist das komplexeste Modell. Die Authentifizierung erfolgt hier nur lokal.

    AD FS benötigt die AD Certificate Services (CS) sowie ein oder mehrere Zertifikate von einer öffentlichen Stelle, also keine selbst ausgestellten. Zusätzlich braucht es eine Public IP und einen Proxy. Wenn man AD FS redundant, also hochverfügbar auslegt, erhöht sich der Aufwand weiter.

    Bei dieser Variante wird eine Vertrauens­stellung zu Microsoft aufgebaut, und die Authentifizierung erfolgt weiterhin lokal. Anders als bei der Synchro­nisierung gelangen keine Passwörter (als Hashes) in die Cloud. Richtlinien wirken sich bei diesem Modell unmittelbar aus.

    Wenn die lokale Infrastruktur Probleme hat, dann ist der Zugang zu den Cloud-Diensten und deren Workloads ebenfalls beeinträchtigt.

    Dokumentation zu Hybrid-Identitäten von Microsoft:

    Täglich Know-how für IT-Pros mit unserem Newsletter

    Wir ver­wenden Ihre Mail-Adresse nur für den Ver­sand der News­letter.
    Es erfolgt keine per­sonen­be­zogene Auswertung.

    Bild von Benjamin Bürk

    Benjamin Bürk ist Senior Systems Engineer und betreut seit 2002 IT-Infrastrukturen von Unternehmen. Sein Schwerpunkt liegt im Aufbau und Betrieb von Server-Systemen und Microsoft 365-Umgebungen. Er ist ITIL4 Foundation, dreifach als MCSA sowie als MCSE Productivity zertifiziert..

    // E-Mail, LinkedIn, Podcast //

    Ähnliche Beiträge

    Weitere Links