Merge von speparaten Domains zu einer trusted Domain - SID History question

[gessi 12]

Hallo,

 

ich versuch das Prinzip zu verstehen wenn man aus mehreren separaten Domains eine trusted Domain machen will was mit den SID's der User und den Useraccounts passiert?

 

Existiert nach dem Merge nur noch ein Useraccount mit einer SID History der SID's aus den älteren Domains?

In welcher Domain muss sich der User dann anmelden? Kann man das beim Merge festlegen?

Werden die Accounts gelöscht die nicht mehr genutzt werden?

 

Es geht um eine NAS Implementierung wo virtuelle NAS Server in mehrere Domains gejoint wurden und nun sichergestellt werden muss dass die User auch die Daten nach dem Merge zugreifen können.

 

Vielleicht kann mir jemand ein paar Hinweise/Tipps geben!?

[Daim 12]

Aloha,

 

ich versuch das Prinzip zu verstehen wenn man aus mehreren separaten Domains eine trusted Domain machen will was mit den SID's der User und den Useraccounts passiert?

 

es kommt darauf an wie du migrierst. Wenn man mit der SIDHistory migriert, wandert die "alte" SID mit.

 

Welche Migrationsszenarien es gibt, erfährst du hier:

 

LDAP://Yusufs.Directory.Blog/ - Eine Domänenmigration durchführen

 

Existiert nach dem Merge nur noch ein Useraccount mit einer SID History der SID's aus den älteren Domains?

 

Genau. In der neuen Domäne wird ein neues Benutzerobjekt mit logischerweise einer neuen SID erstellt und die SIDs aus der alten Domäne werden in das Attribut SIDHistory im neuen Benutezrobjekt geschrieben.

 

In welcher Domain muss sich der User dann anmelden? Kann man das beim Merge festlegen?

 

Das kommt darauf an, wie und mit welchem Werkzeug du migrierst. Führst du z.B. eine INTRA-Migration mit ADMT durch, muss sich der Benutzer zwingend in der neuen Domäne anmelden. Mit ADMT wird das Benutzerobjekt nach der Migration aus der Quelldomäne entfernt, aber nur bei einer Intra-Migration.

 

Werden die Accounts gelöscht die nicht mehr genutzt werden?

 

Das kommt auf das Werkzeug und dein Migrationsszenario (Intra- oder Inter-Migration?) an. Lies dir den o.g. Link durch.

[gessi 12]

Danke!

 

Das hilft mir schon Mal sehr weiter...

 

Nun habe ich noch das Problem dass mein NAS server auch migriert werden soll. Nun frage ich mich wie die SID's aus der alten Domain zu einem NAS Server in der neuen Domain migriert werden.

 

Am besten wäre es natürlich die alte SID auf die neue SID zu transferieren. Aber ich weis nicht ob das Robocopy macht (Option)

Ich weis auch nicht wie sich der NAS server verhält wenn man Security Descirptoren mit unbekannten SID's (in der neuen Domäne, falls die User noch nicht migriert wurden) migriert werden können.

 

Hier scheint es besser zu sein erst die User+SID history und dann die Daten zu migrieren richtig? Weil dann gibt es ja die alte SID in meiner neuen Domäne und Robocopy kann die SID's ohne Weiteres migireren?

 

@Daim: Ich sehe in Deinem Bericht Du schreibst etwas über anpassen der ACL's. Mit welchem tools kann man die alte auf die neue SID ummünzen? Funktioniert das auch mit ADMT

[NilsK 2.930]

Moin,

 

ein NAS (von was für einem sprechen wir denn?) sollte sich an der Stelle genauso verhalten wie ein Windows-Server: Es interessiert überhaupt nicht, wo der SID herkommt. Es interessiert nur, ob er in der Berechtigungsliste auftaucht.

 

Sprich: Wenn du mit SID History migrierst, brauchst du keine bestehenden Berechtigungen anzupassen. Im Access Token des Users steht sowohl der alte als auch der neue SID. Daher erkennt der angefragte Server den User als den "alten" User: Der alte SID steht ja in der Berechtigungsliste.

 

Ein Zugriff sieht in Windows prinzipiell so aus:

• User verbindet sich mit dem Server und verlangt einen bestimmten Zugriff auf eine Ressource.
  
• Der Server prüft das Access Token des Users, welche SIDs darin stehen. (Wo diese herkommen, ist ihm egal.)
  
• Der Server prüft, ob die ACL (Access Control List, Berechtigungsliste) der angefragten Ressource den Zugriff für die Kombination der SIDs im Access Token erlaubt.
  
• Wenn genau der Zugriff möglich ist, den der User anfordert (z.B. Lesen und Schreiben), lässt der Server den Zugriff zu. Sonst nicht.
  
• Der Server gibt keinen Teilzugriff (z.B. nur Lesen, wenn der User eigentlich lesen und schreiben wollte) - entweder genau der angeforderte Zugriff oder gar keiner.
  
