Microsoft arbeitet weiterhin an einem wunden Punkt in seiner Strategie für hybride Identitäten: Die Herausforderung, seine Identitätsbrücke zwischen Active Directory Domain Services (AD DS) vor Ort und Azure Active Directory in der Cloud zu implementieren. Diese Brücke besteht aus AD FS für den Verbund und einer Reihe von Dienstprogrammen für die Identitätssynchronisierung, die in Azure AD Connect gipfeln. Azure AD Connect wurde vor kurzem allgemein verfügbar gemacht und macht die Anbindung Ihres lokalen AD DS (und anderer Identitätsdatenbanken wie SQL Server oder LDAP) an Azure AD einfacher als seine Vorgänger DirSync und Azure AD Sync.
Die neuen Funktionen von AD Connect
AD Connect (Sie können mehr darüber erfahren hier) ist ein Konfigurationsprogramm, das die Einrichtung der Identitätssynchronisierung zwischen einer kurzen Liste beliebter Identitätsquellen (einschließlich Active Directory Domain Services natürlich) und optionaler Einzelanmeldung mit AD FS vereinfacht. Es vereinfacht den Einrichtungsprozess erheblich und bietet außerdem neue Funktionen wie das gerätebezogene Zurückschreiben von Attributen aus Azure AD in AD DS.
Eine neue Funktion, die bislang jedoch kaum Beachtung gefunden hat, ist eine, nach der praktisch alle meine Unternehmenskunden fragen: die Option „Azure AD Connect-Staging-Server“. Um diese Option besser zu verstehen, wollen wir zunächst die Situation betrachten, für deren Bewältigung sie konzipiert wurde.
So funktioniert die Microsoft Identitätssynchronisierung
Diese Entwicklung der Synchronisierungsdienstprogramme – DirSync, dessen Nachfolger AADSync und schließlich AD Connect – nutzt eine abgespeckte Version des Metaverzeichnisdienstes von Microsoft, der unter verschiedenen Bezeichnungen wie MIIS, ILM, FIM und seit einigen Monaten als Microsoft Identity Manager (MIM) bekannt ist. Diese Metaverzeichnisdienste verfügen über Konnektoren sowohl zu AD DS als auch zu Azure AD, um Attribute in Konnektorbereiche zu übertragen. Eine Reihe von Synchronisierungsregeln legt fest, ob diese Attribute in ein Metaversum aufgenommen werden, das sowohl lokale Identitätsattribute als auch Azure AD-Attribute umfasst. Schließlich bestimmen ausgehende Synchronisierungsregeln, welche Attribute in Azure AD geschrieben werden.
Abbildung 1: AD Connect-Dienstarchitektur (Bild mit freundlicher Genehmigung von Microsoft)
Hierfür ist ein Server erforderlich, auf dem die Konnektoren konfiguriert und die Regeln definiert sind und der über eine Datenbank-Engine (SQL Server Express oder die Vollversion von SQL Server) verfügt, um die Konnektorbereiche und das Metaversum zu speichern. Diese serverseitige Datenbank verfügt über keine integrierte Fehlertoleranz oder Redundanz, und Clustering wird nicht empfohlen. Und falls Sie nun denken: „Ich stelle die Datenbank einfach aus meinen Backups wieder her“ – auch das wird nicht unterstützt. Grundsätzlich gilt: Wenn der Server ausfällt, müssen Sie entweder den Synchronisierungsdienst deinstallieren und neu installieren oder den gesamten Server aus Backups wiederherstellen.
Das ist nicht ganz so schlimm, wie es zunächst erscheint. Microsoft weist zu Recht darauf hin, dass die Synchronisierung zwar zweifellos ein geschäftskritischer Dienst ist, jedoch kein besonders zeitkritischer; das standardmäßige und empfohlene Synchronisierungsintervall beträgt drei Stunden. Das bedeutet, dass es zwar im Falle eines Ausfalls einige Stunden dauern kann, den Synchronisierungsdienst wiederherzustellen, Sie jedoch höchstens einen Synchronisierungszyklus verpassen werden. IT-Abteilungen in Unternehmen mögen jedoch keine Grauzonen hinsichtlich der Wiederherstellungszeit ihrer Produktionssysteme. In den meisten großen Unternehmen muss ein System, das als besonders wichtig eingestuft wird, über eine gewisse Fehlertoleranz oder eine verbesserte Verfügbarkeit verfügen. „Meinen Sie das ernst?“ – diesen Kommentar habe ich mehr als einmal gehört, wenn ein Unternehmen die Hochverfügbarkeitsfunktionen von DirSync oder AADSync in Betracht zog.
So funktioniert die Option Staging Server
Die Option „Staging-Server“ wurde entwickelt, um diesen Mangel zu beheben. Auch wenn es sich dabei nicht um echte Hochverfügbarkeit handelt, ermöglicht Ihnen die Implementierung eines Staging-Servers, die Identitätssynchronisierung innerhalb weniger Minuten wieder aufzunehmen (sobald Sie sich für ein Failover auf diesen Server entschieden haben).
Um einen Staging-Server einzurichten (Abbildung 2), führen Sie eine identische Konfiguration von Azure AD Connect durch wie beim primären AD Connect-Server, mit einer Ausnahme: Im allerletzten Schritt aktivieren Sie die Option „Staging-Server“. Dadurch wird verhindert, dass die im Dienst des Staging-Servers erzeugten Synchronisierungsergebnisse in Azure AD oder zurück in AD DS geschrieben werden. Dies bedeutet auch, dass das Zurückschreiben von Kennwörtern und die Synchronisierung von Kennwort-Hashes deaktiviert sind, da Ersteres das Schreiben von Änderungen in AD DS und Letzteres das Schreiben von Änderungen in Azure AD erfordert.
Abbildung 2: AD Connect Architektur mit Staging Server
Wiederherstellung nach einem AD Connect-Ausfall
Sollte der primäre AD Connect-Server ausfallen, führen Sie einfach den AD Connect-Einrichtungsassistenten erneut durch und deaktivieren Sie die Option „Staging-Server“ (sowie „Passwort-Writeback“ oder „Hash-Synchronisierung“, falls Sie diese nutzen). Dadurch werden Aktualisierungen in Azure AD und AD DS ermöglicht. Selbstverständlich sollten Sie darauf achten, dass jeweils nur ein AD Connect-Server vollständig aktiviert ist!
Die Option „Staging-Server“ in AD Connect ist eine neue Funktion, die von großen Unternehmen sehr begrüßt werden wird. Sie ermöglicht eine deutlich kürzere Wiederherstellungszeit als ihre Vorgängerversionen und lässt sich ohne besondere Hardware- oder Softwareanforderungen einfach implementieren. Ich bin mir sicher, dass sie für viele Unternehmen zur Standardpraxis bei der Bereitstellung werden wird.
