AD-Zukunft: On Premise und in der Azure-Cloud, Teil 1

Seit der Vorstellung des Azure Active Directory (Azure AD) gab es viel Verwirrung: Das Azure AD unterscheidet sich massiv vom traditionellen AD. Dennoch ist diese Form des AD ein wichtiger Bestandteil für eine Cloud-basierte IT-Infrastruktur. In einer Beitragsreihe werden die Grundlagen skizziert und dabei verschiedene Konfigurationen mit dem Azure AD besprochen, bei denen ein Zusammenspiel des „On Premise AD“ mit dem Azure AD zum Einsatz kommt.

Mit der Fokussierung auf die Azure Cloud bei Microsoft wurde ein Konzept dringend nötig: das Active Directory (AD) musste irgendwie auch in die Azure Cloud kommen – daher hat Microsoft das Windows Azure Active Directory auf den Markt gebracht. Mittlerweile ist dieser Service schon seit einiger Zeit am Laufen. Doch kaum einer darf erwarten, dass Unternehmen auf breiter Front in AD in den „eigenen Räumen“ weg werfen und sich komplett auf die Alternative – so es denn überhaupt eine ist – aus der Cloud verlassen.

Vielmehr geht es heutzutage darum, Konfigurationen aufzuzeigen, die von einer Kombination aus „Windows Azure Active Directory“ und „Windows Server Active Directory“ profitieren können. Da aber das „Windows Azure Active Directory“ als ein wesentlicher Bestandteil für kombinierte IT-Infrastrukturen agieren kann, muss zuerst geklärt werden, welche Funktionalität „Windows Azure Active Directory“ bietet und welche Aufgaben es – Stand heute – beim besten Willen noch nicht übernehmen kann. Vor allem der Vergleich zum bekannten „Windows Server Active Directory“ bringt hier ein viel besseres Verständnis.

Der Vergleich zeigt die Unterschiede

Das Windows Server AD, genauer gesagt die Active Directory Domain Services (AD DS), bieten die Authentifizierung und die Zugriffskontrolle (sprich die Autorisierung) auf Anwendungen, Dateidienste, Drucker und andere Ressourcen, die in der IT-Infrastruktur eines Unternehmens liegen. Dabei kommen Protokolle wie etwa Kerberos für die Authentifizierung oder LDAP (Lightweight Directory Access Protocol) für das Erkennen von vorhandenen Ressourcen zum Einsatz. Doch man darf eines nicht vergessen: Die AD DS waren ursprünglich nicht dafür vorgesehen, direkt – sprich native – mit den Web-basierten Diensten zurechtzukommen, die über das Internet angeboten werden.

Wie die AD DS bietet auch das Windows Azure Active Directory die Funktionalitäten Authentisierung und Autorisierung für die Anwendungen. Doch anders als bei den AD DS wurde das Azure AD speziell entwickelt, um Web-basierte Dienste zu unterstützen, die zudem noch über „RESTful“-Schnittstellen verfügen. REST steht für „Representational State Transfer“ und skizziert einen Ansatz, mit dem sich Information auf einem Server über einfache http-Aufrufe erzeugen, lesen, aktualisieren oder löschen lassen. Dabei ist dieser Ansatz recht einfach (verglichen mit Konzepten wie RPC, CORBA oder SOAP) – es wird üblicherweise nur ein http-GET-Aufruf an eine eindeutig identifizierbare Ressource (auf einem Server) abgesetzt.

Die über das Web angebotenen Applikationen, wie etwa Office 365, salesforce.com oder auch die Google-Apps, sie alle nutzen diese Art der Schnittstelle. Das hat zur Folge, dass das Azure AD auch ganz andere Protokolle verwenden muss – und zwar Protokolle die mit diesen Web-basierten Diensten zusammenspielen. Dazu zählen zum Beispiel SAML und OAuth 2.0.

