ADMT

Beachten Sie dazu auch die Seite Org2Org Basics.

Das „Active Directory Migration Toolkit“ ist das universalwerkzeug von Microsoft zur Umstrukturierung von Domänen. Es unterstützt bei der Migration und Übernahme von Benutzern, Computern, Dienstkonten und Diensten, in dem es die Security Principals von einer Domäne in eine andere Domäne des gleichen oder anderen Forests migriert. Dabei werden optional SID in die SIDHistory und das Kennwort übertragen. Zudem kann ADMT Gruppen und deren Mitgliedschaften verwalten.

Sobald bei der Migration auch Exchange oder ein anderer Verzeichnisabgleich (z.B. Microsoft Identity Manager, DirX, Quest Migration Manager) zum Einsatz kommt, müssen die Prozesse aufeinander abgestimmt werden, da ADMT und das Metadirectory im schlimmsten Fall gegenseitig Daten zerstören. Es sollte daher immer sichergestellt sein, dass nur ein System eine Funktion ausübt.

ADMT kann interaktiv per GUI ausgeführt werden, um alle oder eine Teilmenge der Objekte zu migrieren oder per Skript gesteuert werden. Oft übersehen wird die Funktion, mit ADMT immer wieder die Objekte zu migrieren und damit die Zielobjekte einfach nur zu aktualisieren. Damit ist mit ADMT in Grenzen sogar eine Art „Verzeichnisabgleich“ möglich. ADMT pflegt dabei sogar Gruppenmitgliedschaften. Allerdings sind die Möglichkeiten einer Konflikterkennung und Lösung begrenzt. ADMT überschreibt die Daten im Ziel durch die Informationen aus der Quelle. Wenn also kleinere Einheiten migriert werden, dann sollten nach der Umstellung diese Objekte nicht mehr aus der Quelle in das Ziel übertragen werden.

Was kann ADMT ?

Der Leistungsumfang von ADMT ist sehr große. ADMT unterstützt bei der Migration und Umstellung folgender Objekte:

  • Gruppen
    Gruppen können mit SIDHistory übernommen werden und die Liste der Mitglieder kann für bereits migrierten Benutzer aktualisiert werden
  • Benutzer und Dienstkonten
    Benutzer werden optional mit SIDHistory und Kennwort in das Ziel übertragen und in bereits migrierte Gruppen aufgenommen.
  • Computer (Workstation und Server)
    Der Agent kann den Computer in die neue Domäne umziehen und dann sowohl auf dem Dateisystem als auch in der Registrierung und bei Diensten die ACLs aktualisieren
  • Benutzerprofile
    Sogar lokale Profile und Netzwerkprofile können durch ADMT für den migrierten Benutzer umgestellt werden
  • NTFS-Rechte
    Ein generischer Prozess erlaubt es, auf Dateisystemen die Berechtigungen anhand der migrierten Konten anzupassen. bestehende Rechte können ersetzt oder addiert und entfernt werden.
  • Exchange
    ADMT übernimmt, wenn das Schema im Ziel entsprechend vorbereitet ist, auch Exchange relevante Konfigurationseinstellungen bei den Benutzern und Verteilern. Es ist sehr nützlich, dass z.B. ProxyAddresses und das Feld Mail, aber auch Quotas in einem anderen Forest übertragen werden. Die Übernahme von HomeMTA oder HomeMDB etc. ist hingegen nicht sehr hilfreich. für die Übernahme von Exchange Postfachinhalten gibt es dann MailMig o.ä.
  • OCS-Felder
    Wie bei Exchange werden auch Daten der OCS-Einstellungen übertragen, wenn das Schema im Ziel passend ist.

Gerade die Daten, die übernommen aber wenig hilfreich sind, sind später dann wieder gerade zu ziehen.

Achtung: Wenn Sie keine Felder ausschließen, übernimmt ADMT alle Felder, die er in das Ziel übertragen kann. Das kann störend sein, weil z.B. per ADMT migrierte user in der Exchange 2007/2010 Umgebung als "LegacyMailbox" erscheinen, die auf dem alten Server liegen. Hier hilft dann nur die manuelle Korrektur/Löschung der störendenden Felder.

ADMT speichert alle migrierten Objekte in einer Datenbank. Damit wird es möglich, z.B. zuerst die Gruppen zu migrieren und erst in einem zweiten Schritt die Benutzer und danach die Workstations. ADMT erkennt immer wieder die bereits migrierten Objekte und weist die korrekten Daten zu.

Wichtig:
Installieren Sie nur EINE Instanz von ADMT. Die Datenbank liegt auf dem PC, auf dem ADMT installiert wird und sollte während der Migration auch regelmäßig gesichert werden.

ADMT kann genutzt werden, um diese Objekte von einer Domäne zur einer anderen vertrauten Domäne zu migrieren. Wenn beide Domänen innerhalb des gleichen Forest sind, kann allerdings das Quellobjekt nicht bestehen bleiben. Um die SID-History zu übernehmen, darf es im gesamten Forest nur genau ein Objekt mit der gleichen SID geben. Nur bei der Migration in einen anderen Forest oder von einer NT4-Domäne kann das Quellobjekt bestehen bleiben.

Was kann ADMT nicht ?

Es gibt sogar einige wichtige Einschränkungen im Hinblick auf Exchange:

  • keine "Externals Account" bei Migration der Benutzer
    Wenn Sie z.B. einen Benutzer einer Exchange Organisation in einen anderen Forrest migrieren, aber das Postfach zurück lassen, dann unterstützt Sie ADMT zwar bei der Deaktivierung des Quellkontos, aber ADMT trägt nicht das neue Konto als "AssociatedExternalAccount" ein. Der Benutzer kann daher nicht mehr auf das Postfach zugreifen
    Lassen Sie das Konto jedoch aktiv, dann kann der Benutzer dank der SID-History zugreifen, aber Sie haben das Problem, dass sich der Anwender weiter mit dem alten Konto anmelden könnte.
    Hier müssen Sie von Hand oder per Skript eine Lösung schaffen
  • keine Exchange Eigenschaften von Verteilern/Gruppen
    ADMT migriert bei Bedarf alle Sicherheitsgruppen. Allerdings ignoriert ADMT dabei die Exchange Eigenschaften. Ist eine Gruppe in der Quelle auch ein Exchange Verteiler, dann müssen Sie dies im Ziel von Hand wieder aktivieren. Leider müssen Sie dabei auch die sonstigen Exchange Eigenschaften (Mailadressen, Empfangsbeschränkungen, Sichtbarkeit etc.) wieder eintragen.
    Ist die Quelle sogar nur ein Verteiler, so kann ADMT diesen überhaupt nicht migrieren. Sie können Sich behelfen, indem Sie den Verteiler mit einer SID versehen, migrieren und dann wieder zum Verteiler zurückstufen. Aber auch hier kommen die Exchange Eigenschaften nicht mit.
    Wenn zudem nicht alle Postfächer migriert sind, dann enthalten die migrierten Gruppen natürlich noch nicht alle Empfänger. Nicht migrierte Postfächer könnten als Kontakt im AD angelegt werden, aber auch dieser Prozess ist manuell zu lösen.
  • keine Exchange Server
    Mit ADM können Sie Windows Server mit Exchange 5.5 durchaus umziehen, wenn Sie einige Besonderheiten beachten. Bei Exchange 5.5 laufen die Dienste mit einem Dienstkonto, welches Sie ändern können. Ein umzug eines Exchange 2000x Servers mit ADMT ist jedoch nicht sinnvoll, da Exchange sehr tief in der Domäne verwurzelt ist (z.B. Gruppe Exchange Domain Servers, Gruppenrichtlinien, Berechtigungen etc.). Ein umzug in einen anderen Forest ist komplett unmöglich, da dies eine Veränderung der Exchange Organisation bedeuten würde.
  • keine Exchange Dienstkonten
    ADMT unterstützt sie NICHT bei der Migration von Exchange 5.5 Dienstkonten. Nutzen Sie dazu besser die Informationen der Technet, wie sie das Dienstkonto von Exchange 5.5 ändern (siehe auch Schiebung ist alles).
  • Kein "Sync", nur Merge
    ADMT ist kein Ersatz für eine echte Synchronisation. ADMT legt im Ziel nur Objekte an und aktualisiert diese aber ADMT löscht im Ziel keine Objekte, wenn die in der Quelle nicht mehr vorhanden sind und auch Gruppenmitgliedschaften sind immer nur additiv.

