In nahezu jedem kleinen Unternehmen findet sich heute mehr als nur ein Computer. Je nach Betätigungsfeld des Unternehmens gehört der eigene PC entweder zur unverzichtbaren Ausrüstung des Arbeitsplatzes aller Mitarbeiter oder ist zumindest für einen Teil nötig. Viele Tischler etwa greifen heute gern auf CAD & Co zurück, um ihre Möbel vor dem Bau zu planen. Zimmerleute, die einen Dachstuhl bauen, planen diesen zuvor ebenfalls in aller Regel digital. Lange Rede, kurzer Sinn: IT gehört in KMU selbstverständlich dazu. Anders als in großen Firmen gibt es hier regelmäßig allerdings keine eigene Abteilung, die die interne IT betreut. Entweder ist diese Arbeit gleich an externe Dienstleister ausgelagert oder ein Mitarbeiter erledigt die Aufgabe nebenher mit.

Um verschiedene Compliance-Themen quasi im Vorbeigehen abzuhandeln und die Verwaltung von Benutzerzugängen und Geräten zu vereinfachen, haben sich zentrale Verzeichnisdienste wie LDAP oder das Active Directory (AD) gerade in den letzten Jahren immer stärker verbreitet. Galt ein ausgewachsenes AD einst noch als Werkzeug, das nur riesige Firmen für die eigene Infrastruktur benötigten, finden sich kleine AD-Setups heute auch in Betrieben ab ungefähr zehn Mitarbeitenden. Das Problem dabei: Ein Active-Directory-Setup ist heute kaum weniger komplex als noch vor ein paar Jahren, eher ist es noch schwieriger geworden.

Denn als zentraler Verzeichnisdienst genießt das Active Directory freilich auch eine zentrale Relevanz. Wenn alle Benutzeranmeldungen nur via AD klappen, klappen sie nicht, wenn das AD nicht zur Verfügung steht. Schon sieht sich ein Admin dem Thema Hochverfügbarkeit gegenüber. Diese ist indes vor Ort oft gar nicht sinnvoll zu erreichen, weil keine typische RZ-Infrastruktur zur Verfügung steht, sondern der Server mit AD ein tristes Dasein in der Abstellkammer fristet.

Doch macht Microsoft seit Jahren erfolgreich auf Cloud, betreibt in Form von Azure sogar eine eigene. Und siehe da: Scrollen wir durch das Produktportfolio des Windows-Herstellers, findet sich dort nicht nur ein "Azure Active Directory", meist "Azure AD" abgekürzt, sondern auch ein "Azure Active Directory Domain Services"-Dienst, oder kurz Azure AD DS. Können die IT-Verantwortlichen von KMU sich das leidige Thema des AD-Betriebs möglicherweise durch die Migration des Dienstes in die Wolke vom Hals schaffen? Wodurch unterscheiden sich Azure AD und Azure AD DS eigentlich voneinander? Und welcher Dienst passt zu welchem Einsatzzweck?

Wer sich erstmals mit Microsofts Cloudangebot rund um das Active Directory beschäftigt, landet schnell auf dem Holzweg. Denn bloß weil "Active Directory" und "Azure Active Directory" ähnlich klingen, bedeutet das nicht, dass letzteres Produkt lediglich das in die Azure-Cloud umgezogene Active Directory ist, wie Administratoren es von ihrer On-Premises-Installation kennen. Zunächst ist es daher unabdingbar, die Begrifflichkeiten zu klären, die Microsoft für seine Produkte nutzt, und diese im Hinblick auf ihren Funktionsumfang voneinander abzugrenzen.

Den Anfang macht dabei "Azure Active Directory". Wie bereits erwähnt ist Azure AD nicht einfach ein in die Cloud umgezogenes Active Directory – was schon daran zu erkennen ist, dass Microsoft Azure AD ausschließlich als gemanagten Dienst anbietet, also eher als "Platform-as-a-Service" oder "Software-as-a-Service"-Angebot. Wo der Dienst läuft und wie unter ihm das System aussieht, erfährt der Nutzer also gar nicht erst.

