Azure Active Directory: Identitätstypen

Microsoft fasst die eigene Firmenstrategie inzwischen unter dem Motto „Mobile first – Cloud first“ zusammen. Der Ansatz dieser Strategie wird zunehmend deutlich, wenn man versucht, einige neuere Lösungen aus dem Microsoft Portfolio zu implementieren. Schon beim Evaluieren stellt man schnell fest, dass manche Produkte es erfordern, über eine Variante von Microsoft Azure Active Directory nachzudenken, da ohne dieses ein Einsatz der Produkte nur eingeschränkt oder schlicht und einfach gar nicht möglich ist. Wer also in Zukunft nicht auf Microsoft-Lösungen verzichten und weiterhin innovative Lösungen aus Redmond einsetzen möchte, kommt nicht drum herum, sich mit dem Thema Microsoft Azure Active Directory zu befassen.

Um einen Einstieg in das Thema zu liefern, möchte ich In dieser mehrteiligen Artikelreihe von unterschiedlichen Cloud-Identitätstypen über Synchronisationsmöglichkeiten der lokalen Active-Directory-Benutzer bis hin zu hochverfügbaren Active Directory Federation Services mit der Anbindung an Microsoft Azure Active Directory beleuchten. Ebenso sollen auch Gedanken über eine mögliche Implementierungsstrategie und etwaige Sicherheitsbedenken mit einfließen.

Varianten der Identitäten

Microsoft unterscheidet bei der Verwendung von Azure Active Directory zwischen drei Arten von Identitätstypen.

1. “Cloud Identity“
2. “Synchronized Identity“
3. “Federated Identity“

Diese einzelnen Typen werde ich nun gemeinsam mit Euch beleuchten.

1. “Cloud Identity“