Wie Sie sehen ist ADMT ein sehr leistungsfähiges Tool aber besonders im Hinblick auf Exchange bei weitem nicht ausreichend. für die Migration der Postfächer können Sie mit MailMig arbeiten, aber sehr viele Informationen sind von Hand oder mit eigenen Skripten zu übernehmen.

Einen gewissen Teil der Exchange spezifischen Felder kann aber z.B.: der ADC mit übernehmen. Dies ist der Fall, wenn Sie von Exchange 5.5 nach Exchange 2000/2003 innerhalb der gleichen Organisation migrieren. Mit ADMT können Sie dann die Konten in die neue Domäne übernehmen und ADC übernimmt die Exchange Eigenschaften und Verteiler.

Versionen und Kompatibilität

Microsoft hat ADMT immer weiter entwickelt, aber sie bekommen immer noch ältere Versionen herunter laden. Das mag auf den ersten Blick unlogisch erscheinen aber hat natürlich etwas mit der Evolution Es gibt verschiedene Versionen von ADMT mit unterschiedlichen Kompatibilitäten:

Version Installierbar auf Quell Directory Ziel Directory Clientagenten Workstation/Server Download

ADMT 2.0

Server 2000
Server 2003

NT4 SP4
2000
2003

2000
2003

Workstation: NT4SP4, 2000,XP
Server: NT4SP4, 2000,2003

Active Directory Migration Tool v.2.0
http://www.microsoft.com/downloads/details.aspx?familyid=788975B1-5849-4707-9817-8C9773C25C6C&displaylang=en

ADMT 3.0

Server 2003

NT4 SP4
2000
2003

2000
2003

Workstation: NT4SP4, 2000,XP
Server: NT4SP4, 2000,2003

ADMT 3.0
http://www.microsoft.com/downloads/details.aspx?familyid=6F86937B-533A-466D-A8E8-AFF85AD3D212&displaylang=en

ADMT 3.1

Server 2008

2000
2003
2008

2000
2003
2008
2008R2

2000
XP
Vista
Win 7

2000
2003
2008
2008R2

ADMT 3.1
http://www.microsoft.com/downloads/details.aspx?FamilyID=ae279d01-7dca-413c-a9d2-b42dfb746059&displaylang=en

PES 3.1

Server 2000
Server 2003
Server 2008

Any

entfällt

entfällt

Password Export Server Version 3.1 für Windows 2003/2008 x64
64bit: http://www.microsoft.com/downloads/details.aspx?familyid=5B4E5C61-1C00-4DA7-9C0D-130200AED21A&displaylang=en
32bit: http://www.microsoft.com/downloads/details.aspx?familyid=F0D03C3C-4757-40FD-8306-68079BA9C773&displaylang=en

ADMT 3.2

Server 2008 R2

2003
2008
2008 R2
2012
2012R2

2003
2008
2008 R2
2012
2012R2

XP
Vista
Windows 7

2003
2008
2008R2
2012
2012R2

ADMT 3.2
http://www.microsoft.com/en-us/download/details.aspx?id=19188

Migration Guide
http://www.microsoft.com/downloads/en/details.aspx?displaylang=en&FamilyID=6d710919-1ba5-41ca-b2f3-c11bcb4857af

Sie sehen also, dass die ADMT-Version parallel mit dem Server weiter entwickelt wurde, auf dem ADMT selbst installiert wird und welche Quelle nicht mehr "supported" wird. Der Password Export Server 3.1 arbeitet aber mit allen Windows Server Versionen als Quelle, zumindest wenn man von NT4 absieht.

Download und Installation

Auch wenn ADMT auf jeder Windows 2000 und Windows 2003 Server CD enthalten ist, sollten Sie die passende Version (Siehe vorheriges Kapitel) nutzen. Vor allem weil ADMT für Windows 2008 und neuer auch in einer neueren Version mit kommt. ADMT 3.x benötigt mittlerweile eine SQL-Datenbank die bei der Installation gleich abgefragt wird.

Dies ist wichtig, da so auch eine verteilte Installation möglich ist. Da ADMT Konten migriert, muss es natürlich wissen, welche alten Konten und Gruppen zu welchen neuen Konten und Gruppen passen. Wer also mehrere ADMT-Instanzen installiert, sollte immer die gleiche SQL-Datenbank verwenden.

Achtung:
SQL-Express ist nur für die lokale Nutzung geeignet. Bei der Installation mehrerer ADMT-Instanzen muss eine voll SQL-Server-Version installiert werden
Bitte installieren Sie mehrere ADMT-Instanzen mit jeweils eigenen lokalen SQL-Datenbanken nur, wenn Sie genau wissen, was sie tun.

Nach der Installation können Sie ADMT über die Verwaltung starten und sehen eine recht unspektakuläre Oberfläche. Die Assistenten zur Migration erreichen Sie, indem Sie mit der rechten Maustaste auf den obersten Eintrag klicken. Alles andere ist dann allerdings durch einen Assistenten geführt. Sie könnten ADMT aber auch komplett per VBScript steuern. Dazu gibt es ein passendes Objekt und eine Beschreibung in der Hilfe.

Ehe Sie nun aber sofort los migrieren müssen Sie noch einige Vorarbeiten leisten, die sowohl im README, der OnlineHilfe und in kurzer Form auch hier noch mal aufgeführt sind.

  • Namensauflösung
    Zuerst müssen Sie sicher stellen, dass beide Domänen gegenseitig korrekt auflösbar sind. Das können Sie z.B.: durch WINS-Replikation, LMHOSTS und DNS erreichen.
  • Trust und SID Filterung
    Weiterhin müssen sich die Domänen vertrauen. Dies ist der erste Test, ob Sie Schritt 1, die Namensauflösung, auch korrekt abgeschlossen haben
  • PWDMIG + RegistryKeys + Auditing
    Damit ADMT die SID-History und auch die Kennworte migrieren kann, sind auf dem PDC der Quelldomäne einige Registrierungsschlüssel zu setzen und die PWDMIG.DLL zu installieren. Details hierzu finden Sie in der Online Hilfe, TechNet, Readme und selbst bei der Migration meldet sich ADMT, wenn die Voraussetzungen nicht erfüllt sind und ändert die Nach Rückfrage sogar. Allerdings ist dazu ein Neustart des PDCs der Quelldomäne erforderlich. Ebenso ist das Auditing in der Zieldomäne zu aktivieren und einige Mitgliedschaften von Systemgruppen zu ändern.
  • Rechte über Gruppenmitgliedschaften
    Zuletzt müssen Sie noch sicher stellen dass das Konto, welches später die Migration durchführt auch ausreichend Berechtigungen hat. In der Regel erfolgt dies über das hinzufügen des Kontos zur Administratorengruppe. Es ist seit Windows 2003 nicht mehr erforderlich, dass das migrierende Konto gleich Domänen Administrator im Ziel ist. für die Migration von Workstations muss das Konto aber Admin über alle Workstations sein.  Das sind meist nu die Domänen Administratoren der Quelle.

Ich kann hier nur raten, die Dokumentation zu ADMT ausführlich zu lesen.

Von ADMT migrierte Felder

