rookie
Goto Top

ObjectSID bei Miration kopieren?

Hallo,

ich habe gesehen, dass man mit den Quest Tools bei einer AD Migration die SID eines Benutzers auf das neue Benutzerkonto übertragen kann. Das würde ja bedeuten, dass ich zum einen keine SIDHistory mehr benötige und zum anderen, dass ich absolut keine ACEs (lokales Profil, Fileserver, Drucker usw) mehr auf die neue SID des Benutzers umschreiben muss.
Kann das wirklich sein? Dann wundert es mich, warum das ADMT das nicht kann.

Hat jemand Erfahrung?

Content-Key: 243059

Url: https://administrator.de/contentid/243059

Ausgedruckt am: 28.03.2024 um 20:03 Uhr

Mitglied: emeriks
emeriks 09.07.2014 um 10:14:27 Uhr
Goto Top
Hi
Zitat von @rookie:

Hallo,

ich habe gesehen, dass man mit den Quest Tools bei einer AD Migration die SID eines Benutzers auf das neue Benutzerkonto
übertragen kann.
Wo?

Das würde ja bedeuten, dass ich zum einen keine SIDHistory mehr benötige und zum anderen, dass ich
Ich vermute, die meinen da auch DIE sidHistory.

absolut keine ACEs (lokales Profil, Fileserver, Drucker usw) mehr auf die neue SID des Benutzers umschreiben muss.
Musst Du nicht, wenn Du die SID mit migriert hast.

E.
Mitglied: rookie
rookie 09.07.2014 aktualisiert um 20:51:56 Uhr
Goto Top
Hallo,

gesehen habe ich das im Handbuch und auf einem Screenshot. Es gibt bei der Behandlung der SID die Option "Replace" und dort steht auch, dass damit die SID des Zielobjekts gegen die ursprüngliche SID getauscht wird. Für de SIDHistory gibt es aber noch mal einen extra Haken.

Während der Koexistenz kann ich mit der SIDHistory arbeiten, ja. Aber beim Cleanup wird die History ja gelöscht, daher muss ich die SIDs in den ACEs umschreiben. Es wäre doch nicht sehr "sauber" wenn ich dauerhaft mit der History arbeite!?
Mitglied: emeriks
emeriks 09.07.2014 aktualisiert um 22:13:43 Uhr
Goto Top
Hi,
dort steht auch, dass damit die SID des Zielobjekts gegen die ursprüngliche SID getauscht wird. Für de SIDHistory gibt
Sorry, aber das ist Quatsch! Die SID eines Principals besteht zum Teil aus der SID der Domäne. Ein Principal kann keine objectSID haben, die nicht zur Domäne passt. Wenn Du ein Principal also von einer Domäne in eine andere migrierst, dann muss sich die objectSID des Principals ändern. Bei Inter-Forest-Migrationen wird gar ein neues Objekt angelegt, dessen SID bei Anlage neu kreiert wird. Bei Intra-Forest-Migration wird das Objekt verschoben und anschließend eine neue SID berechnet.

Während der Koexistenz kann ich mit der SIDHistory arbeiten, ja.
Auch später, wenn die alte Domäne nicht mehr da sein sollte, funktioniert die sidHistory noch, solange diese SID noch irgendwo im NTFS, Registry, AD oder sonstwo eingetragen ist. Der Benutzer bekommt beim Anfordern seines Sicherheit-Tokens seine SID, ggf. seine sidHistory, die SID's aller Gruppen, in denen er direkt oder indirekt Mitglied ist (je nach Ressource, wo authentifiziert werden muss) sowie ggf. die sidHistories dieser Gruppen. Damit kann er dann bei der Ressource hausieren gehen.

