Als zentrale Benutzerverwaltung für Windows Clients gibt es neben dem Microsoft Active Directory (AD) unterschiedlichste Lösungen. Eine sehr bekannte und beliebte Open Source Alternative ist das Samba AD. Mit der Einführung von Microsoft 365 oder Microsoft Azure stehen viele jedoch vor der Herausforderung das lokale AD mit dem Azure AD für die Cloud Dienste zu verbinden. Wie eine Active Directory Migration erfolgreich umgesetzt werden kann? Mehr dazu erfahren Sie in diesem Beitrag..
Vorüberlegungen zu einer Active Directory Migration
Motivation
Für Microsoft Cloud Dienste wie Microsoft 365 oder Microsoft Azure wird im Hintergrund als zentrale Identitäten- und Zugriffsverwaltung das Azure Active Directory (Azure AD/AAD) verwendet. Dieser IDaaS (identity as a service) unterstützt neben modernen Authentifizierungsprotokollen wie SAML 2.0, OpenID Connect und OAuth 2.0 auch den Aufbau hybrider Szenarien, also die Einbindung lokaler Workloads. Diese Szenarien funktionieren jedoch mit dem Samba Active Directory (AD) nicht zuverlässig und die Migration zu Microsoft Active Directory ist empfehlenswert.
Ziel
Ziel dieses Artikels ist die Active Directory Migration von Samba zu Microsoft Active Directory Domain Services (ADDS). Im Anschluss deren Anbindung an das Azure AD und damit der Aufbau einer sogenannten “hybrid identity“. Denn obwohl eine vollständige Migration zu AAD möglich ist, gibt es verschiedene Gründe ein klassisches AD weiter zu betreiben. Dazu gehören z.B.:
- Einbindung von NAS-Systemen
- Einbindung von Linux-Systemen
- Nutzung von Single Sign On für Windows Virtual Desktop
Dabei muss das AD jedoch nicht zwangsweise lokal betrieben werden. Wir empfehlen vielmehr die Bereitstellung eines Availability Sets mit zwei VMs als AD DS innerhalb eines Hub-Netzwerkes in Azure.
Ausgangssituation
Die Ausgangssituation ist das vom Samba Team entwickelte Samba Active Directory. Die im Jahr 2012 veröffentlichte Version 4.0 unterstützte erstmals Active Directory kompatible Domaincontroller. Die vorhandene Installation besteht aus zwei replizierenden Samba AD Domaincontrollern (DC), die mit Hilfe der Samba Dokumentation installiert wurden. Dabei wurde gezielt auf weitere Abhängigkeiten verzichtet.
- Es wurden das interne LDAP- und DNS-Backend verwendet.
- Das Forest- und Domain-Level ist 47 (Windows Server 2008 R2).
- Die Samba Version ist 4.6 oder neuer.
- Die lokale Zertifizierungsstelle basiert auf OpenSSL.
Ablauf der Active Directory Domain Services Migration
Samba unterstützt Active Directory (AD) Schema Version 56 (Windows Server 2012) und 67 (Windows Server 2012 R2). Damit besteht die Möglichkeit Windows Server 2012 und 2012 R2 zur Domäne hinzuzufügen. Jedoch wird für den Join seit Windows Server 2012 das Windows Management Instrumentation (WMI) Protokoll benötigt. Folglich führt der Weg führt über einen Windows Server 2008 R2 DC und sieht grob wie folgt aus:
- Demoten eines Samba Active Directory DC
- Promoten eines Windows Server 2008 R2 DC
- Kopieren und Aktivieren des SYSVOL Share auf dem Windows DC
- Demoten des zweiten Samba Active Directory DC
- Promoten eines Windows Server 2012 R2 DC
- Demoten des Windows Server 2008 R2 DC
- Promoten eines Windows Server 2019 DC
- Demoten des Windows Server 2012 R2 DC
- Promoten eines zweiten Windows Server 2019 DC
Grundsätzlich werden vor einem Demote die FSMO-Rollen-Halter geprüft und diese ggf. übertragen. Nach einem Demote die DNS Einträge geprüft und ggf. korrigiert und der Replikationsstatus des AD geprüft. Bei diesen Aufgaben hilft, vor allem zu Beginn, die hervorragende Samba Dokumentation:
Samba Dokumentation
- Verifying the Directory Replication Statuses
- Transferring and Seizing FSMO Roles
- Demoting a Samba AD DC
- Verifying and Creating a DC DNS Record
- Joining a Windows Server 2008 / 2008 R2 DC to a Samba AD
- Joining a Windows Server 2012 / 2012 R2 DC to a Samba AD
Durchführung der Active Directory Migration
Der “große” Schritt
Der vermeintlich große Schritt von Samba zu Microsoft ist, auf Grund der Kompatibilität von Samba 4.0 zu Windows Server 2008, in der Realität gar nicht so groß. Mit Hilfe der obigen Samba Dokumentation ist das Demoting a Samba AD DC des “zweiten” Samba DC unproblematisch. Vor diesem Schritt wird die Synchronisation des AD geprüft und die des SYSVOL-Share beendet. Da Samba “DFS-R” derzeit noch nicht unterstützt, ist dieser Vorgang vom eingesetzten SysVol replication (DFS-R)-Verfahren abhängig. In der Regel kommt dabei Rsync zum Einsatz und es wird lediglich der entsprechende Cronjob deaktiviert.
Weiterhin verlief die Integration des Windows Server 2008 R2 DCs fehlerlos. Als Nacharbeiten bei diesem Schritt war das Erstellen der A- und objectGUID-CNAME-Records notwendig (s. Verifying and Creating a DC DNS Record). Die Synchronisation des Verzeichnisses lief problemlos, auf Grund des Fehlens der “DFS-R”-Unterstützung waren erwartungsgemäß die folgenden Nacharbeiten für das SYSVOL-Share notwendig:
- Aktivieren des SYSVOL-Share: Enabling the Sysvol Share on a Windows DC
- Kopieren des SYSVOL-Share: Robocopy based SysVol replication workaround (hier wurden lediglich die beschriebenen Parameter genutzt, um das Share einmalig auf den 2008 R2 DC zu transferieren, da der letzte Samba DC im nächsten Schritt entfernt wurde)
Exkurs FSMO-Rollen
Vor dem nächsten Schritt, dem Entfernen des letzten Samba DC, müssen die FSMO-Rollen-Halter geprüft und die Rollen ggf. übertragen werden. Dabei ist in der Regel von den folgenden fünf Rollen die Rede:
- Schema master
- Domain naming master
- RID master
- PDC emulator
- Infrastructure master
Die Übertragung dieser Rollen kann grundsätzlich mit grafischen (Anzeigen und Übertragen von FSMO-Rollen) oder Kommandozeilen-Tools (Samba: Transferring and Seizing FSMO Roles oder PowerShell: Move-ADDirectoryServerOperationMasterRole) bewerkstelligt werden. Zusätzlich ist im ADDS-Umfeld jedoch auch die Beachtung der Infrastruktur-Partitionen der DNS-Server notwendig, vor allem bei den Migrationen von Samba und Windows Server 2008 zur nächsten Version. Die korrekten Einstellungen werden mit Hilfe von ADSIEdit geprüft und angepasst. Dazu für die folgenden Partitionen mit ADSIEdit immer zum Ziel-DC verbinden (das ist wichtig, um Fehler zu vermeiden):
- Für Domänen-DNS-Zonen: DC=DomainDnsZones,DC=Contoso,DC=Com
Öffnen der Einstellungen des Objektes “CN=Infrastructure,DC=DomainDnsZones,DC=Contoso,DC=Com”
Anpassen des Attributes “fSMORoleOwner” zu “CN=NTDSSettings,CN=Name_of_DC,CN=Servers,CN=DRSite,CN=Sites,CN=Configuration,DC=Contoso,DC=Com” - Für Forest-DNS-Zonen: DC=ForestDnsZones,DC=Contoso,DC=Com
Öffnen der Einstellungen des Objektes “CN=Infrastructure,DC=DomainDnsZones,DC=Contoso,DC=Com”
Anpassen des Attributes “fSMORoleOwner” zu “CN=NTDSSettings,CN=Name_of_DC,CN=Servers,CN=DRSite,CN=Sites,CN=Configuration,DC=Contoso,DC=Com”
Der “kleine” Schritt
Der vermeintliche kleine Schritt, das Entfernen des letzten Samba AD DC, erfordert deutlich mehr Aufwand als Eingangs angenommen. Da das in der Samba Dokumentation beschriebene Demoting a Samba AD DC-Verfahren schon zu Beginn fehlschlägt. Folglich haben wir den letzte Samba DC heruntergefahren und die offizielle MS Dokumentation zur Bereinigen von AD DS-Metadaten befolgt. Anschließend ist es sehr wahrscheinlich notwendig, die SRV-Records der DCs im DNS neu anzulegen. Hierbei hilft die ausgezeichnete Anleitung Clean up Domain Controller DNS Records with Powershell von Dr Scripto. Als Nächstes empfehlen wir sicherheitshalber die beiden folgenden GPOs neu zu erstellen:
- Default Domain Policy:
dcgpofix /target:domain - Default Domain Controller Policy:
dcgpofix /target:dc
Im Anschluss sind dort etwaige Anpassungen wie Kennwort-Richtlinen wieder einzupflegen!
Die nächsten Schritte
Die Migration des AD von Samba zu Microsoft ist somit bereits geschafft. Im weiteren Verlauf verwenden wir den beschriebenen Ablauf weiter, um bis auf Server 2019 zu aktualisieren. Währenddessen wird auch der Lift von lokalen Maschinen zu IaaS VMs auf Azure vollzogen. Jedoch müssen wir im Verlauf die Zertifikate der DCs noch manuell mit Hilfe von OpenSSL ausstellen und verteilen, bis die Einführung der AD Zertifikatsdienste erfolgt ist.
Anbindung des Azure Active Directory
Die Anbindung an das Azure AD und damit der Aufbau einer sogenannten “hybrid identity” können wir über folgende Szenarien abbilden:
- Password hash synchronization (PHS)
- Pass-through authentication (PTA)
- Federation (AD FS)
Eine vollständige Beschreibung dieser Szenarien würde den Rahmen dieses Artikels sprengen, aber so viel sei an dieser Stelle gesagt. Obwohl eine Federation mittels Active Directory Federation Services (ADFS) einige Vorteile bieten mag, ist für sehr viele Kunden eine Anbindung über Password hash synchronization absolut ausreichend. Denn diese ist wartungsarm, damit wenig anfällig und kostenfreundlich. Dabei synchronisieren wir AD Objekte mit Hilfe von Azure AD Connect in das Azure AD. Bei der Entscheidungsfindung hilft die Azure Dokumentation:
Fazit
Obwohl die Migration eines OpenSource-basierten Verzeichnisdienstes zu Microsoft Active Directory im ersten Moment abwegig erscheint, ist sie nicht nur möglich, sondern auch nahtlos durchführbar. Dabei ist die Erfüllung der genannten Voraussetzungen entscheidend, um die notwendigen Arbeiten ohne größere Ausfallzeiten durchzuführen. Schließlich wird das gezeigte Szenario selbstverständlich mit Technologien wie Azure Monitor, Update Management, Azure Security Center und Azure Sentinel ausgebaut.
Sie haben weiteren Fragen, Anregungen oder Ideen zu Samba Active Directory und Microsoft Azure? Dann nehmen Sie gerne jetzt Kontakt mit uns auf!