Natürlich überträgt ADMT Felder wie den SamAccountName und einige andere für Windows wichtige Felder. ADMT versucht bis auf wenige ausgeschlossene Felder sogar alle Daten zu übertragen, sofern dies möglich und sinnvoll ist. Dies betrifft auch Felder, die es für Exchange und OCS gibt. Voraussetzung ist aber dabei, dass auch im Ziel die Schemaerweiterungen bereits vorgenommen wurden. Ansonsten werden die Felder mit einer Warnung übersprungen. Interessant ist hier immer die Warnung, wenn Felder in der Quelle stehen, die im Ziel nicht im Schema definiert sind, z.B. Exchange, OCS oder benutzerdefinierte Erweiterungen. In der ADMT Doku Version 3.1 und 3.2 steht:

The first time that you run an ADMT user migration, ADMT generates a system attribute exclusion list, which it stores in its database. The system attribute exclusion list contains two attributes by default: mail and proxyAddresses. ADMT also reads the schema in the target domain, and adds any attributes to the list that are not part of the base schema. Attributes in this list are excluded from migration operations even if the attribute is not specified in the attribute exclusion list. An administrator can change the system attribute exclusion list only by using a script. This protects attributes that are important in order für server-based applications, such as Microsoft Exchange, to work. If the target domain schema is further extended after ADMT has generated the list, administrators must manually add the new attributes to the list, unless they are certain that copying the values of these attributes from the source domain will not interfere with server-based applications.

Insofern ist es also nicht 100% vorhersehbar, welche Felder ADMT im laufe der Migration vorlässt. Wenn Sie z.B. ADMT installieren und erst danach z.B. das Schema auf Exchange 2010 anheben, dann könnte es sein, dass eine Teil der Felder noch ausgeschossen ist, weil diese bei Exchange 2007 schon da waren und andere mitkommen. Offen ist auch, wie dies bei verschiedenen Zielforests zu betrachten ist.

Mein Rat: Lesen Sie aus, welche Felder ausgeschlossen und sind und passen Sie dies auf ihre Anforderungen an.

System Felder Felder

Windows Systemfelder

  • USNCreated
  • USNChanged
  • LastMOdifu
  • distinguishedName
  • MemberOf

Können nicht übernommen werden, da diese Systemfelder vom Ziel verwaltet werden.

Windows

  • UserSID

Landet in SIDHistory, wenn aktiviert

Windows

  • Password

Kann über Password Export Server übertragen werden

Windows Gruppe

  • Member

Die den Quellmitgliedern entsprechenden Zielobjekte werden addiert, wenn diese schon migriert wurden.

Windows Standardfelder

  • Displayname
  • sn (Surname)
  • Und andere

Werden nach meiner Erfahrung 1:1 übernommen

Exchange

  • mail
  • ProxyAdresses
  • HomeMDB
  • showInAddressbook
  • HomeMTA
  • Und viele mehr

ADMT sollte diese Felder NICHT übertragen, da er nur Felder übernimmt, die in der Quelle und im Ziel im "Base-Schema sind". Anscheinend gibt es aber Fälle, in denen diese Prüfung nicht funktioniert und die Felder nicht auf der Exclude-List gelandet sind oder mangels Exchange Schema im Ziel eine Warnung ausgegeben wurde. Prüfen Sie mit einem Testkonto, ob die Felder mitkommen.
Sie sollten NICHT übertragen werden, da der Wert für HomeMTA, HomeMDB etc in der neuen Organisation nicht zutreffen.

OCS

  • msRTCSIP-PrimaryUserAddress
  • msRTCSIP-TargetHomeServer
  • msRTCSIP-OriginatorSid
  • msRTCSIP-PrimaryHomeServer
  • msRTCSIP-UserEnabled
  • msRTCSIP-UserExtension
  • msRTCSIP-FederationEnabled
  • msRTCSIP-InternetAccessEnabled
  • msRTCSIP-ArchivingEnabled

Vergleichbar zu Exchange ist es mehrfach vorgekommen, dass wohl im Ziel noch nicht OCS/Lync installiert war schon mit ADMT gearbeitet wurde. Wurde dann OCS/Lync im Ziel installiert, dann wurden auch diese Felder übertragen.

Allerdings können Sie per VBScript ermitteln, welche Felder auf ihrer Installation ausgeschlossen sind:

REM  Script GetADMT.VBS
Set objMigration = CreateObject("ADMT.Migration")
WScript.Echo "UserPropertiesToExclude:" & objMigration.UserPropertiesToExclude 
WScript.Echo "InetOrgPersonPropertiesToExclude :"& objMigration.InetOrgPersonPropertiesToExclude 
WScript.Echo "GroupPropertiesToExclude :"& objMigration.GroupPropertiesToExclude 
WScript.Echo "ComputerPropertiesToExclude :"& objMigration.ComputerPropertiesToExclude 
WScript.Echo "SystemPropertiesToExclude:"& objMigration.SystemPropertiesToExclude

Um per VBScript die Klasse "ADMT.Migration" instanziieren zu können, müssen Sie zum einen Als Administrator arbeiten (oder user Account Control abschalten) und auf 64bit-Systemen dürfen sie nicht den 64bit CScript nutzen, sondern müssen die 32bit-Version starten (c:\windows\syswow64\cscript.exe)

Bei meinen Installationen waren diese Ausschlusslisten aber immer leer, was mich zum dem Schluss verleitet, dass ADMT gerne alles mit nimmt und grade mal das Systemfeld "SID" auslässt bzw. auf Anforderung in die SIDHistory überträgt. Auf einem Windows 2008 R2 Server mit ADMT 3.2 sind aber schon einige Felder ausgeschlossen.

mail,proxyAddresses,msDS-PSOApplied, attributeCertificateAttribute, audio, carLicense, departmentNumber, employeeNumber, employeeType, gecos,
gidNumber, homePostalAddress, houseIdentifier, ipHostNumber, jpegPhoto, labeledURI, lo
ginShell, memberUid, msDFSR-ComputerReferenceBL, msDFSR-MemberReferenceBL, msDS-Obje
ctReferenceBL, msDS-SourceObjectDN, msExchAssistantName, msExchHouseIdentifier, msEx
chLabeledURI, msRADIUS-FramedIpv6Route, msRADIUS-SavedFramedIpv6Route, msSFU30Alias
es, msSFU30Name, msSFU30NisDomain, msSFU30PosixMember, msSFU30PosixMemberOf, networkA
ddress, nisMapName, otherMailbox, photo, preferredLanguage, registeredAddress, roomNum
ber, secretary, shadowExpire, shadowFlag, shadowInactive, shadowLastChange, shadowMax,
shadowMin, shadowWarning, textEncodedORAddress, uid, uidNumber, UnixHomeDirectory, uni
xUserPassword, userPKCS12, userSMIMECertificate, x500uniqueIdentifier

Um zusätzlich z.B. HomeMTA, HomeMDB und andere Felder auszuschließen, reicht dann der einmalige Aufruf der folgenden Skriptdatei.

Set objMigration = CreateObject("ADMT.Migration")
WScript.Echo " --PRE----- SystemPropertiesToExclude ---:" & vbcrlf _
   & objMigration.SystemPropertiesToExclude

objMigration.SystemPropertiesToExclude = objMigration.SystemPropertiesToExclude _
   + "HomeMDB,HomeMTA,mailnickname,showInAddressBook,msExchHomeServerName, msExch*"

WScript.Echo " --POST--- SystemPropertiesToExclude ---:" & vbcrlf _
   & objMigration.SystemPropertiesToExclude

Ein paar Felder können Sie aber auch innerhalb von ADMT auf der GUI ebenfalls während der Migration ausschließen.

Eine gute Quelle für den Einsatz von ADMT mit Skripten ist die Datei "TemplateScript.vbs", welche in das Verzeichnis C:\Windows\ADMT mit installiert wird.

SID und SID History

