Domain Rename

Wer gut geplant hat, wird keine Domäne oder Forest umbenennen müssen. Aber es gibt immer noch "alte Forests", die einen DNS-Namen nutzen, der ungeeignet ist und diesen ändern wollen oder müssen. Diese Seite beschreibt das Vorgehen eines Rename der Domäne und verwandte Themen. Prüfen Sie insbesondere die Voraussetzungen des Rename und ob ein paralleler Neuaufbau mit Migration der Benutze, Gruppen, Clients, Server und Dienste nicht der sicherere oder einzige Weg ist.

Der richtige Domänenname

Wenn Sie schon über einen Rename nachdenken, dann haben Sie hoffentlich auch verstanden, warum der bestehende Name unpassend ist und wie der neue Name aussehen muss. Zumindest wenn technische Gründe vorliegen, ist der Rename oft auch ein Blocker für den Projektfortschritt. Wenn organisatorische Gründe, z.B. Firmenumbenennung, der Auslöser sind, dann sollten Sie trotzdem noch mal kontrollieren, dass der neue Name auch dauerhaft bestand hat. Ein Rename ist nämlich keineswegs eine "Routinetätigkeit" und hat umfangreiche Abhängigkeiten auch wenn es letztlich nur um einen Namen geht.

Der Name des Forest und der Domain steckt an vielen Stellen, z.B. im FQDN der Server und Client über den auch Dienste angesprochen werden aber auch intern als Teil des LDAP-Pfads verwendet. Schon allein diese beiden stellen wirken sich auf URLs und Hostnamen aus. LDAP-Pfade erscheinen in Skripten, Zertifikaten u.a.. Daher sollte ein Neuaufbau oder Rename zumindest beim Ziel dann "sauber" sein.

Beim Namen empfiehlt es sich einen DNS-Namen zu nutzen, der auch öffentlich blockiert ist. Drei Optionen sehe ich

  • Split-DNS
    Es kann der gleiche DNS-Name sein, den sie auch im Internet nutzen. Einige Besonderheiten bei DNS sind zu beachten
  • Subdomain
    Auch eine Unterdomäne wie z.B. ad.uclabor.de ist möglich. Diese Domäne muss gar nicht im Internet sichtbar sein.
  • öffentliche (hidden) Domain
    Denkbar ist auch eine gesonderte Domain, die sie natürlich im Internet "gekauft" haben aber extern nicht aktiv nutzen.

Ungeeignet sind natürlich Domänen, die anderen Firmen gehören (Sicherheitsrisiko) oder Domänen, die es (noch) nicht gibt. Ich habe schon Domänen wie "firma.ads" gesehen die solange funktioniert haben bis Google die Top Level Domain ".ads" bereitgestellt hat und VPN-Clients plötzlich gemeint haben, sie wären intern

Denken Sie dabei auch an die Möglichkeit einer Ausstellung von öffentlichen Zertifikaten, die eindeutige Erreichbarkeit bei Partnerverbindungen zwischen Firmen und die Einstufung der Adressen im Browser als "Trusted Intranet".

Voraussetzungen

Gleich vorneweg: Ein Rename einer Active Directory Domäne ist kein "Routinetask", da umfangreiche Änderungen an der Infrastruktur nicht immer sicher abzuschätzen sind. Am einfachsten ist es wenn ihre Umgebung nur aus ein paar Domaincontrollern mit Windows Servern und Clients besteht. Jedes zusätzliche Programm, welches das Active Directory nutzt und per DNS nach Servernamen fragt, wird vor dem Rename betrachtet werden müssen. Ein Risiko bleibt, da Sie es nicht vorab testen können und der Rückweg in der Regel nicht gegangen wird.

Ein Neuaufbau ist natürlich ein Stück Arbeit. Das AD ist schnell installiert aber die Migration zieht sich auch über Tage, Wochen oder sogar Jahre hin. Bei einem Rename ist man viel schneller aber mit einem deutlich höheren Risiko fertig.