Aber beim Cleanup wird die History ja gelöscht, daher
muss ich die SIDs in den ACEs umschreiben. Es wäre doch nicht sehr "sauber" wenn ich dauerhaft mit der History
arbeite!?
Du musst nicht "säubern". Man sollte aber, um den Zugriff zu beschleunigen. Außerdem kann die sidHistory von Gruppen zu einem Problem werden, wenn der Benutzer in vielen Gruppen Mitglied ist und die Anzahl der SID's insgesamt zu groß für das Token wird. (meines Wissen max. 1015 Gruppen-SID)
Bevor Du jedoch die sidHistory entfernst musst Du sicherstellen, dass alle Ressourcen diese nicht mehr in Ihren ACL verwenden.

E.
Mitglied: rookie
rookie 09.07.2014 um 22:19:14 Uhr
Goto Top
Hallo,

Die SID eines Principals besteht zum Teil aus der SID der Domäne. Ein Principal kann keine
objectSID haben, die nicht zur Domäne passt.
Das hatte ich auch so im Hinterkopf. Das SID Filtering bezieht sich doch nur auf das SIDHistory Attribut, richtig? Dann frage ich mich allerdings immer noch, wozu es diese Option eigentlich gibt.

Hier mal kurz aus dem Handbuch:

Replace—All entries of the target object’s security descriptor will be deleted. The entries of the source object’ security descriptor will be copied to the target object’s security descriptor.
Habe ich da was falsch verstanden?

Bevor Du jedoch die sidHistory entfernst musst Du sicherstellen, dass alle Ressourcen diese nicht mehr in Ihren
ACL verwenden.
Ohja. Auf den Moment freue ich mich ja schon ;)
Mitglied: emeriks
emeriks 10.07.2014 um 08:36:18 Uhr
Goto Top
Zitat von @rookie:

Das hatte ich auch so im Hinterkopf. Das SID Filtering bezieht sich doch nur auf das SIDHistory Attribut, richtig? Dann frage ich
mich allerdings immer noch, wozu es diese Option eigentlich gibt.
Hierbei geht es um Vertrauensstellungen zu externen Domänen! Damit kannst Du festlegen, ob ein Principal aus einer vetrauten Domäne nur mit den "echten" objectSID's (seiner + Gruppen) oder auch mit den ggf. vorhandenen sidHistories auf Ressorcen der vetrauenden Domäne zugreifen kann. Beim Zugriff auf Ressourcen, welche zum "neuen" Forest gehören (also dort, wohin das Objekt migriert wurde), kommt die sidHistory-Filterung gar nicht zum Tragen.

> Replace—All entries of the target object’s security descriptor will be deleted. The entries of the source
> object’ security descriptor will be copied to the target object’s security descriptor.
Habe ich da was falsch verstanden?
Ja. Hier geht es um die Zugriffsberechtigungen auf das AD-Objekt und nicht um die Berechtigungen, die das Objekt irgendwo anders hat.
http://technet.microsoft.com/en-us/library/cc781716(v=ws.10).aspx
All objects in Active Directory, and all securable objects on a local computer or on the network, have security descriptors to help control access to the objects. Security descriptors include information about who owns an object, who can access it and in what way, and what types of access are audited. Security descriptors, in turn, contain the access control list (ACL) of an object, which includes all of the security permissions that apply to that object.


> Bevor Du jedoch die sidHistory entfernst musst Du sicherstellen, dass alle Ressourcen diese nicht mehr in
> Ihren ACL verwenden.
Ohja. Auf den Moment freue ich mich ja schon ;)
Wie gesagt, Du musst die History nicht entfernen. Wenn Du bloss ne kleine Domäne hast, und die Benutzer nur in ein paar Gruppen Mitglied sind, dann macht sich das nicht negativ bemerkbar. Wir hatte bei uns aber schon Fälle, da waren Benutzer schon vor der Migration in >750 Gruppen Mitglied (direkt oder verschachtelt). Nach der Migration der ganzen Domäne in eine andere (mit Erhalten der alten SIDs) hätte der Benutzer also >1500 Gruppen-SID in seinem Token haben müssen, was nicht geht. Also hat der Zugriff auf einige Ressourcen nicht funktioniert. Hier mussten wir bereinigen.

E.