Die “Cloud Identity“ ist eine Kombination aus Benutzername und Passwort, welche ihren Ursprung im Azure Active Directory hat. Hierfür muss der Administrator des Azure Active Directory (AAD) pro Anwender ein neues Benutzerkonto anlegen. Dieses kann entweder manuell über das Management-Portal des AAD oder alternativ über das Microsoft Azure Active Directory PowerShell Module (http://go.microsoft.com/fwlink/p/?linkid=236297) erfolgen. Für die Anlage von mehreren Anwendern ist zusätzlich die Verarbeitung einer CSV-Datei über das Management-Portal (oder natürlich wieder per PowerShell) möglich. Nach der erfolgreichen Anlage des Benutzerkontos kann sich der Anwender mit der neuen “Cloud Identity“ an die entsprechenden Dienste (zum Beispiel Microsoft Office 365) anmelden.

Der größte Nachteil dieser Identitätsart ist, dass keinerlei Abgleich zwischen einem lokalen Active Directory und Azure Active Directory besteht. Somit müssen alle notwendigen Änderungen doppelt gepflegt werden, und der Anwender muss sich eine zusätzliche Kombination aus Benutzername und Kennwort merken.

Die nachfolgende Grafik stellt diese Art der Identität im Überblick dar.

Vorteile der “Cloud Identity“:

• Schnelle Implementierung für Testumgebungen (Trial)
• Keine zusätzliche Infrastruktur On-Premises notwendig
• Verfügbarkeit abhängig von den Microsoft Services, keine On-Premises-SLAs zu definieren
• Kein On-Premises-Active-Directory notwendig

Nachteile der “Cloud Identity“:

• Zusätzliche Benutzernamen-/Kennwort-Kombination für den Anwender
• Erhöhter administrativer Pflegeaufwand

Aus den genannten Vor- und Nachteilen empfinde ich die “Cloud Identity“ nicht als Enterprise-taugliche Variante für den Einsatz im Unternehmen.

“Synchronized Identity“

Die “Synchronized Identity“ ist meines Erachtens die inzwischen von Microsoft präferierte Variante der Identitätstypen. Hierbei handelt es sich um eine Identität, die ihren Ursprung im Active Directory des eigenen Unternehmens hat und ins Azure Active Directory synchronisiert wird. Zum heutigen Zeitpunkt stehen für die Synchronisation mehrere Microsoft-Tools (DirSync, AAD Sync, AAD Connect, FIM) zur Verfügung. Diese Tools unterscheiden sich im Umfang der Möglichkeiten und natürlich auch in der Implementierung. Genauere Einzelheiten und Tipps zur Implementierung werden in den nächsten Teilen der Blogreihe erläutert.

Um den Anwendern eine gewohnte Usability zu bieten, kann der Administrator ebenfalls die Synchronisation des Passworts einrichten, wodurch sich der Anwender sowohl lokal oder bei entsprechenden Clouddiensten (z.B. Office 365) mit der gleichen Benutzernamen-/Kennwort-Kombination anmelden kann. Um dieses zu ermöglichen, wird jedoch nicht das Passwort im Klartext, sondern der Hash des Passwortes übertragen (sas Kennwort wird auch im lokalen Active Directory nicht im Klartext gespeichert). Um die Sicherheit weiter zu erhöhen, wird ein neuer Hash aus dem bestehenden Passworthash mittels eines SHA256-Algorithmus gebildet (“re-hash the hash”) und anschließend über eine gesicherte SSL-Verbindung ins AAD übermittelt.

Die Administration der “Synchronized Identity“ erfolgt ausschließlich über das lokale Active Directory. Änderungen an den lokalen Active-Directory-Konten werden innerhalb des nächsten Synchronisationszyklus ins Azure Acitve Directory übertragen.

Die Authentifizierung des Anwenders erfolgt in diesem Fall weiterhin am Azure Active Directory. Dieses ist in der nachfolgenden Grafik nochmals dargestellt.

Vorteile der “Synchronized Identity“:

• Einfache Implementierung
• Sehr hohe Verfügbarkeit (Microsoft-SLAs)
• kein administrativer Overhead (Pflege von mehreren Benutzerkonten pro Anwender unnötig)
• hohe Anwenderakzeptanz durch identische Benutzername-/Kennwort-Kombination (bei aktiviertem Passwortsync)

Nachteile der “Synchronized Idenity“:

• Passwortsynchronisation für Anwenderakzeptanz notwendig, dieses kann in Unternehmen mit strengen Security Policies scheitern
• Kein Single-Sign-On
• Änderungen werden erst bei dem nächsten Synchronisationszyklus übertragen (z.B. Sperren eines Accounts)

Die genannten Vor- und Nachteile zeigen, dass für viele Unternehmen die “Synchronized Identity“ wahrscheinlich die optimale Wahl darstellt.

“Federated Identity“

Nun kommen wir sozusagen zur Königin der Identitäten, der “Federated Identity“. Hierbei handelt es sich ebenfalls um eine Identität, die ihren Ursprung im Active Directory des eigenen Unternehmens hat und ins Azure Active Directory synchronisiert wird. Bei der Synchronisation der Benutzerkonten kann jedoch auf die Übermittlung der Passwörter verzichtet werden, da die Authentifizierung der Anwender im Gegensatz zur “Synchronized Identity“ lokal im eigenen Netzwerk (“on premises”) durchgeführt wird. Hierfür wird bei einer Anmeldung an einem Clouddienst (z. B. Office 365) der Authentifizierungsversuch vom Cloudservice an einen lokalen Identitätsprovider umgeleitet. Dieses kann entweder ein ADFS (Active Directory Federation Server) oder ein Identitätsprovider eines Drittanbieters (siehe https://msdn.microsoft.com/library/azure/jj679342.aspx) sein. Dieser Identitätsprovider authentifiziert den Anwender und liefert das Ergebnis der Authentifizierung an den Cloudservice zurück. Somit ist sichergestellt, dass keinerlei Passwörter an den Cloudservice übermittelt werden, sofern die optionale Synchronisation der Passwörter nicht aktiviert ist. Diese Synchronisation kann unter Umständen jedoch sinnvoll sein, doch dazu später mehr.

Zusätzlich hierzu kann diese Art der Identität weiteren organisatorischen Anforderungen Rechnung tragen. So ist zum Beispiel die Implementierung von Single-Sign-On oder die Einbindung von SmartCards zur Authentifizierung möglich.

Der Ablauf ist in der nachfolgenden Grafik nochmals dargestellt.

Vorteile der “Federated Identity“

• Hohe Flexibilität bei der Implementierung in Verbindung mit Active Directory Federation Services (unter anderem Unterstützung von SmartCards und Multi-Factor-Authentication zur Authentifizierung)
• Unterstützung von Single-Sign-On
• Authentifizierung findet in der eigenen Domäne statt – keinerlei Übertragung der Passwörter während der Authentifizierung in Richtung Cloud
• Sofortige Sperrung eines Accounts möglich
• Auditing von Benutzeranmeldungen möglich

Nachteile der “Federated Identity“

• Höhere Komplexität als bei den anderen Identitätstypen
• Notwendigkeit von zusätzlichen On-Premise-Services (Identitätsprovider), je nach organisatorischen Anforderungen in Hochverfügbarkeit ausgelegt

Wechsel zwischen den Identitätsvarianten

Microsoft bietet die Möglichkeit, die Identitäten zwischen einzelnen Typen zu konvertieren. Dieses unterstützt die Möglichkeit, auf organisatorischen Anforderungen zu reagieren und jeweils die beste Identität für das Unternehmen auszuwählen.

Von der “Cloud” zur “Synchronized Identity“

Wie in den obigen Beschreibungen dargestellt, unterscheidet sich die “Cloud“- und die “Synchronized Identity“ in der Tatsache, dass entweder eine Synchronisation zwischen dem On-Premises-Active-Directory durchgeführt wird oder nicht.

Um von der “Cloud“ zur “Synchronized Identity“ zu wechseln, ist es notwendig, dass im eigenen Netzwerk eines der Synchronisationstools von Microsoft implementiert wird, das die Benutzerkonten in das Azure Active Directory synchronisiert. Bei der Synchronisation von bereits bestehenden Accounts wird entweder ein “Soft“- oder “Hard-Match“ durchgeführt. Hierdurch wird gewährleistet, dass bereits bestehende Accounts mit den synchronisierten Informationen aktualisiert werden.

Von der “Synchronized“ zur “Federated Identity”

Der Wechsel von einer “Synchronized“ zur “Federated Identity” erfordert erstmals einen On-Premises-Identitätsprovider. Sofern dieser implementiert ist, ist der Wechsel einfach per PowerShell-Befehl beziehungsweise im Management-Center des AADs zu realisieren. Hierbei ist zu beachten, dass der Wechsel zwischen den Identitäten immer pro Domäne durchgeführt wird. Sollten also mehrere Domains innerhalb des AAD-Tenants vorhanden sein, so muss jede Domain einzeln konvertiert werden. Aufgrund der Tatsache, dass die Authentifizierung ab diesem Zeitpunkt On-Premises durchgeführt wird, ist die Synchronisation der Passworthashes nicht mehr notwendig. Allerdings sollte weiterhin die Synchronisation der Passworthashes für einen Wechsel von der “Federated“ zur “Synchonized Identity“ in Betracht gezogen werden, welches als mögliche Disaster-Recovery-Option für den Ausfall des lokalen Identitätsproviders dienen kann.

Von der “Federated“ zur “Synchronized Identity“

Die Migration von einer “Federated“ zur “Synchronized Identity“ kann über den PowerShell-Befehl Convert-MsolDomainToStandard durchgeführt werden. Für den Fall, dass die Passwortsynchronisation aktiviert war beziehungsweise ist, haben die Anwender die Möglichkeit, sich mit der identischen Benutzernamen-/Kennwort-Kombination wie im lokalen Active Directory an den Cloudservices anzumelden. Dieses kann wie bereits beschrieben eine sinnvolle Backup- und Disaster-Recovery-Lösung für den Ausfall des lokalen Identitätsproviders darstellen. Sollte dieses nicht der Fall gewesen sein, so werden dynamische Passwörter pro Benutzer generiert, welche der Administrator anschließend an die Benutzer weitergeben muss.

Bei der Umwandlung zwischen den Identitätstypen ist allerdings je nach Anzahl der Benutzer mit einer gewissen Verzögerung zu rechnen.

Von der “Synchronized Identity“ zur “Cloud Identity“

Um von einer “Synchronized Identity” wieder zu einer “Cloud Identity“ zu gelangen, ist es ausreichend, innerhalb des AAD-Management-Portals die Verzeichnissynchronisation zu deaktivieren. Dieses kann natürlich auch mit der PowerShell (Set-MsolDirSyncEnabled –EnableDirSync $false) erledigt werden. Die Verarbeitung der Änderung kann bis zu 72 Stunden dauern.

Fazit

In dem ersten Teil der Artikelreihe wurden die unterschiedlichen Microsoft-Cloud-Identitätstypen mit Ihren Eigenschaften erläutert. Des Weiteren wurde aufgezeigt, welche Wechsel zwischen den einzelnen Typen möglich sind. In dem nächsten Teil der Blogreihe werden die Möglichkeiten und dazu gehörigen Tools für die Synchronisation der Active-Directory-Accounts zwischen On-Premises und Cloud genauer betrachtet. Wir werden also langsam den theoretischen Teil verlassen und mehr der dahinter stehenden Technik widmen.