Wenn man sich allerdings in der Abstraktionsstufe weiter nach oben bewegt, könnte man die Aussage gelten lassen: „Beim Azure AD handelt es sich um einen AD-Dienste für Cloud-basierte Applikationen.“ Dabei darf man allerdings nicht vergessen: Das Azure AD ist keinesfalls nur eine Implementierung der AD DS unter Windows Azure. Auch wenn die höheren Funktionen für die Authentifizierung, Autorisierung, die Abfrage von Verzeichnissen und das Verwalten von Gruppen und Benutzern alle vorhanden sind: Die Details wie diese Funktionen gebildet werden, unterscheiden sich massiv von den AD DS.

Beim Azure AD handelt es sich aber auch um einen gigantischen „multi tenant“ Dienst, der das gesamte Identity und Access Management (IAM) von allen Services (die im Rahmen von Azure angeboten werden) übernimmt. Dazu gehören auch die Microsoft Online Services (MOS). Die Kopie des Azure AD, das man selbst sieht und auch selbst verwalten kann (also das „eigene Tenant“, sprich die Instanz, die zu einem selbst gehört), ist immer nur eine kleine Instanz des viel größeren Ganzen (siehe Bild 2).

Zusätzlich zu den Authentifizierungs- und Autorisierungsfunktionen für die Microsoft Online Services und allen anderen Azure-Abonnements, hat das Azure AD hunderte von SaaS-Applikationen (Software as a Service) an seinen Dienst mit angebunden. Damit wird dann ein SSO (Single Sign On) erreicht – sei es durch die Federation für Anwendungen, die diese Funktionalität unterstützen, oder durch ein sogenanntes „Password Vaulting“ und eine formularbasierte Authentifizierung für die Anwendungen, die eine Federation nicht unterstützen.

Ansonsten müsste man selbst im eigenen Rechenzentrum die AD DS zusammen mit den AD FS (Active Directory Federation Services) einsetzen und dann jede Verbindung zu einer Applikation selbst herstellen. Das funktioniert allerdings nur, wenn die Applikation das Federation-Konzept unterstützt.

Brückenschlag für die Identitäten

Da in der realen Welt der überwiegende Anteil von Benutzerkonten eines Unternehmens in der jeweiligen AD-Gesamtstruktur des Unternehmens und somit im firmeneigenen Rechenzentrum liegt, muss das Azure AD auch damit umgehen können. Dazu unterstützt es die Verbindung einer Instanz im Azure AD mit den AD-Strukturen in den jeweiligen Unternehmen. Dazu wird eine „Identity Bridge“ angeboten.
Dazu hat Microsoft die AD FS (Active Directory Federation Services) zusammen mit dem Windows Azure Active Directory Synchronization Tool (abgekürzt als „DirSync“ bezeichnet) vorgesehen. Für komplexere Szenarien gibt es auch noch den „Windows Azure AD Connector for FIM 2010“. Auch von Drittherstellern gibt es ausgezeichnete Werkzeuge, um diese Aufgabe zu stemmen. Sie sind oftmals einfacher einzusetzen und bieten teilweise auch mehr Funktionalität als die Tools von Microsoft.

Generell stellt sich für viele Administratoren die Frage, warum sie sich mit Azure AD befassen sollen. Müssen sie sich dabei doch in viele Details einarbeiten – zusätzlich zu den vielen anderen Aufgaben, die sie Tag für Tag zu bewältigen haben. Die Antwort dazu ist mit zwei Argumenten gegeben: Wer mit den Microsoft Online Services, wie Office 365, Exchange Online oder Windows Intune, liebäugelt, der muss sich im Klaren sein: Die Konten, die man für diese Dienste verwalten muss, liegen alle im Azure AD. Daher ist es für den Administrator sehr wichtig, dass er sich damit auskennt.