Sie haben nun schon mehrfach den Begriff der SID und der SID-History gelesen. Was hat es damit auf sich und warum ist das wichtig ?. Sie nutzen zwar einen Anmeldenamen und das dazu gehörige Kennwort, um sich anzumelden, aber für die verschiedenen Dienste des Netzwerks sind diese Daten nur sekundär. Intern arbeiten Computer mit Nummern oder Kennungen und so kommt es, dass jedes Objekt mit Berechtigungen eine eindeutige Kennnummer, die SID (Security IDentifier) hat. Alle Berechtigungen, z.B.: Auf Postfächer, Freigaben,  Dateien und Ordner werden immer anhand dieser Nummer zugewiesen. Daher ist es auch kein Problem, einen Benutzer umzubenennen etc. Die Rechte bleiben erhalten.

Eine SID funktioniert natürlich nur dann, wenn diese eindeutig und einmalig ist. Daher besteht die SID aus einem domänenabhängigen Teil und einem relativen Teil. Der relative Teil ist beim Administrator immer eine -500. Auch andere besondere Gruppen und Objekte wie Gäste, LocalSystem etc. haben fest vorgegebene SIDs. Normaler Anwender starten mit einer 1000 und werden hoch nummeriert.

Wird nun ein Benutzer von einer Domäne zu einer andere Domäne migriert, so kann er seine SID nicht mitnehmen, da der erste Teil die Nummer der Domäne selbst ist. Wird ein Benutzer daher migriert, so wird immer ein neues Konto mit einer neuen eindeutigen SID am Ziel angelegt. Dieses neue Konto hat dann natürlich erst einmal nicht mehr die gleichen Berechtigungen wie das alte Konto, selbst wenn es gleich heißt und das gleiche Kennwort hat. Natürlich kann das neue Konto nun auch in die bisherigen Gruppen aufgenommen werden und erhält damit einen Großteil der Berechtigungen. Es ist aber für die alten Server nicht das gleiche Konto.

Seit Windows 2000 gibt es nun die Möglichkeit, die bisherige SID eines Kontos einem neuen Konto "zusätzlich" zu geben. Über die SID-History ist es damit möglich, dass ein migriertes Konto neben seiner neuen primären SID auch die früheren SIDs weiter erhält. Beim Zugriff auf eine Ressource werden dem Server alle SIDs (dazu gehören auch die SIDs der Gruppen, in denen der Benutzer Mitglied ist) präsentiert. Er kann also gar nicht unterscheiden, das der neue Benutzer ein "anderer" Benutzer ist. So ist es dem Anwender auch nach der Migration möglich, alle Dienste zu nutzen, die das alte Konto nutzen konnte.

ADMT nutzt für den Export der SID immer den PDC-Emulator der Quelldomäne, auch wenn Sie im ADMT einen anderen DC als Quelle eintragen.

Grenzen der SIDHistory

Damit diese Funktion möglich ist, muss zumindest die alte Domäne der neuen Domäne vertrauen. Sobald solch ein Trust eingerichtet ist, besteht natürlich auch ein Risiko des Missbrauchs. So könnte der Administrator der Zieldomäne bei seinem Konto in die SID-History eines wichtigen Accounts in der Quelldomäne zuweisen und dann so arbeiten, als wäre er dieser Anwender. Damit dies nicht passiert, kennt Windows 2000 eine Funktion namens "SID Filterung". Damit können Sie steuern, welche SIDs der SID-History über einen Trust überhaupt genutzt werden können. Bei einer Migration mittels ADMT müssen Sie daher eventuell an dieser Stelle noch drehen-

Netdom TRUST <TrustingDomain> /domain:<TrustedDomain> /quarantine:No /userD:<domainadminAcct> /passwordD:<domainadminpwd>

Aber auch denn die SIDHistory mit übertragen wird, sind ein paar Fallstricke zu beachten. Das folgende Beispiel soll das etwas verdeutlichen:

Wir haben zwei Domains ALT und NEU, die per Trust verbunden sind und die Benutzer aus ALT sollten mit ADMT nach NEU migriert werden. Um die Sache etwas zu erschweren, gibt die Benutzer aus ALT schon in NEU. Weil es früher vielleicht keinen Trust gab, wurden also während der Koexistenzphase alle Benutzer doppelt gepflegt. Es kann also sein, dass z.B. das Konto NEU\USER1 natürlich in der Gruppe NEU\DomainUser ist und diese Gruppe vielleicht in einer andere Gruppe (häufig TerminalServerUser) aufgenommen ist. NEU\USER1 kann sich also auf NEU\TSServer anmelden.

Nun wird der Benutzer ALT\User1 nach NEU\User1 migriert. Dabei wird durch ADMT das Konto "gemachted", das Kennwort übertragen und die SID von ALT\User1 in die SIDHistory bei NEU\User1 kopiert. Damit das nun "rund" wird, müssen natürlich auch auch aus ALT die Gruppen samt der SID der Gruppe als SIDHistory in die Zielgruppe übertragen werden. Da in dem Schritt auch die Mitglieder gepflegt werden sollten, hat dann der Benutzer NEU\User1 nicht nur seine neue SID und die SIDs der neuen Gruppen, in denen er in NEU drin ist, sondern auch die SIDHistory seines alten Kontos und über die neuen Gruppen auch die SID-History der alten Gruppen.

Achtung: BuildIn Accounts und Gruppen
ADMT kann keine "eingebauten" Gruppen und Benutzer übertragen. Administrator aber auch Administratoren, Domänenbenutzer etc. bleiben bei der Migration außen vor. Sicher war es schon immer eine schlechte Idee, diese Gruppen für die weitere Vergabe von Berechtigungen zu nehmen, aber hier müssen Sie dann manuell Hand anlegen.

Gerade die Besonderheit mit der BuildIn-Gruppe "Domänen-Benutzer" führt oft zu Problemen, die sich aber vermeiden ließen:

  • ALT\User1 will auf Ressourcen zugreifen, auf die NEU\User1 Rechte hat
    So herum funktioniert die SID-History schon gar nicht. Wenn ich mich als ALT\User1 anmelde und glaube, dass ein Server in NEU nun meine SID nutzt, um im AD nach der SIDHistoy zu fahnden und darauf NEU\User1 aufzulösen und mir die Rechte dieses Benutzers gewährt, der täuscht sich.
  • Neu\User1 möchte auf Ressourcen in ALT zugreifen, auf die ALT\Domänen-Benutzer berechtigt ist
    Auch dies funktioniert nicht, da NEU zwar sicher einige SIDs über die SIDHistory seines Account und seiner Gruppenmitgliedschaften bekommt, aber da die BuildIn-Gruppen nicht übertragen werden können, kann er seine Rechte nicht ausüben, die er als ALT\User1 über die dortige Mitgliedschaft in der ALT\Domänen-Benutzer-Gruppe hatte.

Daher ist es ungeschickt Rechte an Buildin Gruppen fest zu machen.

ADMT und Kennworte

ADMT V2.0 kann mittlerweile auch Kennworte migrieren. Allerdings ist es damit erforderlich, dass auf einem DC der Quelldomäne eine DLL (PWDMIG) installiert wird und einige Einträge in der Registrierung getätigt werden.

Allerdings ist darauf zu achten, dass ADMT auch wirklich die Kennworte schreiben kann. Oft ist in der Zieldomäne eine Richtlinie aktiv, die komplexe Kennworte erfordert. Das betrifft auch ADMT.

Aber selbst wenn ADMT die Kennworte migrieren kann, dann wird der Windows 2003 Active Directory Controller den Benutzer auffordern, das Kennwort bei der ersten Anmeldung zu ändern.

Um diese Flag zu löschen, gibt es nun mehrere Möglichkeiten:

  • Handarbeit
    Sie können natürlich mit der MMC für Benutzer und Computer diese Kreuz beim Benutzer abschalten. Das ist aber nur eine Lösung für wenige Konten.
  • Skript
    Sie können nach der Migration der Benutzer mit einem Skript bearbeiten, um das Kreuz zu entfernen. Allerdings müssen Sie eben daran denken, nach der Migration das Skript zu starten.
    Die essentiellen Zeilen im Code sind:

