cordial
Goto Top

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:*

Content-ID: 668518

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

Printed on: October 15, 2024 at 07:10 o'clock

emeriks
emeriks Oct 01, 2024 updated at 13:43:18 (UTC)
Goto Top
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
  • 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.
Penny.Cilin
Penny.Cilin Oct 01, 2024 updated at 14:26:24 (UTC)
Goto Top
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.
emeriks
emeriks Oct 01, 2024 at 15:51:24 (UTC)
Goto Top
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.
Penny.Cilin
Penny.Cilin Oct 01, 2024 at 17:27:27 (UTC)
Goto Top
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.

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.
emeriks
emeriks Oct 02, 2024 updated at 06:36:35 (UTC)
Goto Top
@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.
cordial
cordial Oct 02, 2024 at 07:49:25 (UTC)
Goto Top
@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.
cordial
cordial Oct 02, 2024 at 08:57:40 (UTC)
Goto Top
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
netuse2
netuse1
cordial
cordial Oct 02, 2024 at 09:16:44 (UTC)
Goto Top
Bezogen auf Netuse2, sprich Anmeldung mit olddomain\testuser1 bekomme ich folgende ACL Zugriffe auf den Unterordner "Alle" angezeigt - Siehe Bild - eigentlich korrekt
icacls
cordial
cordial Oct 02, 2024 updated at 12:09:07 (UTC)
Goto Top
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...
alle
emeriks
emeriks Oct 02, 2024 at 13:02:26 (UTC)
Goto Top
Und die migrierte Gruppe "Alle" hat tatsächlich eine sidHistory?
cordial
cordial Oct 02, 2024 at 13:17:18 (UTC)
Goto Top
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....
emeriks
emeriks Oct 02, 2024 at 13:50:19 (UTC)
Goto Top
Das Einzige, was mir jetzt noch einfällt, ist, dass Du doch nicht die SID-Filterung deaktiviert hast.
emeriks
emeriks Oct 02, 2024 at 13:55:04 (UTC)
Goto Top
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
cordial
cordial Oct 02, 2024 at 14:07:13 (UTC)
Goto Top
Habe ich schon alles durchprobiert. Kein Erfolg.
cordial
Solution cordial Oct 04, 2024 at 06:48:34 (UTC)
Goto Top
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.