Einleitung: Wann ist es Zeit, sich zu trennen?
Azure AD Connect ist seit Jahren der Dreh- und Angelpunkt für unzählige Organisationen, die eine hybride Identitätslösung betreiben. Es ermöglicht die nahtlose Synchronisierung von Benutzern, Gruppen und Geräten zwischen Ihrem lokalen Active Directory (AD) und Azure Active Directory (Azure AD), der Identitäts- und Zugriffsverwaltungslösung von Microsoft in der Cloud. Diese Brücke zwischen den Welten hat die Migration und den Betrieb von Hybridumgebungen erheblich vereinfacht.
Doch es kommt der Punkt, an dem die Brücke vielleicht nicht mehr benötigt wird. Organisationen vollziehen zunehmend eine **vollständige Cloud-Migration**, konsolidieren ihre IT-Infrastruktur oder überdenken ihre Identitätsstrategie grundlegend. Wenn Ihr lokales AD keine autoritative Quelle mehr für Ihre Cloud-Identitäten sein soll oder Sie planen, es ganz stillzulegen, müssen Sie Azure AD Connect sicher und sauber von Ihrem lokalen AD trennen.
Dieser Prozess ist jedoch weit mehr als nur das Deinstallieren einer Software. Eine unsachgemäße Trennung kann zu erheblichen Problemen führen: von doppelten Benutzerkonten über Authentifizierungsfehler bis hin zu Datenverlust. Dieser umfassende Leitfaden führt Sie Schritt für Schritt durch die sichere Methode, um **Azure AD Connect vom lokalen AD zu trennen**, und stellt sicher, dass Ihre Identitäten in Azure AD intakt und funktionsfähig bleiben.
Warum eine sorgfältige Planung unerlässlich ist
Die Entscheidung, Azure AD Connect zu trennen, ist eine strategische. Sie beeinflusst, wie Ihre Benutzer auf Ressourcen zugreifen, wie Passwörter verwaltet werden und welche Verzeichnisquelle die „Wahrheit” für Ihre Identitäten darstellt. Daher ist eine sorgfältige Planung das A und O. Betrachten Sie diesen Prozess als eine Art Operation am offenen Herzen Ihrer Identitätsinfrastruktur. Ohne präzise Vorbereitung und Ausführung drohen schwerwiegende Komplikationen.
Ziel ist es, Ihre ehemals synchronisierten Benutzerobjekte in **reine Cloud-only-Objekte** umzuwandeln, ohne deren SID (Security Identifier) oder UPN (User Principal Name) in Azure AD zu ändern, und sicherzustellen, dass sie weiterhin nahtlos auf alle benötigten Cloud-Dienste zugreifen können.
Phase 1: Vorbereitung und Risikoanalyse
Bevor Sie auch nur eine Taste drücken, ist eine umfassende Vorbereitung entscheidend.
1. **Dokumentation der aktuellen Konfiguration:**
* Erfassen Sie alle Einstellungen Ihres **Azure AD Connect Servers**. Welche Organisationseinheiten (OUs) werden synchronisiert? Gibt es benutzerdefinierte Synchronisierungsregeln? Welche Attribute werden gefiltert oder transformiert?
* Halten Sie fest, welche Synchronisationsmethode verwendet wird (Pass-Through Authentication, Password Hash Sync, Federation mit ADFS). Dies hat Auswirkungen auf die spätere Authentifizierung.
* Notieren Sie alle konfigurierten **Anwendungsproxy-Connectors** oder andere Azure AD Connect-bezogene Dienste.
2. **Bestandsaufnahme der Benutzerobjekte:**
* Führen Sie eine detaillierte Analyse Ihrer synchronisierten Objekte durch. Wie viele Benutzer, Gruppen und Geräte sind betroffen?
* Identifizieren Sie alle Benutzer, die ausschließlich über die Synchronisierung erstellt wurden und keine Cloud-only-Pendants besitzen.
* Stellen Sie fest, welche Benutzer eventuell bereits direkt in Azure AD erstellt wurden und später „weich abgeglichen” (Soft Match) wurden.
* Verstehen Sie das Konzept der **ImmutableID**. Dies ist der unveränderliche Anker zwischen Ihrem lokalen AD-Objekt und dem entsprechenden Azure AD-Objekt. Sie muss nach der Trennung gelöscht werden, damit das Objekt ein reines Cloud-Objekt wird.
3. **Backup ist Pflicht:**
* Erstellen Sie ein vollständiges **System-Backup des Azure AD Connect Servers**. Dies beinhaltet auch die SQL-Datenbank (lokale SQL Express-Instanz oder externe SQL-Server).
* Erstellen Sie Snapshots Ihrer Domain Controller. Im Falle unvorhergesehener Probleme können Sie so zum vorherigen Zustand zurückkehren.
* Sichern Sie alle wichtigen Konfigurationsdateien oder Skripte, die mit Azure AD Connect in Verbindung stehen.
4. **Kommunikation mit Stakeholdern und Benutzern:**
* Informieren Sie alle relevanten Abteilungen (IT, Helpdesk, Management) und betroffenen Benutzer über den geplanten Wartungszeitraum.
* Erläutern Sie mögliche Auswirkungen, wie etwa kurzzeitige Anmeldeverzögerungen oder die Notwendigkeit, sich neu anzumelden, falls sich die Authentifizierungsmethode ändert.
5. **Testumgebung (wenn möglich):**
* Wenn Ihre Infrastruktur dies zulässt, führen Sie den gesamten Prozess zuerst in einer separaten Testumgebung durch. Dies hilft, potenzielle Probleme frühzeitig zu erkennen und den Prozess zu verfeinern.
Phase 2: Die Deaktivierung der Synchronisation – Schritt für Schritt
Dies ist die kritischste Phase, in der die Verbindung zwischen lokalem AD und Azure AD unterbrochen wird. Gehen Sie hier äußerst methodisch vor.
1. **Schritt 1: Azure AD Connect Synchronisations-Scheduler deaktivieren**
* Dies ist der erste und wichtigste Schritt, um zu verhindern, dass weitere Änderungen vom lokalen AD in die Cloud synchronisiert werden. Öffnen Sie PowerShell als Administrator auf Ihrem Azure AD Connect Server und führen Sie aus:
„`powershell
Import-Module ADSync
Set-ADSyncScheduler -SyncEnabled $false
„`
* Überprüfen Sie den Status: `Get-ADSyncScheduler`. Stellen Sie sicher, dass `SyncEnabled` auf `False` steht.
* Dieser Befehl stoppt den Scheduler, der für die planmäßigen Synchronisationszyklen verantwortlich ist. Es ist eine sanfte Methode, die Synchronisation anzuhalten, ohne die gesamte Konfiguration sofort zu stören.
2. **Schritt 2: Überprüfung der Synchronisationsstatus**
* Nachdem Sie den Scheduler deaktiviert haben, sollten Sie sicherstellen, dass tatsächlich keine Synchronisierung mehr stattfindet.
* Überprüfen Sie im Azure-Portal unter „Azure Active Directory” > „Azure AD Connect” den Status der Synchronisierung. Es sollte angezeigt werden, dass der letzte Synchronisierungszyklus eine Weile her ist oder ausgesetzt ist.
* Kontrollieren Sie die Ereignisanzeigen auf dem Azure AD Connect Server auf Fehler oder Warnungen bezüglich der Synchronisierung.
3. **Schritt 3: Soft-Deaktivierung der Verzeichnisdienstsynchronisierung in Azure AD**
* Dies ist der endgültige Schritt, um Azure AD mitzuteilen, dass es keine Synchronisierung mehr von Ihrem lokalen AD erwarten soll. Dieser Befehl löscht die **ImmutableID** von allen synchronisierten Objekten in Azure AD und wandelt sie in **Cloud-only-Objekte** um. Dies ist der Punkt, an dem Ihre Benutzer in der Cloud „eigenständig” werden.
* Installieren Sie das `MSOnline` PowerShell-Modul, falls noch nicht geschehen: `Install-Module MSOnline`
* Verbinden Sie sich mit Azure AD als globaler Administrator:
„`powershell
Connect-MsolService
„`
* Deaktivieren Sie die Verzeichnisdienstsynchronisierung:
„`powershell
Set-MsolDirSyncEnabled -EnableDirSync $false
„`
* **Wichtiger Hinweis:** Dieser Befehl benötigt bis zu **72 Stunden**, um vollständig wirksam zu werden. Während dieser Übergangszeit können Benutzer möglicherweise Probleme beim Ändern ihrer Passwörter oder beim Zugriff auf bestimmte Ressourcen haben, je nach Ihrer ursprünglichen Synchronisationsmethode. Planen Sie diese Zeit ein und kommunizieren Sie dies.
* Nachdem der Befehl ausgeführt wurde, können Sie den Status überprüfen mit: `(Get-MsolDirSyncFeatures).EnableDirSync`. Es sollte `False` zurückgeben, sobald der Prozess abgeschlossen ist.
Phase 3: Umgang mit Benutzerobjekten nach der Trennung
Nachdem `Set-MsolDirSyncEnabled -EnableDirSync $false` erfolgreich durchgelaufen ist, sind Ihre ehemals synchronisierten Objekte in Azure AD nun **Cloud-only**.
1. **Die Rolle der ImmutableID:**
* Die **ImmutableID** ist ein eindeutiger, unveränderlicher Bezeichner, der ein lokales AD-Objekt mit seinem entsprechenden Azure AD-Objekt verknüpft. Solange ein Objekt eine ImmutableID hat, weiß Azure AD, dass es von einem lokalen AD synchronisiert wird.
* Durch `Set-MsolDirSyncEnabled -EnableDirSync $false` wird die ImmutableID bei allen Objekten, die zuvor synchronisiert wurden, auf `NULL` gesetzt. Das ist der Moment, in dem die Objekte ihre hybride Bindung verlieren und zu vollwertigen Cloud-Objekten werden.
2. **Was passiert mit synchronisierten Objekten?**
* Alle Objekte, die zuvor synchronisiert wurden, sind jetzt vollständig in der Cloud verwaltet.
* **Passwörter:** Wenn Sie Password Hash Sync (PHS) verwendet haben, sind die Hashes der Passwörter bereits in Azure AD vorhanden, und Benutzer können sich weiterhin mit ihren alten Passwörtern anmelden. Bei Pass-Through Authentication (PTA) oder Verbundauthentifizierung (ADFS) müssen Benutzer möglicherweise ihr Passwort in der Cloud neu setzen oder eine Cloud-basierte Authentifizierungsmethode (z. B. SSPR oder MFA) nutzen, um sich anzumelden.
* **Authentifizierung:** Benutzer authentifizieren sich nun direkt gegen Azure AD. Stellen Sie sicher, dass Ihre Conditional Access-Richtlinien und MFA-Einstellungen korrekt konfiguriert sind und funktionieren.
* **Attribute:** Alle Attribute, die zuvor synchronisiert wurden, verbleiben in Azure AD, werden aber nicht mehr vom lokalen AD aktualisiert. Änderungen an diesen Attributen müssen nun direkt in Azure AD vorgenommen werden.
3. **Wiederherstellung (falls nötig):**
* Sollten Sie nach der Trennung feststellen, dass ein Objekt wieder mit einem lokalen AD-Objekt verknüpft werden muss (z. B. wenn Sie einen Fehler gemacht haben), können Sie dies über den sogenannten „Soft Match” oder „Hard Match” versuchen.
* **Soft Match:** Wenn ein lokales AD-Objekt synchronisiert wird und sein UPN und die primäre SMTP-Adresse mit einem *bestehenden Cloud-only-Objekt* in Azure AD übereinstimmen, versucht Azure AD, diese beiden Objekte zu verknüpfen. Das funktioniert aber nur, wenn das Cloud-Objekt *keine* ImmutableID hat und das lokale Objekt noch synchronisiert wird.
* **Hard Match:** Hierbei wird die ImmutableID eines Cloud-only-Objekts manuell mit dem `objectGUID` eines lokalen AD-Objekts gesetzt. Dies ist der zuverlässigere Weg, sollte aber nur mit äußerster Vorsicht und Präzision angewendet werden, um Datenkorruption zu vermeiden.
4. **Bereinigung von verwaisten Objekten (optional):**
* Nachdem die Synchronisierung deaktiviert wurde, bleiben alle Objekte in Azure AD erhalten. Sollten Sie lokale AD-Objekte haben, die nicht mehr benötigt werden und deren Entsprechungen in Azure AD auch nicht mehr benötigt werden, können Sie diese jetzt sicher aus Azure AD löschen. Überprüfen Sie dies sorgfältig, um ungewollten Datenverlust zu vermeiden.
Phase 4: Deinstallation von Azure AD Connect
Sobald die Synchronisation vollständig deaktiviert ist und Sie sich vergewissert haben, dass alle Benutzerobjekte in Azure AD stabil und Cloud-only sind, können Sie den Azure AD Connect Server deinstallieren.
1. **Wichtige Überlegungen vor der Deinstallation:**
* Stellen Sie sicher, dass keine Anwendungen oder Dienste mehr vom Azure AD Connect Server abhängig sind (z. B. Azure AD Application Proxy Connectors).
* Überprüfen Sie noch einmal den Status der Synchronisierung in Azure AD, um sicherzustellen, dass sie wirklich deaktiviert ist.
2. **Deinstallationsprozess:**
* Die Deinstallation erfolgt wie bei jeder anderen Windows-Software: Gehen Sie zu „Systemsteuerung” > „Programme und Funktionen” und deinstallieren Sie „Microsoft Azure AD Connect”.
* Folgen Sie den Anweisungen des Assistenten. Dieser entfernt die Software, die Konfigurationsdateien und in den meisten Fällen auch die lokale SQL Express-Datenbank.
3. **Bereinigung von AD-Objekten:**
* Nach der Deinstallation bleiben bestimmte Objekte in Ihrem lokalen Active Directory zurück, die von Azure AD Connect erstellt wurden:
* Der **Azure AD Connect Service Account** (z. B. MSOL_xyz).
* Die Sicherheitsgruppe „MSOL_AD_Sync_Admins”.
* Diese Objekte können Sie manuell aus Ihrem lokalen AD löschen, nachdem Sie sich vergewissert haben, dass keine weiteren Abhängigkeiten bestehen.
4. **SQL-Datenbank (falls extern):**
* Wenn Sie eine externe SQL-Server-Instanz für die Azure AD Connect-Datenbank verwendet haben, müssen Sie diese Datenbank manuell löschen, da der Deinstallationsassistent sie nicht entfernt.
Phase 5: Nach der Trennung – Überprüfung und Sicherstellung
Die Trennung ist vollzogen, aber Ihre Arbeit ist noch nicht ganz erledigt. Eine gründliche Überprüfung stellt sicher, dass alles wie erwartet funktioniert.
1. **Überprüfung der Authentifizierung:**
* Testen Sie die Anmeldung für verschiedene Benutzer aus unterschiedlichen Gruppen und mit verschiedenen Berechtigungen.
* Stellen Sie sicher, dass Multi-Faktor-Authentifizierung (MFA) und Conditional Access-Richtlinien korrekt funktionieren.
* Überprüfen Sie die Passworteinstellungen – können Benutzer ihr Passwort in der Cloud ändern?
2. **Überprüfung der Gruppenmitgliedschaften und Zugriffsrechte:**
* Kontrollieren Sie stichprobenartig, ob Benutzer weiterhin die korrekten Gruppenmitgliedschaften in Azure AD besitzen und auf die entsprechenden Cloud-Ressourcen (Microsoft 365, SaaS-Anwendungen) zugreifen können.
3. **Monitoring und Protokollanalyse:**
* Überwachen Sie die Anmeldeereignisse im Azure AD Sign-ins-Log auf ungewöhnliche Aktivitäten oder Fehler.
* Überprüfen Sie die Azure AD Audit Logs auf unerwartete Änderungen an Benutzerobjekten.
* Azure AD Connect Health sollte keine aktiven Server mehr anzeigen.
4. **Dokumentation der Änderungen:**
* Halten Sie den gesamten Prozess und die vorgenommenen Änderungen fest. Dies ist für zukünftige Audits, Fehlerbehebungen oder bei einem erneuten Bedarf an Synchronisierung unerlässlich.
Häufige Fallstricke und Tipps zur Fehlerbehebung
* **Vergessene ImmutableID:** Der häufigste Fehler ist das Vergessen, die ImmutableID sauber zu löschen. Dies kann zu Problemen führen, wenn Sie später versuchen, Objekte erneut zu synchronisieren oder neue Objekte zu erstellen, die den alten ähneln.
* **Berechtigungen nach der Trennung:** Stellen Sie sicher, dass alle Berechtigungen und Zugriffsrichtlinien in Azure AD so konfiguriert sind, dass Cloud-only-Benutzer weiterhin arbeiten können, ohne auf lokale AD-Abhängigkeiten zu stoßen.
* **Kommunikationsausfälle:** Ungenügende Kommunikation mit den Benutzern kann zu Verunsicherung und einer Flut von Helpdesk-Anfragen führen.
* **Backup-Fehler:** Das Versäumnis, funktionierende Backups zu erstellen und zu testen, kann katastrophal sein, wenn etwas schiefgeht.
* **DNS-Caches:** Nach einer Umstellung der Authentifizierung kann es vorkommen, dass Clients oder Anwendungen noch alte DNS-Einträge cachen. Leeren Sie gegebenenfalls Client-DNS-Caches.
Fazit: Ein sauberer Schnitt für eine sichere Zukunft
Die Trennung von **Azure AD Connect** und Ihrem lokalen Active Directory ist ein komplexer, aber machbarer Prozess. Mit einer detaillierten Planung, einem schrittweisen Vorgehen und gründlicher Überprüfung stellen Sie sicher, dass Ihre Identitäten in Azure AD intakt bleiben und Ihre Benutzer weiterhin reibungslos arbeiten können. Dieser „saubere Schnitt” ermöglicht es Ihnen, die volle Leistungsfähigkeit und Einfachheit einer Cloud-nativen Identitätsverwaltung zu nutzen, ohne Altlasten aus der hybriden Vergangenheit mitzuschleppen. Nehmen Sie sich die Zeit, gehen Sie sorgfältig vor und profitieren Sie von einer sicheren und zukunftssicheren Identitätslösung.