set cont = GetObject("WinNT://msxfaq.local")
cont.filter = Array("user")

for each oUsr in cont
  oUsr.Put "passwordExpired", CLng(0)
  oUsr.SetInfo
next

  • PowerShell
    Seit Windows 2008 R2 können Sie das ganze natürlich auch mit einem Einzeiler in PowerShell einfach machen.
    Beachten Sie dabei aber auch RSAT AD-PowerShell

import-module ActiveDirectory
get-ADUser | Set-ADUser -ChangePasswordAtLogon $false

  • RegEdit
    Der letzte Weg ist ein Eintrag in der Registrierung. Um von ADMT migrierte Konten ohne Aufforderung zur Kennworteingabe anzulegen, müssen Sie den folgenden Wert auf 1 setzen:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\System\Curr­entControlSet\Control\Lsa]
SamRestrictOwfPasswordChange=dword=0,1 oder 2

0 - old behavior, client can change password through OWF password change API, and the new password remains unexpired.

1 - .NET Server default behavior, client can change password through OWF password change API (SamrChangePasswordUser), but the password expires immediately.

2 - more secure behavior, client can''t use OWF password change API. This API (SamrChangePasswordUser) will be totally disabled and return STATUS_ACCESS_DENIED für all clients except für LocalSystem and members of builtin administrators group.

Mit ADModify 1.5 können Sie leider nicht diese Einstellungen durchführen.

ADMT und "Matchen"

Sehr oft finden sich Konfigurationen, bei denen ein Benutzer sowohl in der Quelle als auch in der Zieldomäne schon ein Konto haben. Natürlich ist das nicht "schön" und über Trusts kann das sogar vermieden werden. Aber wenn diese Fall existiert, dann haben wir natürlich ein Interesse daran, dass es ein zusammengeführtes Konto gibt, welches alle Rechte in sich vereint. Und das kann ADMT sogar. Leider habe ich keine Quellen, die die genauen Arbeitsweisen beschreiben aber bislang konnte ich folgendes erkennen

  • SamAccountName
    Wenn ADMT in der ZielUmgebung ein Konto mit gleichem SAM-Account findet, dann kann ADMT dieses Konto "matchen".
  • Weitere Felder
    Ich habe gehört, dass eine ObjectGUID auch matchen würde. Eventuell gibt es noch andere Felder. Hier habe ich aber noch keine Bestätigungen.
  • Include-Datei
    Der sichere Weg, wenn die Zielkonten anders heißen ist aber die Bereitstellung einer Datei, in der alt und Neu übereinstimmen.

Sobald ADMT den Benutzer matched, dann legt es im Ziel kein neues Konto an, sondern nutzt das bestehende Zielkonto und ergänzt es um die Daten der Quelle, d.h. auch die SIDHistory und Kennwort können dann an das vorhandene Zielkonto angewendet werden. Über eine Steuerdatei ist es sogar möglich, auch Konten mit unterschiedlichem Namen in Ziel und Quelle zusammen zu führen.

Bereits gematchte Konten werden in der ADMT-Datenbank hinterlegt, so dass diese Informationen später bei der Migration der Profile, Computer, ACLs herangezogen werden können.

ADMT als DirSync

ADMT ist sicher kein ideales Werkzeug zum Verzeichnisabgleich und zum Verbinden von Organisationen. Aber ADMT kann Benutzer und Gruppen nicht nur einmalig übertragen sondern auch immer und immer wieder aktualisieren. Da ADMT auch per Kommandozeile als auch als COM-Objekt ("ADMT.Migration") per VBScript steuerbar ist, können Sie damit z.B. Benutzer in zwei Forests unidirektional additiv abgleichen.

  • Unidirektional
    ADMT sollten Sie nur einsetzen, um die Objekte aus einem Forest in einem anderen Forest anzulegen. Sie sollten die Objekte im Ziel behandeln, als wären sie schreibgeschützt, da Änderungen in der Quelle die Objekte im Ziel aktualisieren und dort gemacht Änderungen damit ungeschehen wären.
  • Additiv
    ADMT aktualisiert bestehende Benutzer und Gruppen und addiert neue Objekte. ADMT löscht aber keine Objekte, die im Ziel nicht mehr vorhanden sind.

Unabhängig von diesen beiden Beschränkungen werden aber z.B. Kennwort natürlich übertragen, also eine Art Synchronisation, wenn gleich sicher mit größerem Verzug und sie können die Mitgliedschaft von Gruppen und Verteilern damit abgleichen lassen.

ADMT Best Practice

Es gibt massenhaft gute Dokumentationen zu ADMT. Zuallererst natürlich das README im Installationsverzeichnis und nach der Installation von ADMT auch die Online Hilfe. Trotzdem kann natürlich die Funktionsvielfalt des ADMT im ersten Moment für Verwirrung sorgen. Daher hier die einzelnen Schritte in der logischen Reihenfolge. Zuerst müssen Sie mal die Randbedingungen schaffen:

Ihr Migrationsplan könnte daher wie folgt aussehen:

  • Infrastruktur
    Sie müssen die neue Umgebung (Server etc.) installieren und mit den bestehenden Systemen verbinden. Diese Zeit der Vorbereitung sollten sich auch nutzen, um sich mit einer IST-Aufnahme ein Bild von der Quelle zu machen und etwaige Altlasten vorab zu bereinigen. Alle Probleme und schmerzhaften Umstellung en, die nach der Migration sowieso notwendig wären, sollten Sie vorziehen. Wenn Sie z.B. keinen unsicheren POP3-Zugriff mehr erlauben oder komplexe Kennworte fordern möchten, dann sollten Sie einige Wochen vorher dies umsetzen und nicht erst auf den Zielsystemen. Informieren Sie auch vorab, was passiert und was eventuell nicht sofort wieder funktioniert. Sie können in dieser Phase auch schon ADMT installieren und sogar zum Test ein paar Objekte migrieren.
  • Konten
    Am Tag der Migration fangen Sie dann zuerst mit den Gruppen und den Benutzern an. Diese sollten zuerst samt Kennwort und SID-History migriert werden. Prüfen Sie, wie lange die Anwender sich noch mit dem alten Konto anmelden dürfen. Sie machen sich selbst das Leben einfach, wenn Sie einem Benutzer "GENAU" ein Konto zulassen, d.h. nach der Migration sollten Sie die Quelle deaktivieren. Sonst sind Sie nie sicher, ob alle Anwender auch schon die neue Anmeldung nutzen.
  • Exchange/Mail
    Meist ist die Umstellung des "Kollaboration Systems" ein erstes Ziel und daher übertragen wir möglichst früh die Postfächer und Daten in das Zielsystem, damit die Mitarbeiter unter der neuen Adresse erreichbar sind und vor allem im Ziel die Zusammenarbeit (insbesondere beim Merger) vorhanden ist. Natürlich sind das im Ziel erst mal "Linked Mailboxen" mit deaktivierten Konten und die Verteiler werden als Gruppe übernommen und aktiviert.
  • Client
    Bei der Umstellung der Client stellt sich generell die Frage, ob die PCs wirklich per ADMT umgezogen werden sollen, oder ob eine Neuinstallation (z.B.: mit Remote Installation Services) zusammen mit Gruppenrichtlinien nicht vielleicht einfacher oder sauberer ist. Eine Migration mag für Windows 2000 oder XP Workstations noch akzeptabel sein, aber Windows NT4 Workstations oder System mit sehr alten Versionen von Office bzw. Outlook sind vermutlich schneller neu installiert als verschoben und dann aktualisiert. Windows 95 und ältere Systeme können und müssen nicht mit ADMT migriert werden, da Sie kein Computerkonto haben. Dort sollten Sie nur lokal die Arbeitsgruppe und die Anmeldedomäne ändern.
    Zusammen mit der Clientumstellung werden nun aber auch die Benutzerkonten mit ADMT migriert (Mit Kennwort, mit SDIHistory) und in der Quelle deaktiviert. Aus der LinkedMailbox im Ziel wird dann eine normale UserMailbox.
  • Server
    Neue Server können Sie schon lange vorher komplett installieren. Server, die migriert werden, werden am besten mit ADMT umgezogen. ADMT kann dabei auch die Dienstkonten und die Profile dieser konvertieren. Zudem kann ADMT nach der Migration der Benutzer und Gruppen auch die ACLs auf den Festplatten und Freigaben gleich mit konvertieren. Die meisten Server lassen sich damit problemlos umziehen. Probleme gibt es häufig, wenn nicht klar ist, welche Dienste auf dem Server was tun. Kennwort in VBScript-Dateien etc. sind nicht mit dem ADMT umzustellen. Es ist von Vorteil, wenn Sie sich vorher eine Liste der wichtigen Dienste und deren Überprüfbarkeit erstellt haben und nach der Migration eben diese Liste wieder abarbeiten können.
  • Aufräumen
    Gegen Sie zuerst davon aus, dass die Anwender am ersten Tag mit allen Problemen auf Sie zukommen, auch wenn diese offensichtlich nichts mit der Migration zu tun haben. Das können Sie zwar auch sagen und erklären nur wird ihnen niemand glauben wollen. Daher sollten Sie vorab eben durch eine Information genau mitteilen, was passiert, was nach der Migration vielleicht nicht mehr geht und welches erstes Ziel sie nach der Migration erreichen wollen, d.h. welche Dienste wirklich wichtig sind und funktionieren müssen.