Es gibt aber einige Dinge, die ich vorab zu bedenken geben möchte:

  • Kein Exchange
    Sobald sie Exchange 2007 oder höher installiert haben, ist ein Rename nicht mehr möglich. Exchange ist so eng mit dem AD integriert, da alle Konfigurationseinstellungen (Server, Connectoren, Datenbanken etc.) in der Konfiguration-Partition liegen. Eine Rename würde den DN ändern. Hier bleibt nur die Migration in einen neuen Forest.
  • Sonderfall AD-Integrierte PKI
    Wenn sie heute schon eine Zertifizierungsstelle betreiben, dann müssen Sie einige Voraussetzungen beachten. Insbesondere wenn die CRLs als LDAP-Pfad angegeben sind oder CAs auf Domain Controller installiert sind. Ein Wechsel ist hier vielleicht auch der Anlass die PKI neu zu machen.
    Siehe auch "Prepare Certification Authorities" https://technet.microsoft.com/en-us/library/cc816587
  • Achtung Domain-DFS
    Der Rename ändert die DFS-Einstellungen für SYSVOL und NETLOGON aber nicht für andere "Domain-DFS"-Einstellungen.
  • Memberserver und Client brauchen zwei Reboots
    Nach dem Rename der Umgebung müssen alle Domainmitglieder diese Änderung bekommen. Das passiert eigentlich automatisch während der nächsten zwei Reboots. Das muss natürlich eingeplant werden, dass möglichst viele Endgeräte online sind. Es gibt aber auch sicher Geräte, die nicht "online" sind. Hier ist eine Downtime für Clients aber vor allem auch Server einzuplanen Auch die Domaincontroller booten natürlich zweimal durch.
  • DNS-FQDN ändert sich
    Durch den Rename ändern sich natürlich die FQDNs der Server und Clients. Das hat Auswirkungen auf Netzwerk-Verknüpfungen, ggfls. Computerzertifikate und Konfigurationseinstellungen in Applikationen. Alte Namen könnten im DNS per CNAME weiter bereitgestellt werden und besondere Namen wie z.B. "autodiscover.<maildomain>" müssen auf den richtigen FQDN umgestellt werden
  • Weitere unbekannte Abhängigkeiten
    Der LDAP-DN ändert sich und könnte in verschiedenen Konfigurationseinstellungen hinterlegt sein. Ich denke an Powershell-Skripte, Scanner2Mail-Lösungen mit LDAP-Suchen, Spamfilter, VPN-Systeme, 802.1x. Auch die Änderung des NT4-Domäne wird überall aufstoßen, wo der NT4-Domänenname in der Konfiguration hinterlegt ist, z.B. bei Diensten, die sich so anmelden anstelle den UPN zu nutzen.

Die Liste ist sicher nicht vollständig.

Umstellungsschritte

Wenn Sie sich dann dennoch dazu entschlossen haben, die Domäne im Rahmen eines "Rename" zu ändern, dann durchlaufen Sie im wesentlichen folgende Checkliste.

Schritt Erledigt

Neuen Domänennamen als Zone anlegen.

Beim DCPromo mit DNS-Installation legt der Assistent eine DNS-Zone an. Das müssen Sie hier von manuell machen und eine Zone für die neue Domäne

  • AD-Integrierte Zone mit „secure Updates“
  • DNS-Zone ggfls. in anderen Systemen delegieren/forwarder)
  • Als AD-Integrierte Zone warten, bis alle andere DNS-Server die Zone haben

Umbenennung vorbereiten

Die nächsten Schritte starten den Rename.

REM Zuerst generieren wir eine Domainlist.xml
rendom /list

REM Diese Datei muss editiert werden und der alte Domänenname durch den Zielnamen
REM ersetzt werden
Notepad.exe Domainlist.xml

REM Kontrolle der Änderungen
rendom /showforest
REM Änderungen auf dem Domain Naming master anstoßen. REM Das friert auch alle weiteren Änderungen im AD ein rendom /upload REM Kontrolle, dass diese Aenderung bei allen DCs angekommen ist rendom /prepare

Umbenennung aktivieren

Nach all den Vorarbeiten starten wir die Änderung auf allen DCs

rendom /execute

Jeder DCs macht nun den Change und bootet neu. Denken Sie bei der ersten Anmeldung nach dem Reboot an die neue Domäne beim Benutzernamen.

Group Policy updaten

Auch wenn die Domäne umgestellt ist, sind in den Gruppenrichtlinien noch die alten DNS-Namen und NT4-Namen enthalten. Dazu gibt es folgende beiden Befehle, die auf einem DC nach dem Rename ausgeführt werden.

gpfixup /olddns:<alterDNSName> /newdns: <NeuerDNSName>
gpfixup /oldnb:<AlterNT4Name> /newnb: <NeuerNT4Name>

FQDN der DNS prüfen

Prüfen Sie den FQDN der Domain Controller. Wenn der FQDN noch nicht stimmt, sollten Sie die Konfiguration anpassen:

netdom computername <alterFQDN> /add:<neuerFQDN>
netdom computername <alterFQDN> /makeprimary:<neuerFQDN>

Danach ist ein Reboot ratsam.

Clients Reboot

Die DCs bieten nun die neue Domäne an aber scheinen auch noch auf den alten Namen zu reagieren und in Windows scheint auch Code vorhanden zu sein, der diesen Rename erkennt.

Sie müssen die Domänenmitglieder (Server und Clients) zweimal booten, damit diese die neue Domäne direkt übernehmen.

Vor dem nächsten Schritt sollten natürlich viele Clients den automatischen Prozess übernehmen. Nach dem nächsten Schritt müssen Sie noch nicht umgestellte Client manuell umstellen.

Cleanup

Diese Kompatibilitätsfunktion zur Umstellung der Clients wird mit dem finalen Cleanup ebenfalls mit abgeschaltet.

REM Entfernt verweise auf den alten Namen. Alle Clients, die bis 
REM dahin nicht 
gebootet wurden, wechseln nicht mehr automatisch die Domäne
rendom /clean

REM Löst die Änderungssperre vom rendom /upload
rendom /end

Checks

Eigentlich sollte die Umbenennung damit schon abgeschlossen sein. Ein paar Tests zur Verifikation sollten sie aber doch durchführen, z.B.

  • Kontrolle DNS
    Ist die neue Zone mit passenden Daten befüllt?.
    Die alte Zone kann danach zurück gebaut werden, wenn Sie nicht mit CNAME auf die die neuen Namen weiter leiten.
  • Können Clients in Domain aufgenommen werden?
  • Funktionieren die vorhandenen Trusts

Weitere Links