15
ADMT - Migration Benutzer + Gruppen
Moin,
Szenario:
Alte Domäne = olddomain.local mit einem DC1 (Domaincontroller) - Windows 2016
Neue Domäne = newdomain.local mit einem DC2 (Domaincontroller) - Windows 2022
Benutzer und Gruppen mit Shares in der alten Domäne vorhanden.
- Domänenvertrauensstellung hergestellt und nochmal überprüft -> alles i. O.
- Auf dem DC1 habe ich ADMT + PES installiert
- Benutzer und Gruppen via ADMT migriert (Erfolgreich)
- SID's passen soweit, sprich SID History
- Mit Benutzerdaten an der neuen Domäne angemeldet
Ich bekomme einfach keinen Zugriff auf die Shares in der alten Domäne mit den migrierten Benutzer aus der alten Domäne. Ich weiss hier einfach nicht mehr weiter. Jemand einen Tipp für mich? Ich weiss einfach nicht wo der Wurm ist.
Erforderliche Befehle soweit ausgeführt:
Netdom trust newdomain.local /D:olddomain.local /quarantine:No /userD:newdomain.local\administrator /passwordD:*
netdom trust olddomain.local /D:newdomain.local /enablesidhistory:yes /userD: olddomain.local\administrator /passwordD:*
Szenario:
Alte Domäne = olddomain.local mit einem DC1 (Domaincontroller) - Windows 2016
Neue Domäne = newdomain.local mit einem DC2 (Domaincontroller) - Windows 2022
Benutzer und Gruppen mit Shares in der alten Domäne vorhanden.
- Domänenvertrauensstellung hergestellt und nochmal überprüft -> alles i. O.
- Auf dem DC1 habe ich ADMT + PES installiert
- Benutzer und Gruppen via ADMT migriert (Erfolgreich)
- SID's passen soweit, sprich SID History
- Mit Benutzerdaten an der neuen Domäne angemeldet
Ich bekomme einfach keinen Zugriff auf die Shares in der alten Domäne mit den migrierten Benutzer aus der alten Domäne. Ich weiss hier einfach nicht mehr weiter. Jemand einen Tipp für mich? Ich weiss einfach nicht wo der Wurm ist.
Erforderliche Befehle soweit ausgeführt:
Netdom trust newdomain.local /D:olddomain.local /quarantine:No /userD:newdomain.local\administrator /passwordD:*
netdom trust olddomain.local /D:newdomain.local /enablesidhistory:yes /userD: olddomain.local\administrator /passwordD:*
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 668518
Url: https://administrator.de/contentid/668518
Ausgedruckt am: 25.11.2024 um 08:11 Uhr
15 Kommentare
Neuester Kommentar
Hi,
rein netzwerktechnisch funktioniert aber alles?
Der Client kann den Server mit der Freigabe tatsächlich erreichen?
Server mit Freigabe hat welche Windows Version?
Angemeldet an Client welcher Domäne?
DFS im Spiel?
Der Trust ist bi- oder unidirektional?
Test
E.
rein netzwerktechnisch funktioniert aber alles?
Der Client kann den Server mit der Freigabe tatsächlich erreichen?
Server mit Freigabe hat welche Windows Version?
Angemeldet an Client welcher Domäne?
DFS im Spiel?
Der Trust ist bi- oder unidirektional?
Test
- Client aus neuer Domäne
- mit Benutzer aus neuer Domäne anmelden
- Verbinden zur Freigabe auf Server in alter Domäne mit Anmeldedaten aus der alten Domäne herstellen (z.B. mit net use ...)
- Mit Explorer die NTFS-Rechte eines Ordner aus dieser Freigabe anzeigen lassen
- Die ACL sollte die migrierten Gruppen aus der neuen Domäne anzeigen, sofern diese Gruppen tatsächlich inkl. sidHistory in der neuen Domäne vorhanden sind.
E.
Alte Domäne = olddomain.local mit einem DC1 (Domaincontroller) - Windows 2016
Hier liegt der Denkfehler:Neue Domäne = newdomain.local mit einem DC2 (Domaincontroller) - Windows 2022
Es sollte mittlerweile jedem klar sein, das .local nicht mehr genutzt werden sollte
Gruss Penny.
Zitat von @Penny.Cilin:
Es sollte mittlerweile jedem klar sein, das .local nicht mehr genutzt werden sollte
Das hat aber jetzt nichts mit der Problemstellung zu tun.Es sollte mittlerweile jedem klar sein, das .local nicht mehr genutzt werden sollte
Zitat von @emeriks:
Zitat von @Penny.Cilin:
Es sollte mittlerweile jedem klar sein, das .local nicht mehr genutzt werden sollte
Das hat aber jetzt nichts mit der Problemstellung zu tun.Es sollte mittlerweile jedem klar sein, das .local nicht mehr genutzt werden sollte
Indirekt schon. Es sei denn, es sind Platzhalter. Hatte gestern erst eine Diskussion bzgl. .local Domainverwendung. Musste die Person aufklären bzgl. MDNS.
Gruss Penny.
@Penny.Cilin
Inwiefern soll denn die Tatsache der Verwendung der TLD "local" in einem Umfeld, in welchem sie bereits erfolgreich verwendet wird, den Zugriff auf über Domänenvertrauensstellung angebundene Ressourcen bei Verwendung der sidHistory beeinflussen?
Wir haben keinerlei Aussage, welche Art von Clients zum Einsatz kommen. Ich für mich gehe deshalb von Windows Clients aus, weil TO von Windows Server schreibt.
Inwiefern soll denn die Tatsache der Verwendung der TLD "local" in einem Umfeld, in welchem sie bereits erfolgreich verwendet wird, den Zugriff auf über Domänenvertrauensstellung angebundene Ressourcen bei Verwendung der sidHistory beeinflussen?
Wir haben keinerlei Aussage, welche Art von Clients zum Einsatz kommen. Ich für mich gehe deshalb von Windows Clients aus, weil TO von Windows Server schreibt.
@emeriks
- Netzwerk i. O.
- Client war erstmal an der alten Domänen registriert. Nach der Migration des Users habe ich den Client in die neue Domäne aufgenommen und mich mit dem migrierten Benutzer angemeldet. Ist ein Windows 10 Client
- Server mit Freigabe ist ein Windows 2016 Server
- Kein DFS
- Bidirektional
Werde die Tests mal machen.
- Netzwerk i. O.
- Client war erstmal an der alten Domänen registriert. Nach der Migration des Users habe ich den Client in die neue Domäne aufgenommen und mich mit dem migrierten Benutzer angemeldet. Ist ein Windows 10 Client
- Server mit Freigabe ist ein Windows 2016 Server
- Kein DFS
- Bidirektional
Werde die Tests mal machen.
Tests:
- Direkter Net use mit Benutzer in der neuen Domain wird sofort ausgeführt, aber kein Zugriff - Siehe Bild - netuse1
- Net use mit Benutzer alte Domain wird sofort durchgeführt und hat sofort zugriff - Siehe Bild - netuse2
- Direkter Net use mit Benutzer in der neuen Domain wird sofort ausgeführt, aber kein Zugriff - Siehe Bild - netuse1
- Net use mit Benutzer alte Domain wird sofort durchgeführt und hat sofort zugriff - Siehe Bild - netuse2
Bezogen auf Netuse2, sprich Anmeldung mit olddomain\testuser1 bekomme ich folgende ACL Zugriffe auf den Unterordner "Alle" angezeigt - Siehe Bild - eigentlich korrekt
Hab auch mal zum Test die migrierte Gruppe "alle" in die Gruppe "alle" in der alten Domänen als Mitglied hinzugefügt. (Siehe Bild) Dann funktioniert der Zugriff natürlich reibungslos auf das Share, aber das ist ja nicht Sinn der Sache...
Und die migrierte Gruppe "Alle" hat tatsächlich eine sidHistory?
Jep. SIDHistory ist gesetzt und ist die ObjectSID von der Gruppe Alle in der alten Domäne. Hier ist irgendwo der Wurm, aber ich finde ihn nicht und ich google mich schon langsam tot....
Das Einzige, was mir jetzt noch einfällt, ist, dass Du doch nicht die SID-Filterung deaktiviert hast.
Ist das ein Domain- oder ein Forest-Trust?
Deine beiden genannten netdom-Kommandos benutzen ja Schalter für beide Verfahren.
Meines Wissens gilt für
Domain Trust
Netdom trust SOURCE /domain:TARGET /quarantine:No
Forest-Trust
Netdom trust SOURCE /domain:TARGET /enablesidhistory:yes
Beachte Unterschied yes/no
Deine beiden genannten netdom-Kommandos benutzen ja Schalter für beide Verfahren.
Meines Wissens gilt für
Domain Trust
Netdom trust SOURCE /domain:TARGET /quarantine:No
Forest-Trust
Netdom trust SOURCE /domain:TARGET /enablesidhistory:yes
Beachte Unterschied yes/no
Habe ich schon alles durchprobiert. Kein Erfolg.
Du wirst es nicht glauben. Habe es herausgefunden......
beim Befehlt "netdom trust...." ist es wichtig, wenn deutsches OS, dass am ende bei /Enablesidhistory:ja steht!!!!!!! Also "JA", nicht "YES"
Nun funktioniert es.
beim Befehlt "netdom trust...." ist es wichtig, wenn deutsches OS, dass am ende bei /Enablesidhistory:ja steht!!!!!!! Also "JA", nicht "YES"
Nun funktioniert es.