Diese Beschreibung nimmt aktuell keine Rücksicht auf eine Migration über einen längeren Zeitraum oder sogar eine Migration nach Abteilungen. Solche komplexeren Umstellung en bedürfen einiges an Erfahrung und eine genaue Analyse der Quelle. Wenn Sie migrieren möchten, aber eine 0 auf 100 Migration vermutlich nicht durchführbar ist, dann sprechen Sie mich bitte an.

Die eigentliche Migration mit ADMT ist letztlich einfach, wenn Sie eine Reihenfolge einhalten. Folgender Ablauf hat sich in der Praxis bewährt aber soll nicht als "einzig richtig" verstanden werden. Abweichungen sind im Einzelfall durchaus möglich, da ADMT auch erneut migrieren kann, d.h. nachträgliche Änderungen mit Einschränkungen in der Quelle in das Ziel einpflegen kann.

Am besten einen Zeitpunkt "X" definieren, ab dem die Quelle nicht mehr verändert wird und alle Gruppen und Benutzer migriert werden. Die Quellkonten sollten gleich deaktiviert werden und alle PCs müssen eingeschaltet sein, um diese ebenfalls zu migrieren. Die Migration einzelner Benutzer oder Abteilungen oder die Streckung über mehrere Tage und Wochen ist genau zu überlegen. Dieser Parallelbetrieb ist unter umständen sehr viel komplexer als eine schnelle Migration mit einer Nachbearbeitung der offenen Probleme.

"Der Fehler ist erst seit der Migration". Mit dieser Aussage werden Sie immer konfrontiert werden, auch wenn viele Probleme nicht auf die Migration zurückzuführen sind. Aber allein dies zu belegen schürt eher den Konflikt und Zwist. Allerdings können Sie viele Aktionen einfach vor der Migration durchführen, z.B. ein Aufräumen der Domäne, die umbenennung von Konten etc. Das entspannt später den Druck.

Nun sollten all ihre Mitgliedsserver, Workstations, Benutzer und Gruppen umgezogen worden sein. Das ist aber nicht alles.

ADMT und Exchange

Aber auch bezüglich Exchange kann ADMT einige Aufgaben erledigen. ADMT kann aber keiner Postfächer migrieren. Dies ist eher eine Aufgabe von MailMig. ADMT kann für folgende Aufgaben genutzt werden:

  • Exchange 5.5 primäre Konten
    Was sich hinter dem Assistent zur "Exchange Directory Migration" verbirgt ist nichts anderes als die Umstellung der primären Konten bei Exchange 5.5. Bei Exchange 5.5 war das Exchange Verzeichnis noch sehr unabhängig von der Domäne bzw. dem Active Directory. Im Exchange Verzeichnis wurde bei jedem Postfach nur ein "Primäres Windows NT Konto" gepflegt. Wird solch ein Konto nun mit ADMT in eine andere Domäne migriert, dann sollte natürlich auch das "Primäre NT Konto" in einem Exchange 5.5. Verzeichnis angepasst werden. Zwar ist das mit der SID-History nicht so kritisch aber trotzdem ratsam.
  • Exchange 5.5 Dienstkonten
    ADMT erkennt aber auch Exchange 5.5 Dienstkonten. Das nimmt ADMT als Grund, dieses Konto eben nicht zu migrieren. Um einen Exchange 5.5 Server in eine andere Domäne zu verschieben, ist ADMT nicht das passende Mittel. Bei Exchange 5.5 können Sie statt dessen das Dienstkonto direkt ändern. (Details auf Schiebung ist alles)
  • Sicherheitsgruppen und Mitglieder
    Wenn Sie Objekte einer Exchange 2000/2003 Umgebung in eine neue Exchange 2000/2003 Organisation migrieren, dann möchten Sie natürlich auch die Verteiler mit übernehmen. Verteiler sind für ADMT einfach Sicherheitsgruppen, die ebenfalls samt den Mitgliedschaften migriert werden können.
  • Exchange Properties
    ADMT überträgt alle Felder (auch Exchange !!) , sofern im Ziel-Forest bereits die Exchange Schema-Erweiterungen vorhanden sind und diese bei der Installation von ADMT noch nicht vorhanden waren. Dann hat ADMT "leider" vergessen, diese Properties auszuschliessen. Ansonsten erhalten Sie eine Warnung, welcher Felder nicht kopiert werden konnten.
  • Q300628 ADMT Does Not Migrate the Exchange System Attendant Service

Die Leistung von ADMT auch Exchange Felder wie HomeMDB und HomeMTA etc. zu übertragen, kann auch störend sein. Per VBScript lässt sich sehr einfach bestimmen, welche Felder ADMT ausschließen soll. (Beschreibung weiter unten)

ADMT und Sharepoint

Leider kann ADMT hier nicht wirklich "helfen", da Sharepoint zwar auch die Windows Anmeldeinformationen nutzt, aber intern eine eine Struktur verwaltet und nur auf die Active Directory Konten verweist. Wird also ein Anmeldekonto von einer Domäne in eine andere Domäne verschoben, migriert oder neu angelegt, dann müssen Sie in Sharepoint die Benutzerzuordnung zurecht rücken. Dazu gibt es eine Kommandozeile "STSADMIN", die gut dokumentiert und gebloggt ist:

ADMT, SAMBA und DumpSID

Man könnte nun auf den Gedanken kommen, mit ADMT auch einfach die Benutzer einer SAMBA-Domäne zu migrieren. Viele Domänen basieren aber auf einer mehr oder weniger alten Version von SAMBA. SAMBA macht einen sehr guten Job ein Unix-System für Windows Clients wie ein Windows Server aussehen zu lassen. Und SAMBA kann sogar als Domain Controller einen NT4 PDC emulieren. Allerdings kann erst Samba 3 einen zweiten SAMBA Server als BDC betreiben (Ausfallsicherheit). Das liegt nahe, da andere Migrationswege mit SAMBA verbaut sind

  • SAMBA kann nur PDC sein oder einen SAMBA BDC (seit Version 3)
  • Ein NT4 BDC kann nicht von einem Samba PDC bedient werden
  • Password-DLL
    Leider kann man die Password-DLL nicht auf Samba einbinden, um das Benutzer Kennwort zu übertragen
  • SID-History
    ADMT akzeptiert SAMBA nicht als gültige als Quelle für die SID zum Übertragen in die SID-History. Samba versteht einfach (noch) nicht die entsprechenden RPCs

