6
ADMT - Fragen zur Security Translation
Hallo!
Bei der bevorstehenden Intraforrest-Migration erschließt sich mir aus dem ADMT-Guide von Microsoft die Vorgehensweise für die Security-Translation nicht so ganz. Ich werde die Migration folgendermaßen durchführen:
1. Migration der universellen Gruppen
2. Migration der globalen Gruppen (ADMT wandelt diese automatisch in universelle Gruppen um)
3. Umwandeln der domänenlokalen Gruppen in universelle Gruppen und anschließende Migration dieser Gruppen
4. Migration der Benutzerkonten
5. Nun kommt laut Microsoft der Punkt "Konvertieren lokaler Profile" durch Verwendung der dem "Security Translation Wizard", hier schreibt Microsoft einen für mich nicht zu versehenden Hinweis:
"Normalerweise sind keine Aktionen erforderlich, um eine lokales Profil auf Clients zwischen Domänen in der gleichen Gesamtstruktur zu konvertieren, weil die GUID des Benutzers gleich bleibt. Das lokale Profil kann die SID-zu-GUID-Zuordnung verwenden, die in der Registrierung gespeichert wird, um das Profil des Benutzers erneut zuzuweisen und es dann der neuen Sicherheitskennung (Security Identifier, SID) erneut zuzuordnen.
Wenn Sie das Benutzerkonto in eine Domäne innerhalb der Gesamtstruktur migrieren, der Pfad für das lokale Profil jedoch ein anderer ist, wird das Benutzerprofil geändert, und es wird ein neuer Profilordner auf dem Server mit den richtigen Zugriffssteuerungslisten (Access Control Lists, ALCs) erstellt. Der Administrator muss sicherstellen, dass der Benutzer auf den Profilordner zugreifen kann."
Ich selbst habe eigentlich auch gedacht, dass dieser Vorgang auf Grund der SID-History nicht zwingend erforderlich ist und auch nach abgeschlossener Migration und Abschaltung der Quelldomäne ausgeführt werden kann, damit die SIDs sauber sind und die SID-History ggf. abgeschaltet werden kann. Kann das jemand bestätigen? Wir verwenden im übrigen keine servergespeicherten, sondern ausschließlich lokale Profile.
Ist der "Security Translation Wizard" an dieser Stelle eigentlich auch dazu geeignet die SIDs auf Servern, die schon immer in der Zieldomäne sind und von Benutzern der Quelldomäne bereits verwenden wurden, zu ersetzen?
6. Migrieren von Computerobjekten (Clients und Mitgliedsserver)
Hier kann ich ebenfalls den SID-Verlauf migrieren, welchen Unterschied macht das zum vorangegangenen Punkt? Ist das erforderlich, auch wenn in bereits die lokalen Profile im vorangegangenen Schritt konvertiert habe?
7. Manuelles Herunterstufen der DCs der Quelldomäne
8. Manueller Wechsel der AD-Domäne der ehemaligen DCs
9. Heraufstufen der DCs in der Zieldomäme
Vielen Dank für eure Unterstützung
Bei der bevorstehenden Intraforrest-Migration erschließt sich mir aus dem ADMT-Guide von Microsoft die Vorgehensweise für die Security-Translation nicht so ganz. Ich werde die Migration folgendermaßen durchführen:
1. Migration der universellen Gruppen
2. Migration der globalen Gruppen (ADMT wandelt diese automatisch in universelle Gruppen um)
3. Umwandeln der domänenlokalen Gruppen in universelle Gruppen und anschließende Migration dieser Gruppen
4. Migration der Benutzerkonten
5. Nun kommt laut Microsoft der Punkt "Konvertieren lokaler Profile" durch Verwendung der dem "Security Translation Wizard", hier schreibt Microsoft einen für mich nicht zu versehenden Hinweis:
"Normalerweise sind keine Aktionen erforderlich, um eine lokales Profil auf Clients zwischen Domänen in der gleichen Gesamtstruktur zu konvertieren, weil die GUID des Benutzers gleich bleibt. Das lokale Profil kann die SID-zu-GUID-Zuordnung verwenden, die in der Registrierung gespeichert wird, um das Profil des Benutzers erneut zuzuweisen und es dann der neuen Sicherheitskennung (Security Identifier, SID) erneut zuzuordnen.
Wenn Sie das Benutzerkonto in eine Domäne innerhalb der Gesamtstruktur migrieren, der Pfad für das lokale Profil jedoch ein anderer ist, wird das Benutzerprofil geändert, und es wird ein neuer Profilordner auf dem Server mit den richtigen Zugriffssteuerungslisten (Access Control Lists, ALCs) erstellt. Der Administrator muss sicherstellen, dass der Benutzer auf den Profilordner zugreifen kann."
Ich selbst habe eigentlich auch gedacht, dass dieser Vorgang auf Grund der SID-History nicht zwingend erforderlich ist und auch nach abgeschlossener Migration und Abschaltung der Quelldomäne ausgeführt werden kann, damit die SIDs sauber sind und die SID-History ggf. abgeschaltet werden kann. Kann das jemand bestätigen? Wir verwenden im übrigen keine servergespeicherten, sondern ausschließlich lokale Profile.
Ist der "Security Translation Wizard" an dieser Stelle eigentlich auch dazu geeignet die SIDs auf Servern, die schon immer in der Zieldomäne sind und von Benutzern der Quelldomäne bereits verwenden wurden, zu ersetzen?
6. Migrieren von Computerobjekten (Clients und Mitgliedsserver)
Hier kann ich ebenfalls den SID-Verlauf migrieren, welchen Unterschied macht das zum vorangegangenen Punkt? Ist das erforderlich, auch wenn in bereits die lokalen Profile im vorangegangenen Schritt konvertiert habe?
7. Manuelles Herunterstufen der DCs der Quelldomäne
8. Manueller Wechsel der AD-Domäne der ehemaligen DCs
9. Heraufstufen der DCs in der Zieldomäme
Vielen Dank für eure Unterstützung
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 311531
Url: https://administrator.de/contentid/311531
Printed on: April 25, 2024 at 03:04 o'clock
6 Comments
Latest comment
Hi,
Warum nicht einfach alle Benutzer migrieren und dabei die Option setzen, dass auch alle Gruppen migriert werden sollen? Dabei werden alle für die Benutzer relevanten Gruppen automatisch mit migriert. (inkl. verschachtelte Gruppen)
Also Frage: Migrierst Du innerhalb eines Forest oder übergreifend?
Das Roaming Profile für die Anmeldung am PC wird beim Migrieren des Benutzer automatisch gepatcht, wenn man das angibt. Ein Roaming Profile für Anmeldung am RDS nicht!
DNS-Auflösung nicht vergessen.
Abhängikeiten von alten FQDN nicht vergessen. Also stell sicher, dass die Clients auch später noch FQDN aus der alten Zone auflösen können.
1. Migration der universellen Gruppen
2. Migration der globalen Gruppen (ADMT wandelt diese automatisch in universelle Gruppen um)
3. Umwandeln der domänenlokalen Gruppen in universelle Gruppen und anschließende Migration dieser Gruppen
4. Migration der Benutzerkonten
Das mit der automatischen Umwandlung der Gruppentypen stimmt so nicht ganz, bzw. macht so keinen Sinn.2. Migration der globalen Gruppen (ADMT wandelt diese automatisch in universelle Gruppen um)
3. Umwandeln der domänenlokalen Gruppen in universelle Gruppen und anschließende Migration dieser Gruppen
4. Migration der Benutzerkonten
Warum nicht einfach alle Benutzer migrieren und dabei die Option setzen, dass auch alle Gruppen migriert werden sollen? Dabei werden alle für die Benutzer relevanten Gruppen automatisch mit migriert. (inkl. verschachtelte Gruppen)
5. Nun kommt laut Microsoft der Punkt "Konvertieren lokaler Profile" durch Verwendung der dem "Security Translation Wizard", hier schreibt Microsoft einen für mich nicht zu versehenden Hinweis:
"Normalerweise sind keine Aktionen erforderlich, um eine lokales Profil auf Clients zwischen Domänen in der gleichen Gesamtstruktur zu konvertieren, weil die GUID des Benutzers gleich bleibt. Das lokale Profil kann die SID-zu-GUID-Zuordnung verwenden, die in der Registrierung gespeichert wird, um das Profil des Benutzers erneut zuzuweisen und es dann der neuen Sicherheitskennung (Security Identifier, SID) erneut zuzuordnen.
Wenn Sie das Benutzerkonto in eine Domäne innerhalb der Gesamtstruktur migrieren, der Pfad für das lokale Profil jedoch ein anderer ist, wird das Benutzerprofil geändert, und es wird ein neuer Profilordner auf dem Server mit den richtigen Zugriffssteuerungslisten (Access Control Lists, ALCs) erstellt. Der Administrator muss sicherstellen, dass der Benutzer auf den Profilordner zugreifen kann."
Ich selbst habe eigentlich auch gedacht, dass dieser Vorgang auf Grund der SID-History nicht zwingend erforderlich ist und auch nach abgeschlossener Migration und Abschaltung der Quelldomäne ausgeführt werden kann, damit die SIDs sauber sind und die SID-History ggf. abgeschaltet werden kann. Kann das jemand bestätigen? Wir verwenden im übrigen keine servergespeicherten, sondern ausschließlich lokale Profile.
Die sidHistory nützt hinsichtlich der Profile nur hinsichtlich der NTFS-Rechte. Wenn man zwischen Gesamtstrukturen migriert, dann würde das Profil nicht geladen werden, wenn man sich mit dem Konto nach der Migration anmeldet. Hier müssten erst die lokalen Kopien der Profle konvertiert werden."Normalerweise sind keine Aktionen erforderlich, um eine lokales Profil auf Clients zwischen Domänen in der gleichen Gesamtstruktur zu konvertieren, weil die GUID des Benutzers gleich bleibt. Das lokale Profil kann die SID-zu-GUID-Zuordnung verwenden, die in der Registrierung gespeichert wird, um das Profil des Benutzers erneut zuzuweisen und es dann der neuen Sicherheitskennung (Security Identifier, SID) erneut zuzuordnen.
Wenn Sie das Benutzerkonto in eine Domäne innerhalb der Gesamtstruktur migrieren, der Pfad für das lokale Profil jedoch ein anderer ist, wird das Benutzerprofil geändert, und es wird ein neuer Profilordner auf dem Server mit den richtigen Zugriffssteuerungslisten (Access Control Lists, ALCs) erstellt. Der Administrator muss sicherstellen, dass der Benutzer auf den Profilordner zugreifen kann."
Ich selbst habe eigentlich auch gedacht, dass dieser Vorgang auf Grund der SID-History nicht zwingend erforderlich ist und auch nach abgeschlossener Migration und Abschaltung der Quelldomäne ausgeführt werden kann, damit die SIDs sauber sind und die SID-History ggf. abgeschaltet werden kann. Kann das jemand bestätigen? Wir verwenden im übrigen keine servergespeicherten, sondern ausschließlich lokale Profile.
Also Frage: Migrierst Du innerhalb eines Forest oder übergreifend?
Das Roaming Profile für die Anmeldung am PC wird beim Migrieren des Benutzer automatisch gepatcht, wenn man das angibt. Ein Roaming Profile für Anmeldung am RDS nicht!
6. Migrieren von Computerobjekten (Clients und Mitgliedsserver)
Hier kann ich ebenfalls den SID-Verlauf migrieren, welchen Unterschied macht das zum vorangegangenen Punkt? Ist das erforderlich, auch wenn in bereits die lokalen Profile im vorangegangenen Schritt konvertiert habe?
Das bezieht sich meines Wissen auf die sidHistory der Computerobjekte. Das ist meines Wissens nur notwendig, wenn die Computerobjekte direkt über ihr Computerkonto irgendwo Berechtigungen erhalten haben (z.B. NTFS-Rechte in einer Freigabe).Hier kann ich ebenfalls den SID-Verlauf migrieren, welchen Unterschied macht das zum vorangegangenen Punkt? Ist das erforderlich, auch wenn in bereits die lokalen Profile im vorangegangenen Schritt konvertiert habe?
9. Heraufstufen der DCs in der Zieldomäme
Sind diese DC dann an einem anderen Standort als die DC der Zieldomäne?DNS-Auflösung nicht vergessen.
Abhängikeiten von alten FQDN nicht vergessen. Also stell sicher, dass die Clients auch später noch FQDN aus der alten Zone auflösen können.
Zitat von @emeriks:
Das mit der automatischen Umwandlung der Gruppentypen stimmt so nicht ganz, bzw. macht so keinen Sinn.
Warum nicht einfach alle Benutzer migrieren und dabei die Option setzen, dass auch alle Gruppen migriert werden sollen? Dabei werden alle für die Benutzer relevanten Gruppen automatisch mit migriert. (inkl. verschachtelte Gruppen)
Das mit der automatischen Umwandlung der Gruppentypen stimmt so nicht ganz, bzw. macht so keinen Sinn.
Warum nicht einfach alle Benutzer migrieren und dabei die Option setzen, dass auch alle Gruppen migriert werden sollen? Dabei werden alle für die Benutzer relevanten Gruppen automatisch mit migriert. (inkl. verschachtelte Gruppen)
Ich wollte die Gruppen vorab migrieren um die Migration Schritt für Schritt durchzuführen. Wir setzen aktuell ohnehin nur universelle und domänenlokale Gruppen ein, da auf Grund der Entwicklung des Unternehmens ohnehin in fast allen Gruppen Mitglieder aus beiden Domänen sind.
Die sidHistory nützt hinsichtlich der Profile nur hinsichtlich der NTFS-Rechte. Wenn man zwischen Gesamtstrukturen migriert, dann würde das Profil nicht geladen werden, wenn man sich mit dem Konto nach der Migration anmeldet. Hier müssten erst die lokalen Kopien der Profle konvertiert werden.
Also Frage: Migrierst Du innerhalb eines Forest oder übergreifend?
Das Roaming Profile für die Anmeldung am PC wird beim Migrieren des Benutzer automatisch gepatcht, wenn man das angibt. Ein Roaming Profile für Anmeldung am RDS nicht!
Also Frage: Migrierst Du innerhalb eines Forest oder übergreifend?
Das Roaming Profile für die Anmeldung am PC wird beim Migrieren des Benutzer automatisch gepatcht, wenn man das angibt. Ein Roaming Profile für Anmeldung am RDS nicht!
Wir führen eine Intraforrest-Migration, daher sollte ich da nicht auf Probleme stoßen.
9. Heraufstufen der DCs in der Zieldomäme
Sind diese DC dann an einem anderen Standort als die DC der Zieldomäne?DNS-Auflösung nicht vergessen.
Abhängikeiten von alten FQDN nicht vergessen. Also stell sicher, dass die Clients auch später noch FQDN aus der alten Zone auflösen können.
Die DCs der Quelldomäne sind an einem anderen Standort, dort werde ich für die Migrationsphase einen DC der Zieldomäne installieren, so dass in der Migrationsphase gewährleistet ist, dass vor Ort ein DC ist. Abhängigkeiten vom FQDN der alten Zone habe ich geprüft und dort wo es notwendig war aufgelöst, DNS-Auflösung, etc. ist klar.
Während meiner Tests sind mir jedoch noch folgende "Phänomene" entgegengekommen:
- "Senden Als"-Berechtigungen für Exchage-Postfächer sind nach der Migration verschwunden (Exchange 2010)
- ActiveSync-Container am Benutzerobjekt müssen manuell vor der Migration gelöscht werden (Exchange 2010)
- gpresult /R führt nach der Computermigration u.a. zu Zugriff verweigert und es muss ein "winmgmt /resetrepository" ausgeführt werden
Gibt es dazu vielleicht Quellen die diese Vorgehensweisen/Probleme bestätigen?
Vielen Dank!
- "Senden Als"-Berechtigungen für Exchage-Postfächer sind nach der Migration verschwunden (Exchange 2010)
Was heißt "verschwunden"? Tauchen sie in der Liste der Berechtigungen nicht mehr auf oder grifen sie bloß nicht mehr?Sind diese Berechtigungen diekt an Benutzer oder an Gruppen erteilt?
- ActiveSync-Container am Benutzerobjekt müssen manuell vor der Migration gelöscht werden (Exchange 2010)
Ja, leider. Meines Wissen führt da kein Weg dran vorbei.- gpresult /R führt nach der Computermigration u.a. zu Zugriff verweigert und es muss ein "winmgmt /resetrepository" ausgeführt werden
Habe ich so noch nicht beobachtete, nicht bewusst.Ich habe ein Postfach migriert, an dem zwei andere Benutzer (jeweils aus Quell- und Zieldomäne) "Senden als"-Berechtigungen hatte. Nach der Migration waren diese Einträge weg und es waren die Standard-Einträge vorhanden. Ich habe dies auch in anderen Berichten im Internet gelesen, ohne dazu aber etwas offizielles oder eine Lösung zu finden. (z.B. http://www.networksteve.com/exchange/topic.php/ADMT_permissions_issue,_ ...
- ActiveSync-Container am Benutzerobjekt müssen manuell vor der Migration gelöscht werden (Exchange 2010)
Ja, leider. Meines Wissen führt da kein Weg dran vorbei.Können die einfach so gelöscht werden, oder muss ich vorher über die Exchange-Verwaltungskonsole das entsprechende ActiveSync-Gerät entfernen? Muss der Endbenutzer etwas tun, oder wird das Gerät samt Container beim nächsten Sync automatisch wieder angelegt?
Vielen Dank!
Ich habe ein Postfach migriert,
Du meinst sicher, einen Benutzer? Oder verschiebst Du "gleichzeitig" auch die Postfächer auf einen anderen Exchange Server?Können die einfach so gelöscht werden, oder muss ich vorher über die Exchange-Verwaltungskonsole das entsprechende ActiveSync-Gerät entfernen? Muss der Endbenutzer etwas tun, oder wird das Gerät samt Container beim nächsten Sync automatisch wieder angelegt?
Meines Wissen ist das deckungsgleich. Also das, was Du in der Exchange Konsole siehst, ist das, was unter dem Benutzerobjekt hängt.Zitat von @emeriks:
Ich habe ein Postfach migriert,
Du meinst sicher, einen Benutzer? Oder verschiebst Du "gleichzeitig" auch die Postfächer auf einen anderen Exchange Server?Sorry, ja klar ich meinte einen Benutzer. Der Postfach bleibt auf dem gleichen Exchange 2010-Server.
