Zugriff verweigert trotz korrekter Gruppenmitgliedschaft

[Christoph35 10]

Hallo zusammen!

 

So, nachdem MS sich immer noch Zeit lässt, eine Lösung zu präsentieren, habe ich das ganze jetzt selbst mal nachgebaut, so wie wir es in der Prod.Domain gemacht haben.

 

3 NT Domains, davon 2 auf 2003 AD upgegraded mit temp. DCs, die ich auf 2003 aktualisiert habe.

Die 3. Domain werde ich auch bald upgraden.

 

In dieser Testumgebung habe ich das gleiche Problem :schreck:

 

Zugriff eines Users aus B über universelle Gruppen in A auf eine Ressource in A: access denied.

Zugriff eines Users aus B über domain local Gruppen in A auf eine Ressource in A: access granted.

Zugriff eines Users aus A über eine universelle Gruppe in B auf eine Ressource in B: access granted

Zugriff eines Users aus A über DL Gruppen in B auf eine Ressource in B: access granted

 

Scheint tatsächlich irgendwie an der Migration zu liegen....

 

Ich werde mal in meiner Test Domain weiter probieren, und entsprechend weiter berichten.

 

Christoph

[Christoph35 10]

Hallo zusammen,

 

wir haben (endlich) herausgefunden, warum es bei universellen Gruppen zu diesen Problemen gekommen ist. Eine Nachfrage von MS zu den Attributen der Vertrauensstellungen hat uns auf die richtige Fährte gesetzt.

 

Der Trust von unserer Forest Root Domain a.firma.com zu den anderen Domains (b.firma.com und c.firma.com) hatte das Attribut "Quarantine" gesetzt (nie von uns manuell gemacht), so dass SID-Filtering für die Forest Root Domain aktiv war. Bei den Trust in die andere Richtung (also B.firma.com->a.firma.com und c.firma.com->a.firma.com) war dieses Attribut nicht gesetzt, also war in dieser Richtung der Zugriff über universelle Gruppen möglich.

 

Geholfen hat der Befehl

 

netdom trust a.firma.com /domain:b.firma.com /quarantine:no /usero:<domain-admin> /passwordo:* und
netdom trust a.firma.com /domain:c.firma.com /quarantine:no /usero:<domain-admin> /passwordo:*

 

für jede Domain, in deren Richtung Filtering aktiv ist.

 

Ich habe das zunächst mal in meiner virtuellen Umgebung getestet und nach Erfolg haben wir das heute morgen auch in der produktiven Domain umgesetzt. Auch hier ist jettz natürlich der Zugriff möglich.

 

Mein Kollege (MS-Wing) hat mal eine Minimal-Umgebung mit 2 NT PDCs in Place auf 2 AD 2K3 Domains in einem Forest upgegraded, dort ist das Problem nicht aufgetreten! Das Quarantine Attribut war in seiner Root-Domain nicht gesetzt. Vermutung liegt nahe, dass dieses Problem nur in Forests auftritt, die aus mehr als 2 upgegradeten NT4 Domains bestehen, wenn alle NT Domains untereinander einen Trust eingerichtet hatten.

 

Mehr Info zu diesem Themenkomplex gibts unter folgenden Links:

 

http://support.microsoft.com/?id=289246

http://support.microsoft.com/?id=289243

http://technet2.microsoft.com/WindowsServer/en/Library/1f33e9a1-c3c5-431c-a5cc-c3c2bd579ff11033.mspx

http://www.windowsitpro.com/Windows/Article/ArticleID/44077/44077.html

 

Wir warten noch auf einen Rückruf von MS und wollen den Support-Techniker dazu mal etwas eingehender befragen.

 

Aber vielleicht kann auch von euch noch jemand was dazu sagen?

 

Christoph

[Christoph35 10]

Noch als Ergänzung:

 

mit

 

netdom trust trusting_domain_name /Domain:trusted_domain_name /Quarantine

 

kann man den Status der Quarantäne abfragen.

 

Man kann auch über ADSIEdit.msc den Status anschauen, muss aber wissen, wie ein bestimmter Wert zu interpretieren ist.

 

Schaut nach im Domain-Kontext, dann CN=system. Dann sehe man sich die Eigenschaften vorhandener Vertrauensstellungen im Detail-Fenster unter <cn=fqdn der vertrauten domain> an. Die Eigenschaft TrustAttributes ist entscheidend. Normalerweise sollte da stehen 32 (=ATTRIBUTES_WITHIN_FOREST) stehen, bei uns stand da aber 36 (=ATTRIBUTES_WITHIN_FOREST+ATTRIBUTES_QUARANTINED_DOMAIN).

 

Unter http://rallenhome.com/books/adcookbook/src/02.19-view_trusts.vbs.txt gibts ein script, mit dem der Zahlenwert entschlüsselt werden kann.

 

Christoph