Damit ist es nicht möglich, z.B. einen Windows NT4 als BDC zu installieren und dann zum PDC hoch zu stufen. Dann könnte man ja die Benutzer wieder mit ADMT migrieren oder direkt ein Inplace Update auf Windows 2000/2003 machen. Das geht nicht. 

Allerdings kann man in ADMT eine Textdatei bei der Nutzung des "Security Migration Wizard" angeben, in der die alte SID der Quelldomäne auf ein neues Domänenkonto gemappt ist. Alles was hierzu fehlt ist eben diese Liste

Einsatzbereich:
DumpSID hilft ihnen nur, wenn sie mittels ADMT die user, Computer und Gruppen in das Active Directory migrieren (ohne SID History, ohne Passwort, da das Samba als Quelle nicht kann) und dann mit ADMT „danach“ die ACLs im Zielsystem konvertieren wollen.

Ich sende Ihnen DumpSID gerne zu, wenn Sie mit ADMT migrieren wollen und eine Konvertierung der SIDs benötigen. Informationen, warum diese Skripte nicht öffentlich sind, finden Sie auf nicht public.
Ein ähnliches Skript liest aus einem Active Directory die SIDHistory aus und generiert eine entsprechende Datei. Dies ist ideal, wenn Sie früher einmal mit SIDHistory migriert und dann die ADMT verloren/deinstalliert haben. Mit dieser Datei können Sie auch nachträglich noch einmal ADMT installieren und Berechtigungen umschreiben.

