Grundlagen

Jahrelang haben wir das lokale Active Directory als "Master" angesehen und AzureAD wurde per ADSync einfach nachgeführt. Microsoft erweitert aber AzureAD immer mehr zu einer zentralen Identity-Plattform, über die auch Anmeldungen an anderen Diensten per OAUTH möglich sind. Da stellt sich zwangsläufig nicht nur die Frage, wann das AzureAD "führend" wird und Firmen darüber auch die lokalen Identitäten verwalten. Um den Fußabdruck auf der lokalen Seite noch zu reduzieren, kann in dem Zuge auch der lokale ADSync-Server bald wegfallen.

Achtung: Aktuell (Stand Apr 2020) ist dies eine Public Preview

Aus meiner Sicht ist AzureAD Cloud Provisioning heute noch nicht produktiv geeignet.

Bisher

Alle Office 365 Tenants, die ihre Benutzer nicht von Hand verwalten, haben lokal einen ADSync-Server installiert. Dieser Prozess liest alle 30 Min (Default) das lokale Active Directory ausgelesen um Änderungen zu erkennen. Die Sync-Engine hat diese dann gemäß der ebenfalls lokal hinterlegten Konfiguration verarbeitet und in die Cloud übertragen. Dazu hat sich ADSync einer lokalen SQL-Datenbank bedient, die als "Metaverse" alle Objekte (Identitäten) mit ihren Eigenschaften gespeichert hat. So konnte ADSync Änderungen erkennen und differenziell synchronisieren.

Die Lösung ist gut bekannte und viele Dienstleister helfen bei der Umsetzung:

Die Nachteile

Denken Sie nun an Millionen Mandanten, die alle einen Service installieren und betreiben müssen. ADSync ist ziemlich problemlos und kann sich auch alleine aktualisieren aber letztlich liegt viel Arbeit und Problempotential dezentral bei jedem Kunden. Das wird umso kniffliger, je kleiner die Kunden sind.

  • Neue Funktionen
    Verbesserungen in ADSync oder in der Cloud können von den Kunden erst genutzt werden, wenn Sie ADSync aktualisiert und ggfls. die Konfiguration angepasst haben.
  • Weitere Server
    Mittlere Firmen installieren eigene Server, damit diese Funktion nicht auf einem Domain Controller mitläuft, was weitere Lizenzen und Hardware-Ressourcen erforderlich machen.
  • Verfügbarkeit
    Sie konnten auch immer nur einen ADSync-Server gleichzeitig betreiben. Ein zweiter "Cold Standby"-Server kann als Staging-Server aufgebaut werden aber das Umschalten erfolgt manuell
  • 15 Min Verzögerung
    Mit Ausnahme weniger kritischer Dinge, z.B. Kennwortänderungen, werden lokale Änderungen erst nach 30 Minuten übertragen. dieses Intervall kann auf 15 Min reduziert werden, was aber immer noch lange ist.
  • Forest Online
    Ein ADSync kann problemlos mehrere Forests bedienen, aber er muss dazu per LDAP alle Forests erreichen könnten. Das ist gerade bei Merger&Aquisitions nicht immer sofort möglich, weil es keine WAN-Verbindungen gibt oder IP-Adress-Konflikte erst bereinigt werden müssen. Die Installation mehrerer ADSync-Instanzen, die alle den gleichen Forest ansprechen, ist aber nicht möglich.
  • Überwiegend OneWay
    Das Design von ADSync beruht noch darauf, dass das lokale Active Directory der Master ist. Das sehen sie heute noch beim Thema Exchange Provisioning, bei dem die Felder in der Cloud "ReadOnly" sind und über das lokale AD verwaltet werden. ADSync schreibt nur ganz weniger Felder und Objekte ins lokale Active Directory zurück (Siehe ADSync Bidirektional).

Es gibt also einige Dinge, die Microsoft besser lösen könnte. So hat es mich dann nicht überrascht, dass schon auf der Ignite 2019 erste Vorträge und Folien erschienen, sind, die eine Änderung andeuten

Cloud Provisioning

Microsoft möchte aber nicht nur ADSync ersetzen oder umgestalten sondern das AzureAD als zentrale und umfassende Provisionierung-Plattform einsetzen. Schon heute ist es relativ einfach, anhand von Identitäten eines AzureAD auch die Benutzer in anderen Systemen wie z.B. SalesForce etc. zu verwalten. Da ist der nächste Schritt gar nicht mehr so groß, dass das AzureAD auch als Master für lokale AD-Forests genutzt wird.

