Probleme nach Migration von w2k3 auf w2k8r2

[MarNa 10]

Hallo,

 

ich habe ein Problem nach der Migration einer W2k3 AD zu W2k8.

User, Gruppen und Computer habe ich mit ADMT erfolgreich migriert, die GPOs habe ich neu angelegt und die Einstellung importiert. Nun zu meinem Problem:

Meldet sich ein User gegen die neue Domäne an, so ziehen die Gruppenrichlinien nicht, bei gpresult kommt immer die Meldung das keine RSOP-Daten vorhanden sind. Entferne ich die Masse an Sicherheitsgruppen von dem Account klappt es allerdings halbwegs. Dieses Problem tritt mit xP Clients und auch mit Win7 auf, bei migrierten Usern und auch bei neuangelegten.

In der alten W2k3 Domäne gab es hierbei keine Probleme.

Ich hoffe hier hat jemand einen hilfreichen Tipp!

 

Gruß

Markus

[lefg 276]

Moin

 

Von einem Blick in die Ereignisanzeige steht kein Wort in der Eröffnung?

 

Ich kann da jetzt nur vermuten, die Vermutung heisst Namensauflösung per DNS. Haben sich die Clients in die Zonen eingetragen?

 

Wurde mal getestet am dc mit dcdiag und netdiag, an einem XP mit netdiag?

[iDiddi 27]

Was heißt denn "Masse an Sicherheitsgruppen"? Um wieviele handelt es sich denn?

 

Zu viele machen Probleme:

 

MSXFAQ.DE - Windows Gruppen und Berechtigungen

[NilsK 2.801]

Moin,

 

besonders nach einer ADMT-Migration kann es zu Anmelde- und Zugriffsproblemen kommen, wenn die migrierten Objekte schon vor der Migration in vielen Gruppen Mitglied waren.

 

Die ADMT-Migration beruht üblicherweise auf der SID History, d.h. die alten SIDs werden mit den Objekten migriert, und zusätzlich erhalten sie in der neuen Domäne neue SIDs. Überträgt man Gruppen mit, so erhalten diese natürlich auch neue SIDs, sodass für jede Gruppenmitgliedschaft nicht mehr eine, sondern zwei SIDs im Access Token eines Users stehen, der sich anmeldet. Das führt dann schnell zum "Token Bloat", d.h. das Token ist zu groß und enthält nicht mehr alle Gruppenmitgliedschaften.

 

Schon im Normalfall kann ein Objekt nur in ca. 1015 Gruppen gleichzeitig Mitglied sein. Durch das Dual-SID-Prinzip verringert sich das je nach Zusammensetzung der Gruppenstruktur auf etwa 500 Gruppen.

 

Abhilfe: Bereinigung der Gruppen. Dafür ist es notwendig, in den Berechtigungslisten der Ressourcen die Berechtigungen, die auf die "alten" Gruppen lauten, durch solche für die (identischen) "neuen" Gruppen zu ersetzen. Das kann aufwändig sein. Je nachdem, wie die Migration insgesamt abgelaufen ist, gibt es aber vielleicht bereits "Dual-ACL" in den Listen - ADMT umfasst für die Migration etwa von Dateiservern die Option, die ACLs in den Berechtigungslisten um Einträge für die migrierten Gruppen zu ergänzen (es stehen also sowohl die alte als auch die neue Gruppe drin). In so einem Fall braucht man SID History dann eigentlich nicht für den Zugriff.

 

Nach dem Anpassen der ACLs kann man dann die SID History von den Gruppen (und ggf. auch den Usern) entfernen, dafür gibt es Beispielskripte bei Microsoft.

 

Eine weitergehende (und bessere) Option ist, die Gruppen- und Berechftigungsstruktur neu aufzubauen und die Altobjekte und Alteinträge zu entfernen, aber das erzeugt üblicherweise Aufwand, der eher in Wochen zu rechnen ist.

 

Gruß, Nils

[MarNa 10]

Hallo und vielen Dank schon mal für die schnellen Antworten.

 

DNS würde ich als Fehlerursache ausschließen, die Clients tragen sich richtig in der Zone ein und die Netzwerkkartenkonfig ist auch korrekt.

 

In der Ereignisanzeige auf dem Client gibt es einen Fehler:

Quelle: Userenv

Ereigniskennung: 1053

 

Der Benutzer oder Computername kann nicht ermittelt werden. (Für diesen Vorgang ist bicht genügend Speicher verfügbar. ) Die VVerarbeitung der Gruppenrichtlinie wurde abgebrochen.

 

Eine Neuregistrierung der DLL hatte ich auf einem anderen Testclient bereits mal versucht, auch ohne Erfolg.

 

Was die Masse an Sicherheitsgruppen angeht, so handelt es sich um ca. 300 (bei diesem Testuser).

 

 

Beim netdiag bekomme ich 2 Fehler:

DC list test :Failed

[WARNING] Cannot call DsBind to DC01.dom.local <IP>.[ERROR_OUTOFMEMORY]

 

LDAP test :Passed

[WARNING] Failed to query SPN registration on DC 'DC01.dom.local'.

 

Der dcdiag sieht gut aus.

 

Gruß

Markus

[NilsK 2.801]

Moin,

 

für mich sieht das nach "Token Bloat" aus. 300 Gruppenmitgliedschaften verdoppelt macht schon 600 - und zusätzlich zur Maximalgröße des Tokens selbst kann es noch Einschränkungen bei der Übermittlung des Tokens geben (Details dazu habe ich gerade nicht mehr im Kopf, sind aber recherchierbar). Letztere könnte man übergangsweise beheben.

 

Um das Problem tatsächlich zu lösen, kommst du um die Bereinigung der SID History nicht herum.

 

Gruß, Nils

[MarNa 10]

Hallo Nils,

 

nach deinem ersten Post, habe ich diesen Ansatz auch schon vertieft und mir den Ablauf der endgültigen Umstellung neu überlegt. Der Aufwand steigt zwar erheblich, aber ich komme wohl nicht drum rum.

Die Frage ist nur, ob es wirklich die Lösung ist!?

 

Ein weiterer Test vorhin hat mich allerdings etwas verwirrt. Ich habe einen User an einem PC in der alten Domäne angemeldet, dann User und PC migriert und danach hatte der User keine Probleme mit den Policys (an diesem PC, an einem anderen PC bestand das Problem weiterhin).

Nun muss ich mir noch überlegen, wie wir unser NAS migriert bekommen.

 

Gruß

Markus