Die Migration von Samba ist auch vom SAMBA-Team ein Stück weit beschrieben (Siehe http://samba.org/samba/docs/man/Samba-Guide/upgrades.html#id364040). Allerdings sind nicht alle Aussagen richtig. Aus einer eigenen Migration kann ich sagen:

  • ADMT V3 Version
    Auch wenn viele Beschreibungen nur auf ADMT V2 basieren, so kann ich bestätigen, dass auch ADMT V3 SAMBA 2 und SAMBA3 Benutzer, Gruppen und Computer ins Active Directory migrieren kann, allerdings nur ohne SID-History und ohne Kennwort.
  • Trust
    Entgegen der Aussagen muss dazu nicht unbedingt ein Trust bestehen und auch nicht zwingend der "Administrator" genutzt werden. Ein anderes Konto mit entsprechenden Berechtigungen (gleicher Name und Kennwort in beiden Domains) reicht für die einfache Migration aus. Allerdings können dann keine Roaming Profiles umgesetzt werden und die Migration von Computern ist erschwert.
  • Namensauflösung
    ADMT muss z.B.: auch "1B"-Einträge finden, die aber nicht in WINS statisch gepflegt werden können. Daher sollten Sie WINS-Server der alten und neuen Welt replizieren oder alle Systeme auf die gleichen WINS-Server verweisen lassen. Notfalls können Sie sich mit LMHOSTS behelfen. Beachten Sie, dass SAMBA zwar auch als WINS-Server dienen kann, aber meines Wissens nach nicht replizieren kann.
  • Kein Kennwort
    Mangels Passwort .DLL kann ADMT keine Kennworte übernehmen. Oft sind diese aber in SAMBA oder anderen Dateien auf uNXI sogar im Klartext oder reversibel gespeichert, so dass Sie die Kennwort oft einfach frisch setzen können
  • SID History
    Mit ist es bislang nicht gelungen, dass ADMT, SIDHIST oder ClonePrincipal aus einem SAMBA-DC die SIDs derart auslesen kann, dass diese im AD eingetragen werden können. Leider kenne ich keinen Weg, eine SID direkt in die SIDHistory zu schreiben.

Auch wenn ADMT eigentlich nicht für SAMBA gedacht ist und in der TechNet und Knowledgebase SAMBA nicht in diesem Zusammenhang erwähnt wird, so kann man doch auch hier mit ADMT relativ einfach die Objekte und Computer migrieren. Allerdings funktionieren die "How-To's" der Windows Anleitung natürlich nicht mehr.

Unterstützung durch Net at Work:
Profitieren Sie von unserer Erfahrung im Windows Umfeld und beim Einsatz von ADMT.

ADMT und Filer, NAS, NetApp und andere

Kommen wir noch zu einer anderen Gruppe von Servern im LAN, die für die Migration von Domänen interessant sind. Maßgeblich sind das Server die SMB anbieten aber nicht unter Windows laufen und damit z.B. nicht den ADMT-Agent starten können, welcher lokal alte SIDs durch neue SIDs ersetzt oder erweitert.

So ein Server ist, abgesehen von lokalen Tools" eigentlich nur über das Netzwerk zu erreichen und zu verwalten. Lokal werden meist gerade mal die "Freigaben" eingerichtet aber weniger im Dateisystem herum gearbeitet. Entsprechend gibt es drei Aufgaben zu bewältigen

  • Rechte auf Freigaben anpassen
  • Rechte auf Verzeichnisse und Dateien anpassen
  • Domänenmitgliedschaft ändern

Die beiden ersten Punkte sind bei einer Migration relativ gefahrlos sogar zu testen, wenn Sie keine Stichtagsmigration vorhaben. Sie können nämlich einfach eine neue "Testfreigabe" mit ein paar Dateien, Verzeichnissen, Quotas und Berechtigungen anlegen anlegen und dann die per ADMT erst mal ins Ziel kopierten Benutzer mit den von ihnen vorgesehenen Werkzeugen auf dem NAS-System anpassen.

Wenn Sie die Anwender samt "SIDHistory" kopieren, dann können Sie mit dem neuen Konto einfach prüfen, ob sie weiter auf alle Daten zugreifen können. Denn eigentlich sollte jeder SMB-Server bei einem Zugriff des Clients zwischen primärer SID, SIDs von Gruppenmitgliedschaften oder SIDs der SIDHistory unterschieden.

Aber irgendwann wollen Sie vielleicht die SIDHistory-Altlast entfernen oder Sie können damit nicht arbeiten, so dass der Wunsch einer ACL-Korrektur aufkommt. Hier gibt es wieder zwei Optionen:

  • Add/Remove
    Sie können einfach überall, wo ein Eintrag aus der alten Domäne vorhanden ist, den korrespondierenden Eintrag der neuen Domäne addieren. Das Programm muss natürlich dazu wissen, welche Einträge zu einander gehören. Kann es dies anhand der SIDHistory im Ziel oder durch den gleichen SAMAccountName ermitteln, dann ist das ein einfacher Prozess. Irgendwann, wenn dann alle Systeme umgestellt sind, können Sie die alten ACLs entfernen oder bis zum Abbau des Servers in ein paar Jahren einfach drin lassen. So umgehen Sie auch das Restrisiko, später beim Entfernen etwas "vergessen" zu haben, was nur durch die SIDHistory funktioniert hatte. Besser ist es aber schon auch weil sie zu einem Stichtag sich einigen sollten, wie sie laufende Änderungen an den ACLs pflegen.
  • Replace
    Diese Doppelpflege umgehen Sie natürlich, wenn Sie die ACLs "ersetzen". Das geht sinnvoll natürlich auch nur dann, wenn alle Anwender schon in der neuen Umgebung arbeiten und bislang über die SIDHistory auf die Daten zugreifen.

Aber egal wie sie die Umstellung letztlich angehen, so werden Sie immer zuerst Benutzer und Gruppen schon mal migrieren müssen, damit die neuen SIDs im Ziel existieren. Und erst nachdem sich die Anwender sich wirklich mit dem neuen Konto auch anmelden, können die überhaupt daran gehen, die alten SIDs zu entfernen oder ersetzen. Wenn Sie also keine StichtagsUmstellung erreichen, dann sollten Sie die SIDHistory an dem Zielkonto mit addieren und erst nach der Umstellung der ACLs auf allen Ressourcen auf den Ressourcen und dann auf den Objekten entfernen.

Bild Beschreibung

Ausgangssituation

Wir haben eine alte Domäne mit Benutzern, Gruppen und einem SMB-Server mit Freigaben und ACLs

Diese sollen nun alle in die neue Domäne

Migration der Benutzer und Gruppen mit SID-History

Durch die SID-History kann der Anwender auch nach der Anmeldung im Ziel weiterhin auf seine Dateien in der Quelle zugreifen.

In dem Zug sollten Sie auch die Workstations und die Profile auf den PCs vielleicht in die neue Domäne migrieren. (nicht dargestellt)

Umstellung der ACLs auf den Ressourcen

Wenn alle Anwender sich nur noch im Ziel anmelden, dann können Sie bei den Ressourcen die alte SID durch die neue SID ersetzen. Wer vorsichtiger ist, addiert die neue SID und hebt sich das Löschen der alten SID für später auf.

Hinweis: für diverse Tools die "Alt gegen Neu" ersetzen, muss der ausführende Client noch in der alten Umgebung sein, damit er auch den alten user "findet". In der neuen Umgebung verweist ansonsten die SIDHistory schon auf das neue Konto.

Aufräumen

Wenn nun alles umgestellt ist, dann darf die alte Domäne abgebaut werden. Und wenn Sie sicher alle alten Vorkommen der SIDs nicht mehr benötigen, dann können Sie auch die SIDHistory bei den Anwendern und Ressourcen entfernen.

Für die Umstellung der ACLs gibt es gleich mehrere Möglichkeiten, die alle ihre individuellen Vorteile/Nachteile haben. Wer hoffentlich schon in der Quelle überwiegend mit Gruppen zur Vergabe von Berechtigungen gearbeitet hat, sollte nicht all zu viele ACLs zu konvertieren haben.

Methode Bewertung und Links

ADMT Agent

ADMT bringt selbst einen Agenten mit, welcher vom ADMT-System aus auf alle anderen Server und Clients verteilt werden kann. Dieser "kennt" die alten und neuen Konten und kann die ACLs entsprechend umstellen.

Vorteil: Einfach und enthalten, GUI-Gestützt

Nachteil: Nur für Windows Systeme einsetzbar

SUBINACL
ICACLS

Diese Kommandzeilentools erlauben die Ersetzung von Berechtigungen "Alt gegen Neu". Sie sind sehr flexibel und erlauben nahezu jede Ersetzung. Da sie zum Teil auch über LAN mit UNC-Pfaden arbeiten, können Sie damit sogar Rechte auf dem ein oder anderen NAS-System ersetzen.

REM Ersetzen der alten Rechte durch neue
subinacl /subdirectories X:\* /migratetodomain=SOURCEDOM=TARGETDOM

subinacl /subdirectories X:\* /migratetodomain=SOURCEDOM=TARGETDOM


REM Rechte ausgeben
subinacl /subdirectories \\sharesfiler\adm$ /display

ICACLS Y:/ /substitue <SIDOld> <SIDNew>

Einige Tools haben vielleicht mit UNC-Pfaden Probleme. Oft hilft dann einfach das Verbinden eines Laufwerksbuchstaben und optional noch ein SUBST. Hinweise findet man besonders wenn man für Migrationen mit NetApp sucht

3rd Party

Gerade wenn sie ein NAS-System haben und die SMB-Inplementierung nicht komplett ist, können Sie oft nur darauf vertrauen, dass der Hersteller eigene Tools bereit stellt. Es gibt von Herstellern auch Tools, die z.B. schneller arbeiten oder Besonderheiten des NAS-Systems berücksichtigen.

Im Bezug auf das Dateisystem gebührt dem "Owner" eine gesonderte Betrachtung, da dieser auch Rechte ändern kann und einige Produkte dieses Recht auch für Backup/Restore oder Quotas heran ziehen. Spätestens wenn sich auch der Anwender mit dem neuen Konto anmeldet, sollten ihm seine Dateien auch weiter gehören.

Was sie noch bedenken sollten ...

Aber selbst wenn die Migration mit ADMT alles wie gewünscht umgestellt hat, so bleiben einige Dinge zu tun, die Sie auf anderem Weg lösen müssen. Hier eine Auswahl:

  • Anmeldedomäne auf den Workstations setzen
    Nach der Migration der PCs und Benutzer sollen sich diese natürlich an der "richtigen" Domäne anmelden. Dazu eignet sich natürlich am besten eine Gruppenrichtlinie, um die "Default Domäne" vorzugeben (Siehe auch Gruppenrichtlinien)
  • Lizenzierungen
    Programme, die in der Lizenz den den "Domänennamen" gebunden haben, könnten nach der Migration zu Problemen führen. Früher hatten einige Programme auch den Servernamen oder die NetWare Seriennummer als Verbindung zur Lizenz. Selbst Checkpoint nutzt heute noch die IP-Adresse der Firewall als Kriterium. SAP nutzt die MAC-Adresse der Netzwerkkarte.
  • Sonstige Anmeldedaten in einer für ADMT nicht lesbaren Form
    ADMT kann nur die Dienste überprüfen und ändern. Wenn Sie aber Programme nutzen, die Anmeldedaten in einer eigenen Form speichern, dann müssen Sie diese manuell anpassen. Dazu zählen z.B. Skripte, Batchdateien, aber vielleicht auch Anmeldeinformationen in ODBC-Verknüpfungen, IIS ASP.NET Anwendungspools, Einstellungen von Überwachungsprogrammen u.a.
  • Vergessene PCs
    Je besser die IST-Aufnahme am Anfang ist, desto eher können Sie Sicher sein, auch alle Systeme umgestellt zu haben. Aber gerade Workstations mit Dualboot und andere Systeme werden oft nicht erreicht und müssen danach manuell umgestellt werden.
  • Anmeldeskripte
    Nach der Migration haben die Benutzer und Computer eine neue NETLOGON Freigabe. Wenn Sie früher schon Anmeldeskripte genutzt haben, dann müssen Sie diese an die neue Umgebung anpassen.
  • Gruppenrichtlinien
    Das gleiche gilt für die Einstellungen durch Gruppenrichtlinien. Am besten ist dabei vorab die Einstellungen der Quelldomäne zu analysieren und entsprechend auf das Ziel bzw. auf einzelne OUs im Ziel umzusetzen.
  • MAPI-Profile neu anlegen oder anpassen
    Mit der Migration der Postfächer durch MailMig ist es erforderlich, dass die MAPI-Profile auf den Computern aktualisiert werden. Hierzu helfen Programme wie PROFGEN und ExProfRe (Siehe Profile Tools)
  • Rename von Benutzern im Ziel
    ADMT ordnet intern anscheinend die alte SID auf den neuen SamAccountName zu. Benennen Sie daher einen migrierten Benutzer im Ziel um, dann funktioniert die Konvertierung von Sicherheitseinstellungen und Profilen für diesen Benutzer nicht mehr.
  • Windows 2008 RODC
    ältere Windows 2003/XP Systeme haben eventuell Probleme bei der Migration, wenn das neue Active Director< für ReadOnly DCs vorbereitet ist
    ADMT, RODC’s, and Error 800704f1
    http://blogs.technet.com/b/askds/archive/2009/10/19/admt-rodc-s-and-error-800704f1.aspx
    944043 Description of the Windows Server 2008 read-only domain controller compatibility pack für Windows Server 2003 clients and für Windows XP clients and für Windows Vista

Einige dieser nach geschalteten Probleme könnten Sie natürlich durch eine entsprechende Vorbereitung reduzieren. Allerdings ist hierbei auch wieder Aufwand und Nutzen abzuwägen. Alle unwägbarkeiten können Sie nicht erkennen und letztlich ist jede Migration individuell. Wenn Sie daher umfangreichere Migrationen planen, sollten Sie vielleicht die Hinzuziehung externer Dienstleister bedenken.

Weitere Links