Interessanter ist aber zuerst die Veränderung von ADSync, die sich nun nicht mehr nur andeutet, sondern schon genutzt werden kann. Ein Großteil der Arbeit des Verzeichnisabgleichs wird in der Cloud durch Microsoft erledigt und lokal wird nur noch ein kleiner Agent installiert, der eine ausgehende Verbindung aufrecht erhält und die Befehle der Provisioning-Engine ausführt.

Lokal würde man also keinen vollwertigen Dienst samt SQL-Datenbank und lokaler Konfiguration mehr vorhalten, sondern nur noch einen kleinen Service, der sogar mehrfach installiert werden kann. So kann auch die Verfügbarkeit verbessert werden und zudem können weitere eigene Server entfallen. Funktionserweiterungen und Konfiguration finden alle in der Cloud statt und der kleine Agent muss eigentlich nur noch etwas LDAP sprechen. Auch das Setup und spätere Updates dürften deutlich einfacher möglich sein. Sogar eine Installation in mehreren Forests, die nicht miteinander verbunden sind, ist möglich.

Ich hatte mich ja schon vor Jahren gewundert, warum jeder Office 365 Kunde ein ADSync installieren musste. Die Active Directory Web Services sind ja eh bei jedem aktuellen Domain Controller installierbar. Allerdings müssten Sie als Kunde dann ihren DC per HTTP aus der Cloud erreichbar machen. Da ist der Agent natürlich allemal besser.

Den Ansatz aus der Cloud über einem lokalen auf lokale Dienste zuzugreifen ist übrigens gar nicht so neu. Für HTTPS-Dienste gibt es z.B. den Azure AD Application Proxy, der auch mit einem lokalen Agenten als Brücke arbeitet. Dies hier ist aber ein anderer Agent.

Da stellt sich dann nur noch die Frage, wie umfangreich Microsoft die Verwaltungskonsole in AzureAD erweitert, dass Sie als Kunden wirklich auch viele anderen lokale Einstellungen eines Active Directory in der Zukunft verwalten können.

Eckwerte

Durch den Wechsel von ADSync/AADConnect zu Azure AD Cloud Provisioning entfällt der aktive Prozess auf ihrer Seite. Aber es gibt noch andere Dinge, die interessant bei dieser Lösung sind:

  • Verfügbarkeit
    Anders als bei ADSync kann Azure AD Cloud Provisioning mehrere lokale Agenten Parallel bedienen. Eine Änderung in der Cloud wird immer an einen verfügbaren Agenten übermittelt. Sollte also ein Agent einmal ausfallen, dann führt eine andere Instanz die Befehle aus. Die Lösung ist also mit zwei oder mehr Agenten schon hochverfügbar. Gehen Sie mal davon aus, dass auf der Microsoft-Seite die Plattform auch hochverfügbar ausgelegt ist
  • 2 Minuten statt 15 Min
    Änderungen im AzureAD werden innerhalb von 2 Minuten zu einem Agenten weiter gegeben. Das ist deutlich schneller als die minimal 15 Minuten von ADSync. Allerdings sind die Änderungen dann natürlich erst bei einem Domain Controller angekommen. Aber die intern AD-Replikation ist bei allen Lösungen ja gleich
  • Mehrere Forests
    Besonders interessant ist die Funktion, dass ein Tenant mehrere Agenten in mehreren Forests bedienen kann. Welcher Agent zuständig ist, wird wohl über die UPN-Domain bestimmt. Bei ADSync müsste der lokale Server sich mit allen Forests verbinden können. Das ist gerade bei Firmenübernahmen und Abverkäufen in der Anfangszeit nicht einfach, wenn die Netzwerke noch nicht gekoppelt sind. IP-Subnetze, IP-Routing und DNS-Auflösung sind hier oft bremsende Faktoren
  • Sicherheit/Dienstkonto
    Der Agent muss natürlich mit einem entsprechend privilegierten Konto im lokalen Active Directory arbeiten.
  • Weniger lokale Systeme
    Der Agent ist lokal natürlich noch erforderlich aber er ist doch sehr viel "leichter" als ein SQL-Express mit MIM/FIM-Instanz, die regelmäßig sich mit der Cloud und Office 365 verbindet um nach Änderungen zu suchen

Es sind schon einige Argumente, die den Wechsel von ADSync zu "AD Cloud Provisioning" speziell für mittlere und kleinere Firmen zukünftig interessant werden lassen

Weitere Links