Hinzu kommt, dass Azure AD kein klassischer Verzeichnisdienst ist, wie der Admin es von seinem lokalen AD her kennt. Kritiker behaupten, es handele sich bei Azure AD de facto überhaupt nicht um einen Verzeichnisdienst, auch wenn der Name Verwandtschaft mit dem Vorfahren aus der On-Premises-Welt suggeriert. Denn die primäre Aufgabe von Azure AD bestünde darin, Kombinationen aus Benutzernamen und Passwörtern zu speichern und diese über definierte Standardschnittstellen für andere Dienste und Applikationen verfügbar zu machen, etwa im Rahmen von OAuth. Und in der Tat ähnelt der Funktionsumfang von Azure AD eher der Idee eines zentralen Tresors für Benutzerdaten mit Cloudanbindung denn jener eines zentralen Verzeichnisdienstes.

Das ist freilich kein Zufall oßder Ergebnis der Unfähigkeit jener, die bei Microsoft für Azure AD verantwortlich zeichnen. Stattdessen war Azure AD von Anfang an als genau der Dienst konzipiert, der er heute ist. Und Microsoft hat die Gelegenheit genutzt, einige alte Zöpfe abzuschneiden, die das Active Directory bis heute mitschleppt. Das zeigt ein Blick auf die genutzten Protokolle sehr schnell. Während beim Active Directory heute zum Teil noch immer dieselben Protokolle zum Einsatz kommen wie vor mehreren Dekaden, ist das Azure AD vor allem über API-Schnittstellen nach dem ReST-Standard anzusteuern.

Einerseits erleichtert Microsoft es dadurch erheblich, Azure AD an andere Clouddienste und Anwendungen anzubinden. Wie das funktioniert, macht der Konzern bei eigenen Cloudanwendungen gleich überdeutlich: Microsoft 365 (ehemals Office 365) lässt sich etwa vollständig mit den Nutzern aus dem Azure AD verwenden. Andererseits bedeutet das aber auch, dass das Azure AD als Ersatz für ein lokales AD untauglich ist, denn dazu fehlt eine Menge an Funktionalität. Computer lassen sich in Azure AD schon deshalb nicht in eine Domäne integrieren, weil Azure AD das Domänenkonzept gar nicht implementiert. Wer Rechte über Gruppenrichtlinien zuweisen will, scheitert daran, dass es diese in Azure AD ebenso wenig gibt wie LDAP, NTLM oder Kerberos. Und auch die im Active Directory vorgesehene Hierarchie, die "Organizational Units" ermöglicht, fehlt in Azure AD komplett.

Was allerdings mit Azure AD funktioniert, ist das Prinzip der "Single Source of Truth", wenn es um Benutzerzugänge geht. Denn Azure AD bietet eine Möglichkeit, Benutzer und Passwörter aus bestehenden Active-Directory-Setups zu synchronisieren. Wenn Firmen also Software nutzen, die sich an Azure AD als Authentifizierungs- und Autorisierungsdienst heften kann, lässt sich mittels der Synchronisation des On-Premises-AD mit dem Azure AD überall dieselbe Benutzerbasis verwenden. Selbst für Anwendungen, die unmittelbar nicht mit Azure AD reden können, bietet Microsoft einen Ausweg: Der "Azure Application Proxy" lässt sich vor konventionelle Webanwendungen schalten, kommuniziert im Hintergrund aber mit Azure AD. Passen Benutzername sowie Passwort, leitet der Application Proxy den Client zu einer Website weiter, die zum Beispiel per HTTP-Authentifizierung gesichert ist und vom Application Proxy gleich die richtige Kombination aus Benutzername und Passwort geliefert bekommt.

Wirklich befriedigend im Hinblick auf das eigentliche Ziel unseres Artikels, nämlich das Loswerden einer lokalen Active-Directory-Instanz, ist das natürlich nicht. Die gute Nachricht lautet: Microsoft bietet mittlerweile auch ein "echtes" Active Directory in seiner Cloud an, das allerdings deutlich weniger im Rampenlicht steht als Azure AD. Die Rede ist von den "Azure Active Directory Domain Services" (Azure AD DS oder AAD DS). 