Das andere Argument ist der Einsatz von „Identity as a Service“ (IDaaS). Wer sich mit diesem Thema beschäftigt, der wird die Rolle von Azure AD recht schnell einschätzen können. Wer sich nicht mit IDaaS befassen will, der wird über kurz oder lang sich damit auseinandersetzen müssen. Denn das Azure AD soll als der wichtigste Player im Bereich IDaaS etabliert werden – so lautet die Zielsetzung bei Microsoft – auch wenn es andere Anbieter von ähnlichen Diensten am Markt gibt, die auch viele Funktionalitäten bieten. Für die mittelfristige Zukunft sollte ein Administrator auch gerüstet sein: Beim Azure AD handelt es sich aus Microsofts Sicht um die Identity-Infrastruktur der Zukunft.

Identitätskrise bei hybriden Cloud-Strukturen

Bei der IT-Konfiguration, die nach dem Konzept einer Hybrid Cloud arbeitet, kann es schnell zur Verwirrung kommen: Ein Grund ist die Anordnung der einzelnen Bestandteile – sie lassen sich in den verschiedensten Kombinationen zusammenfügen, sowohl im eigenen Rechenzentrum (On Premise) oder in einer Cloud. Dieses Modell passt aber zum Identity-Konzept generell und zum AD im speziellen. Doch aufgrund dieser Möglichkeiten ergeben sich einige Fragestellungen:

• Wann soll man das AD in der Cloud zum Einsatz bringen?
• Wann soll man auf Windows Azure AD benutzen?
• Wann erfüllt das Angebot eines Drittherstellers die IDaaS-Anforderungen besser als das Azure AD?

Auf diese Fragestellungen wird im Rahmen dieser AD-Serie eingegangen. Die möglichen Konfigurationen von Windows Server AD und Azure AD sind im Folgenden aufgelistet. Dabei ist die Reihenfolge nach dem Reifegrad der Lösung angeordnet – das gängigste (und das ausgereifteste) zuerst:

• Nur das Windows Server AD im eigenen Rechenzentrum: Ganz so wie es Microsoft schon seit Jahrzehnten propagiert – noch gänzlich ohne Berücksichtigung von Cloud-basierten Diensten.
• Windows Server AD im eigenen Rechenzentrum und eine Erweiterung, die eine öffentliche IaaS-Cloud (Infrastructure as a Service) mit einbezieht: Windows Server AD Domänencontroller (DCs), die eine oder mehrere Domänen hosten und als virtuelle Maschinen (VMs) in einer IaaS-Cloud (wie Windows Azure oder AWS – Amazon Web Services) laufen. Dabei ist eine Kommunikationsverbindung (wie zum Beispiel ein Virtual Private Network, VPN) zurück zu den DCs im eigenen Rechenzentrum etabliert.
• Windows Server AD im eigenen Rechenzentrum, in der Cloud und mit einer „Identity Bridge“ eine Anbindung in das Azure AD: Windows Server AD DCs sowohl im eigenen Rechenzentrum als auch als VMs in einer IaaS-Cloud. Dabei werden die Identity-Informationen mit dem Windows Azure AD über eine „Identity Bridge“ geteilt.
• Windows Server AD im eigenen Rechenzentrum mit einer „Identity Bridge“ zu Windows Azure AD: Das ist Microsofts „Hybrid Cloud OS Vision“.
• Windows Azure AD nur in der Cloud: Dabei wird kein Verzeichnisdienst mehr im eigenen Rechenzentrum betrieben. Alle Identitätsinformationen kommen aus der Cloud – genauer vom Windows Azure AD.

Kaum ein Unternehmen wird all diese Konfigurationsmöglichkeiten und noch dazu in dieser Reihenfolge nutzen. Doch es ist eine wahrscheinliche Abfolge – selbst wenn man den ein oder anderen Schritt überspringt. Um die Sache möglichst überschaubar zu halten, soll hier noch eine weitere Annahme getroffen werden: Es ist immer nur eine Windows Server AD-Gesamtstruktur in jeder Konfiguration zu betrachten. Im zweiten Teil dieser Reihe wird dann auf die einzelnen Konfigurationen eingegangen.

Sean Deuby/rhh