Azure Active Directory vs. Active Directory-Domänendienste

Zunächst möchte ich anmerken, dass die heutigen Identitätstechnologien sehr verwirrend sein können. Es gibt zahlreiche Dienste (im Zeitalter der Cloud ist alles ein Dienst), Protokolle, Lösungen, SDKs, Technologien und Produkte, die darauf abzielen, das Identitätsproblem zu lösen.

Zunächst möchte ich die beiden grundlegenden Konzepte vergleichen, die möglicherweise am meisten Verwirrung stiften, da sie zufällig denselben Namen tragen: die altbewährten Active Directory Domain Services (kurz ADDS) und Windows Azure Active Directory (kurz AAD).

ADDS wird schon seit Ewigkeiten (nun ja, 13 Jahre sind in der IT-Welt eine Ewigkeit) eingesetzt, um Authentifizierungs- und Autorisierungsdienste (AuthN und AuthZ) innerhalb des Unternehmens-Rechenzentrums (der lokalen Umgebung) bereitzustellen. Es ist sehr beliebt (laut Gartner nutzen es 87 % der Fortune-1000-Unternehmen) und hat sich bei der Bereitstellung aller erforderlichen Dienste als äußerst zuverlässig erwiesen. (Hinweis: Ich habe das Produkt früher bei meiner Tätigkeit bei MSFT betreut, daher habe ich eine gewisse Vorliebe dafür).

Doch in der sich wandelnden Landschaft von heute reicht das eigentlich nicht mehr aus, und der Grund dafür lautet: Die Cloud!

Wenn wir uns das lokale Rechenzentrum und die Cloud-Umgebung ansehen, gibt es viele Unterschiede bei den verwendeten Protokollen und Lösungen, die auf mehrere Gründe zurückzuführen sind, aber die 3 wichtigsten sind: Sicherheit, Datenschutz und Interoperabilität.

Wenn wir uns die Protokolle ansehen, die im lokalen Rechenzentrum für die Authentifizierung und Autorisierung verwendet werden, können wir mit Sicherheit sagen, dass Kerberos heute das am weitesten verbreitete Protokoll ist. Und wenn wir uns den Datenzugriff ansehen, der heute in Rechenzentren für den Zugriff auf den Identitätsspeicher verwendet wird, würde ich sagen, dass LDAP das am weitesten verbreitete Protokoll ist, das von fast jedem Verzeichnisanbieter unterstützt wird.

Das ist also genau das, was ADDS tut: Es authentifiziert Benutzer und autorisiert den Ressourcenzugriff über Kerberos und ermöglicht den Zugriff auf den Datenspeicher über das LDAP-Protokoll.

„Doch dann kam die Cloud“ (und Facebook, das einen ganz konkreten Bezug dazu hat)

Wenn man sich ansieht, wie AuthN und AuthZ in der Cloud verwaltet werden (oder nicht verwaltet werden), ist es durchaus nachvollziehbar, dass Kerberos nicht ganz ausreicht.

Der Grund dafür ist, dass Sie bei der Verwendung von Kerberos Schlüssel angeben, die zur Verschlüsselung von Kerberos-Tickets dienen und von einer einzigen maßgeblichen Quelle bereitgestellt werden. Dies ist in einer Cloud-Umgebung nicht möglich (Welche Schlüssel würden Sie verwenden, wenn Sie ein Facebook-Konto bei einem Google-Dienst authentifizieren möchten? Es gibt keinen zentralen Identitätsspeicher und keinen zentralen Schlüsselanbieter!).

Dann kamen SAML, OAuth, OpenID und einige andere zur Rettung. All das sind Technologien, die eine föderierte Anmeldung ermöglichen. (Im Grunde genommen geht es darum, wie ich mich von Facebook bei Google anmelden kann, ohne meine Anmeldedaten zweimal eingeben zu müssen). Jede dieser Technologien hat ihre eigene Spezifikation, aber das Hauptziel ist es, die Authentifizierung über verschiedene Dienste von verschiedenen Dienst-/Cloud-Anbietern zu ermöglichen (habe ich schon die Interoperabilität erwähnt? ).

Betrachtet man die Datenzugriffsebene, gilt dasselbe. Zwar könnte LDAP funktionieren, doch gibt es etwas, das bei der Verwaltung von Verbindungen zwischen Personen (seien es nun Nutzer innerhalb einer Organisation oder Verbraucher mit Profilbildern und Pinnwänden) sinnvoller ist, nämlich der Graph!

Die Verwendung von Graph als Datenspeicher (insbesondere als Identitätsspeicher) ist durchaus sinnvoll, da es nicht wie LDAP hierarchisch aufgebaut ist und tatsächlich „Verbindungen“ zwischen den Benutzern und den Ressourcen innerhalb der Organisation darstellen kann. Dies ermöglicht es Ihnen, eine Identität tatsächlich zu verwalten, anstatt eine gesamte Hierarchie zu nutzen, die dazu dient, die Identitäten in „Ordnern“ zu organisieren – basierend auf den Kriterien, die die Organisation als sinnvoll erachtet.

An dieser Stelle kommt Azure Active Directory ins Spiel. AAD ist ein cloudbasierter IDaaS (Identity as a Service) von Microsoft, der offene Standards (z.B. SAML) verwendet, um Benutzer zu authentifizieren und den Identitätsverbund zwischen Cloud-Diensten zu ermöglichen, sowie das Graph-Datenmodell, um Objekte abzufragen und zu verwalten.

Hier finden Sie eine kurze Vergleichstabelle der beiden:

Zusammenfassend lässt sich sagen, dass ADDS uns die Möglichkeit bietet, uns bei unserem Unternehmensnetzwerk anzumelden, auf die Ressourcen im Unternehmensnetzwerk zuzugreifen und den Diensten die Abfrage von Informationen über Objekte wie Benutzer, Gruppen und Ressourcen ermöglicht.

AAD ermöglicht die Anmeldung bei unseren Cloud-Diensten, den Zugriff auf Ressourcen in der Cloud und die Abfrage von Informationen über Objekte durch Cloud-Dienste.

Ich hoffe, das hat Ihnen geholfen, die beiden zu verstehen.

Im nächsten Beitrag werde ich versuchen zu erläutern, wie beide miteinander verknüpft werden können, um eine „hybride“ Identität zu schaffen (die es ermöglicht, dasselbe Konto sowohl für lokale Ressourcen als auch für Cloud-Dienste zu verwenden).