Ein Blick auf die Feature-Liste von Azure AD DS verschafft dem Microsoft-Administrator deutlich schneller das Gefühl, daheim zu sein, als es bei Azure AD der Fall ist. Praktisch ist AAD DS nämlich ein von Microsoft in der Azure-Cloud redundant betriebener Domänencontroller, der den größten Teil der liebgewonnenen Funktionalität lokaler Setups wie gewohnt beherrscht. Sie wollen Ihre Notebooks und Server als Mitglied in die entfernte Active-Directory-Domäne joinen? Kein Problem. Anwendungen in Ihrer IT-Umgebung erhalten ihre Benutzerdaten per LDAP? Auch dafür ist AAD DS zu gebrauchen, und zwar wahlweise per öffentlicher IP-Adresse über das Internet oder per VPN in die Azure-Cloud, das Microsoft ebenfalls anbietet. Kerberos-Authentifizierung sowie das NTLM-Protokoll unterstützt AAD DS ebenso wie verschachtelte Organisationseinheiten (Organizational Units, OU) oder Gruppenrichtlinien. AAD DS kommt einem herkömmlichen, vor Ort betriebenen Active Directory damit also deutlich näher als Azure AD.

Und was aus Sicht des Administrators fast noch die bessere Nachricht ist: Microsoft betreibt AAD-DS-Instanzen komplett ohne Zutun des Anwenders und als Platform-as-a-Service. Um die Redundanz braucht der Admin sich also ebenso wenig zu kümmern wie um das Einspielen von Patches für das zugrundeliegende Betriebssystem oder das Active Directory selbst.

Einen Haken hat die Sache allerdings auch: Die typischen Berechtigungen für Domänenadministratoren sind in AAD DS zwar implementiert, doch leitet der Dienst sie nicht zum Nutzer weiter. Konfigurationsdetails der Domäne sind daher nur über die von Azure dafür bereitgestellten GUIs möglich, nicht aber, wie mancher sattelfeste AD-Admin es möglicherweise gewohnt ist, über den direkten Zugriff auf das AD als Domänenadministrator. Für die meisten Administratoren von AD-Instanzen in KMUs dürfte dieses Detail aber ohenhin eine eher untergeordnete Rolle spielen. Vielerorts kommt AD als zentraler Verzeichnisdienst für die Verwaltung von Benutzern sowie Ressourcen zum Einsatz, und dieser Aufgabe ist auch das von Microsoft in der eigenen Cloud gehostete AAD DS mehr als gewachsen.

Hat ein Unternehmen sich für die AD-Migration in die Cloud entschieden, steht oft die Frage nach dem "wie" auf dem Programm. KMU tun gut daran, an dieser Stelle die Kirche im Dorf zu lassen. Das gilt umso mehr, wenn das Active Directory – wie in solchen Setups fast immer – als zentraler Anmelde- und Autorisierungsdienst zum Einsatz gekommen ist. Die Daten der Benutzerzugänge lassen sich sehr leicht migrieren, sodass ein umfassender Migrationsplan kaum notwendig ist.

Den Weg der Migration begleitet dabei Azure AD, also ein alter Bekannter. Im ersten Schritt legt der Systemverwalter einen Mandanten in Azure AD an, der sich wie beschrieben mit einem On-Premises-AD verschränken sowie synchronisieren lässt. Dann konfiguriert der Admin in AAD DS die neue Domäne, die die zuvor lokale Active-Directory-Domäne ersetzt. Schließlich genügt es, zwischen Azure AD und AAD DS eine Synchronisierung einzurichten. Ist diese abgeschlossen, stimmen die Benutzerdaten aus den dann drei Verzeichnissen überein – und das lokale Active Directory kann in den Ruhestand gehen. Etwas komplexer ist es, wenn auch Maschinen mit ihrer AD-Anbindung in die Cloud migriert werden sollen. Falls der Admin es nicht gerade mit hunderten Endgeräten zu tun hat, ist der Ansatz, die Geräte einzeln von der alten Domäne ab- und an der neuen Domäne anzumelden vermutlich der eleganteste.