• Und: Der Server, der die Ressource hostet, fragt nicht beim Domänencontroller nach. (Das ist ein häufiger Irrtum.) Sofern der User ein gültiges Access Token vorweisen kann, reicht das aus. Genau wie die Polizei den Personalausweis kontrolliert und nicht nach der Geburtsurkunde fragt und diese beim Entbindungskrankenhaus prüft.
  

 

Gruß, Nils

[Daim 12]

Aber ich weis nicht ob das Robocopy macht (Option)

 

Die Umsetzung, also den Zugriff weiterhin auch nach der Migration für die Benutzer aufrecht halten, erfolgt von dem eingesetzten Migrationswerkzeug. Wenn du kein Geld ausgeben möchtest, verwendest du ADMT.

 

Ich weis auch nicht wie sich der NAS server verhält wenn man Security Descirptoren mit unbekannten SID's (in der neuen Domäne, falls die User noch nicht migriert wurden) migriert werden können.

 

Auch auf dem NAS gibt es eine ACL auf den Freigaben, daher ist das egal ob es sich dabei und ein NAS oder Windows Server handelt.

 

Hier scheint es besser zu sein erst die User+SID history und dann die Daten zu migrieren richtig? Weil dann gibt es ja die alte SID in meiner neuen Domäne und Robocopy kann die SID's ohne Weiteres migireren?

 

Man migriert im ersten Schritt zuerst die Benutzer und Gruppen und im zweiten die Computer (und dein NAS). Im zweiten Schritt werden die lokalen Ressourcen "übersetzt". Bei Computern kannst du Clients und Mitgliedsserver mit ADMT migrieren, aber keine DCs. DCs müssen aus der alten Domäne herunter- und in der neuen Domäne heraufgestuft werden. Und trenne dich von ROBOCOPY, du suchst wenn es kostenlos sein soll ADMT.

 

@Daim: Ich sehe in Deinem Bericht Du schreibst etwas über anpassen der ACL's. Mit welchem tools kann man die alte auf die neue SID ummünzen? Funktioniert das auch mit ADMT

 

Entweder skriptbasiert oder z.B. mit SUBINACL und nein, die ACLs der Ressourcen bzw. SIDHistory "bereinigen/glatt ziehen" kann ADMT nicht.

[gessi 12]

@All

 

Vielen Dank für die schnelle und kompetente Hilfe...

 

Trotzdem brauch ich Robocopy weil die gesamten Daten von einem alten auf ein neues NAS migriert werden sollen gleichzeitig. Und das neue NAS bekommt dann logischerweise einen Account in der neuen Domäne.

[Daim 12]

Trotzdem brauch ich Robocopy weil die gesamten Daten von einem alten auf ein neues NAS migriert werden sollen gleichzeitig. Und das neue NAS bekommt dann logischerweise einen Account in der neuen Domäne.

 

Du könntest ja das neue NAS in die alte Domäne ausnehmen, die Daten rüber kopieren (ROBOCOPY, xcopy... etc.) und dann mit ADMT das neue NAS migrieren. ;)

[NilsK 2.930]

Moin,

 

und dann mit ADMT das neue NAS migrieren. ;)

 

das musst du mir zeigen, wie du ein NAS mit ADMT migrierst ... :D

 

Gruß, Nils

[NorbertFe 2.027]

das musst du mir zeigen, wie du ein NAS mit ADMT migrierst ... :D

 

Vielleicht wenn du Windows Storage Server dazuzählst. ;)

 

Bye

Norbert

[gessi 12]

Sorry aber jetzt stehe ich ein bisschen auf der Leitung!?

 

Die Daten bekomme ich mit Robocopy rüber aber ADMT funktioniert nicht mit NAS Systemen sondern nur mit nativen Windows Servern?

 

Wie muss ich das jetzt verstehen?

[Daim 12]

das musst du mir zeigen, wie du ein NAS mit ADMT migrierst ... :D

 

Hehee... zum Glück ist heute Freitag. Da waren die Finger schneller als der Gedanke. ;)

[Daim 12]

Die Daten bekomme ich mit Robocopy rüber aber ADMT funktioniert nicht mit NAS Systemen sondern nur mit nativen Windows Servern?

 

Genau. Bei einem klassischen NAS-System gibt es ja kein Computerkonto im AD. Das kann auch nicht mit ADMT migriert werden. Es muss schon ein "echtes" Windows Betriebssystem sein (und im AD existieren) und kein proprietäres (oder gar Linux) System, damit ein Computer mit ADMT migriert werden kann.

[NilsK 2.930]

Moin,

 

... vielleicht könnte sich der TO ja endlich mal bequemen uns mitzuteilen, von was für einem NAS er eigentlich spricht. Da ist die Bandbreite dann ja doch recht groß - so von No-Name über Buffalo über OpenFiler bis NetApp.

 

Gruß, Nils