Mancher Beobachter wird schnell nervös, wenn es um die Migration von Diensten in eine Public Cloud insbesondere amerikanischer Anbieter geht. Schließlich, so die oft angeführte Kritik, sei bekannt, dass hiesige Unternehmen der US-Regierung vollen Zugriff auf die eigenen gespeicherten Daten einräumen müssten. Auch DSGVO-konform sei das nicht, weil Daten im Sinne des Art. 44 der DSGVO in ein Drittland abwanderten, das sich nicht der DSGVO unterworfen hat oder mit dem eine vergleichbare Einigung in Sachen Datenschutz existiert. Gerade im Kontext von AAD DS verfängt diese Kritik allerdings nur zum Teil, und zwar aus mehreren Gründen.

Einerseits migrieren Unternehmen, wenn sie AAD DS nutzen, nur einen Teil der eigenen Daten in die Cloud – nämlich die Benutzernamen, Passwörter und eventuelle zusätzliche Metadaten einzelner Geräte. Wer vom lokalen Active Directory auf eines in der Cloud umsattelt, lädt eben nicht gleich den gesamten Inhalt des lokalen Storage ins Internet, wie es bei anderen Diensten manchmal der Fall ist. Natürlich sind Login-Namen und Passwörter ebenfalls sensibel, doch ermöglichen sie nicht unmittelbar den Zugriff etwa auf Geschäftsdaten eines Unternehmens.

Hinzu kommt ein Faktor, den viele KMU-Admins unterschätzen: Ein Active Directory "richtig" und sicher zu betreiben, verursacht zu unterschätzende Aufwände. Das Problem, ein sinnvolles Hochverfügbarkeitssetup zu bauen, ohne dafür die Infrastruktur zur Verfügung zu haben, hat dieser Artikel bereits aufgegriffen. Hinzu kommt, dass Sicherheitsupdates für Dienste wie das Active Directory oder das darunterliegende Windows oft mit höchster Dringlichkeit einzuspielen sind. Dies indes geht manchmal nicht reibungslos vonstatten, was noch mehr Aufwand bedeutet. Und weil sich oft der passende Zeitpunkt für einen AD-Neustart nicht findet, weil dieser das Büro für mehrere Minuten lahmlegt, ignoriert mancher Admin das Thema Sicherheit gleich ganz. Das wiederum öffnet Angreifern Tür und Tor, sodass sich der Systembetreuer um die Sicherheit seiner Daten mindestens ebenso viele Sorgen wie in der Cloud machen muss.

Als riesiger Anbieter ist Microsoft hingegen gewohnt, Onlinedienste und ihre Daten effektiv zu schützen. Dass Angreifer bei Azure einmarschieren und Daten mitnehmen, ist jedenfalls weniger wahrscheinlich. als dass ein Active Directory in der Besenkammer zum Angriffsziel wird und der Angriff erfolgreich verläuft. Nicht zuletzt gehören zum Lieferumfang von AAD DS zudem automatische Back­ups, die der Systemverwalter bei Bedarf freilich auch herunterladen kann. Findet ein Angriff also doch mal erfolgreich statt, bestünde bei AAD DS noch immer die Möglichkeit, zu einem sicheren Backup der Nutzerdaten aus der Vergangenheit zurückzukehren – dann zumindest, wenn der Beginn des Angriffs klar identifizierbar ist.

Gerade für kleine und mittlere Unternehmen können die Azure Active Directory Domain Services eine echte Alternative zum lokalen AD sein. Viele der lästigen Wartungsaufgaben im Active-Directory-Kontext fallen in der Cloudvariante weg und gleichzeitig werden KMUs regelmäßig keine der Funktionen brauchen, die in AAD DS anders als in der On-Premises-Variante fehlen. Wer viel Zeit in die Wartung eines lokalen AD steckt, die besser woanders investiert wäre, sollte sich AAD DS jedenfalls genauer ansehen. Zwar schafft das einen Posten auf der Opex-Liste: Weil AAD DS ähnlich wie die meisten Azure-Dienste einem Abo-Modell unterliegt, fallen für die Nutzung monatliche Gebühren an. Gerade für KMU dürften diese allerdings im erträglichen Rahmen liegen und jedenfalls nicht die Kosten übersteigen, die mehrere Stunden Arbeit am AD duch einen durchschnittlichen IT-Dienstleister verursachen.