Discussion:
SID werden in der ACL nicht mehr aufgelöst
(zu alt für eine Antwort)
Torsten Krimmer
2007-04-03 08:06:05 UTC
Permalink
Wir haben bei 2 Fileservern das Problem, dass in der ACL (Register
"Sicherheit")sämtlicher Ordner die SID's der Domänengruppen nicht mehr
aufgelöst werden.
DNS scheint alles i.O. zu sein - alle AD-Konsolen funktionieren von den
Maschinen. Wenn ich zB einen neuen Ordner anlege und dann eine Domänengruppe
darauf berechtige, zeigt er mir die Gruppe zuerst korrekt an. Sobald ich mit
"oK" das Fenster schließe und dies übernehme - dann nochmal in die ACL
reinschaue - sehe ich nur noch die SID dieser Gruppe.
Lokale Gruppen werden korrekt angezeigt - nur sämtliche Domänengruppen nicht
mehr.
Auch bei den lokalen Benutzer-Gruppen ist dies so. Beispielsweise wird bei
der Gruppe der lokalen Administratoren nur der Administrator richtig
dargestellt - zwei Domänengruppen auch nur mit ihrer SID.

Hat jemand eine Idee??

Danke und Gruß
Torsten
Nils Kaczenski [MVP]
2007-04-03 08:47:51 UTC
Permalink
Moin,
Post by Torsten Krimmer
Hat jemand eine Idee??
die nächstliegende Idee ist, dass die Kommunikation mit der Domäne nicht
richtig funktioniert. Zeigen andere Maschinen dasselbe Phänomen? Ändert
ein Neustart was? Sagt das Eventlog was Brauchbares?


Schöne Grüße, Nils
--
Nils Kaczenski - MVP Windows Server
www.faq-o-matic.net
Antworten bitte nur in die Newsgroup!
PM: Vorname at Nachname .de
https://mvp.support.microsoft.com/profile/Nils.Kaczenski
Torsten Krimmer
2007-04-03 09:24:01 UTC
Permalink
Post by Nils Kaczenski [MVP]
die nächstliegende Idee ist, dass die Kommunikation mit der Domäne nicht
richtig funktioniert.
ja irgendsowas vermute ich auch
Post by Nils Kaczenski [MVP]
Zeigen andere Maschinen dasselbe Phänomen?
zwei Fileserver haben das Problem
Post by Nils Kaczenski [MVP]
Ändert ein Neustart was?
Nein, Maschine wurde bereits neu gestartet - Phänomen immer noch vorhanden.
Post by Nils Kaczenski [MVP]
Sagt das Eventlog was Brauchbares?
Nicht wirklich, außer auch Probleme mit Gruppenrichtlinienverarbeitung, wsa
ja wieder auf Kommunikation mit Domäne hindeutet.

Ergänzend vielleicht noch zu erwähnen, dass die Maschine an einem
Sub-Standort steht und diese bei uns von "Standort-Admins" betreut werden.
Wir sind für die zentrale Administration des AD zuständig.
Wir haben im März einige DCs an mehreren Standorten ausgetauscht (Migration
von W2k auf W2k3). Wir sind so vorgegangen, dass wir den neuen immer parallel
in Betrieb genommen haben und nachdem die Standortadmins Ihre Server und
Clients auf den neuen DNS (DC ist gleichzeitig DNS) umgestellt hatten, haben
wir den alten herabgestuft und abgeschaltet.
Hat aber bis jetzt nirgendwo zu Problemen geführt - auch an dem betroffenen
Standort sind es wohl "nur" die zwei Fileserver...

Könnten die Server da irgendwo ein DNS Problem haben? Das komische ist
allerdings, dass das einige Tage nach der Abschaltung des alten DCs kein
Problem gewesen scheint; die Fehlermeldungen bzgl. der GPOs beginnen seit ca.
2 tagen.

gruß,
Torsten
Nils Kaczenski [MVP]
2007-04-03 10:42:48 UTC
Permalink
Moin,
Post by Torsten Krimmer
Könnten die Server da irgendwo ein DNS Problem haben?
auch das wäre eine der nächstliegenden Ideen bei der Problemlage.

http://www.faq-o-matic.net/content/view/98/45/


Schöne Grüße, Nils
--
Nils Kaczenski - MVP Windows Server
www.faq-o-matic.net
Antworten bitte nur in die Newsgroup!
PM: Vorname at Nachname .de
https://mvp.support.microsoft.com/profile/Nils.Kaczenski
Torsten Krimmer
2007-04-04 19:23:08 UTC
Permalink
auch das wÀre eine der nÀchstliegenden Ideen bei der Problemlage.
http://www.faq-o-matic.net/content/view/98/45/
Das haben wir eigentlich alles korrekt.

Habe heute das Problem gefunden. Bin da schon so oft drauf gestoßen, nie hat es was damit zu tun gehabt, aber jetzt!!:
--> SMB Signing.
Der betroffene Standort hatte auf alle Server per GPO folgende Werte gesetzt:

Microsoft-Netzwerk (Client): Kommunikation digital signieren (immer) Deaktiviert
Microsoft-Netzwerk (Client): Kommunikation digital signieren (wenn Server zustimmt) Deaktiviert
Microsoft-Netzwerk (Server): Kommunikation digital signieren (immer) Deaktiviert
Microsoft-Netzwerk (Server): Kommunikation digital signieren (wenn Client zustimmt) Deaktiviert

MIt Inbetriebnahme des neuen DC 2003 hat das nun das Problem verursacht - habe in der GPO die Werte auf "nicht definiert" gesetzt und dann in der Registry die entsprechenden Werte zurÃŒckgesetzt. Danach Server neu gestartet und alles funktioniert wieder.

Danke fÃŒr alle Hinweise.

Gruß,
Torsten.
Mark Heitbrink [MVP]
2007-04-05 08:00:28 UTC
Permalink
Hi,
Habe heute das Problem gefunden. Bin da schon so oft drauf gestoßen, nie
--> SMB Signing.
Anstelle der manuellen Reg-Einträge würde ich es per GPO definieren, denn
MS verwendet die unterschiedlichsten Grundeinstellungen beim SMB Sig, je
nach OS und SP Level. Damit dir ein SP/Hotfix/Patch nicht in die Quere
kommen kann, ist die Definition per GPO die sichere Variante.
Denn dann ist es egal, was der Patch in der Reg konfiguriert, es wird von
der GPO überstimmt.
http://www.gruppenrichtlinien.de/HowTo/SMB_Signing.htm

Tschö
Mark
--
Mark Heitbrink - MVP Windows Server - Group Policy

Homepage: www.gruppenrichtlinien.de - deutsch
Blog: gpupdate.spaces.live.com - english
Torsten Krimmer
2007-04-05 13:12:01 UTC
Permalink
Post by Mark Heitbrink [MVP]
Anstelle der manuellen Reg-Einträge würde ich es per GPO definieren, denn
MS verwendet die unterschiedlichsten Grundeinstellungen beim SMB Sig, je
nach OS und SP Level. Damit dir ein SP/Hotfix/Patch nicht in die Quere
kommen kann, ist die Definition per GPO die sichere Variante.
Habe ich in der Tat schon öfters darüber nachgedacht.

Frage: Wir haben ein inwischenrelativ großes AD (SingleDomain) mit mehr als
20 Standorten - in den Standorten kennen wir teilweise die Konfigurationen
nicht.
Gibt das definitiv keine Probleme, wenn ich die Einstellugen entsprechend
Deines Artikels setzen würde? Auch nicht, bis zB alle Maschinen die
Einstellung gezogen haben?
Nicht dass wir da Probleme kriegen, wenn wir jeweils in DefDomPolicy und
DefDomcontrollerPolicy die Erzwungene Kommunikation auf "nicht definiert"
lassen und die "wenn mögliche" aktivieren.
Oder müssen ggf. laufende Maschinen neu gestartet werden?

Gruß,
Torsten.
Mark Heitbrink [MVP]
2007-04-05 13:23:42 UTC
Permalink
Hi,
Post by Torsten Krimmer
Gibt das definitiv keine Probleme, wenn ich die Einstellugen entsprechend
Deines Artikels setzen würde?
Nein. Denn nur wenn der jeweilige Partner zustimmt wird das Paket signiert,
wenn er es nicht kann (Kopierer, Scanner, NAS, Linux Samba, Mac whatever)
dann werden die Pakete nicht signiert und es geht.
Post by Torsten Krimmer
Nicht dass wir da Probleme kriegen, wenn wir jeweils in DefDomPolicy und
DefDomcontrollerPolicy die Erzwungene Kommunikation auf "nicht definiert"
lassen und die "wenn mögliche" aktivieren.
Oder müssen ggf. laufende Maschinen neu gestartet werden?
Letzteres Ja. Aber von "Nicht konfiguriert" habe nie etwas gesagt. Ich
konfiguriere es. Denn Nichtkonfiguriert hat ja das Problem, daß die
aktuelle Einstellung nicht überschrieben wird und diese ist je nach OS
und SP untercshiedlich und führt zu Problemen.

Deswegen der Abschnitt:
"Bestpraxis: Default Domain Policy + Default Domain Controllers Policy"
in dem Artikel.

@Norbert: nein ich möchte nicht über Q916846 sprechen :-))

Tschö
Mark
--
Mark Heitbrink - MVP Windows Server - Group Policy

Homepage: www.gruppenrichtlinien.de - deutsch
Blog: gpupdate.spaces.live.com - english
Torsten Krimmer
2007-04-05 13:44:01 UTC
Permalink
Post by Mark Heitbrink [MVP]
Nein. Denn nur wenn der jeweilige Partner zustimmt wird das Paket signiert,
wenn er es nicht kann (Kopierer, Scanner, NAS, Linux Samba, Mac whatever)
dann werden die Pakete nicht signiert und es geht.
Ok hab ich verstanden.
Post by Mark Heitbrink [MVP]
Post by Torsten Krimmer
Oder müssen ggf. laufende Maschinen neu gestartet werden?
Letzteres Ja. Aber von "Nicht konfiguriert" habe nie etwas gesagt. Ich
konfiguriere es. Denn Nichtkonfiguriert hat ja das Problem, daß die
aktuelle Einstellung nicht überschrieben wird und diese ist je nach OS
und SP untercshiedlich und führt zu Problemen.
Sorry, ja - nicht "Nich konfiguriert" sd. Deaktiv für Erzwungen und Aktiv
für "Wenn Server/Client zustimmt".
Laufende Maschinen machen das ganze für uns schon wieder etwas schwierig -
wie gesagt: größere Umgebung - mehrere Standorte - dezentrale Administration.
Aber vielleicht können wirs planen...
Post by Mark Heitbrink [MVP]
@Norbert: nein ich möchte nicht über Q916846 sprechen :-))
Warum nicht? ;-) Gibts doch noch Stolpersteine?

Gruß,
Torsten.
Mark Heitbrink [MVP]
2007-04-05 14:33:31 UTC
Permalink
Hi,
Post by Torsten Krimmer
Post by Mark Heitbrink [MVP]
@Norbert: nein ich möchte nicht über Q916846 sprechen :-))
Warum nicht? ;-) Gibts doch noch Stolpersteine?
Nein, aber der Patch erlaubt dir ein komplette Fehlkonfiguration per GPO
oder auch per Hand und er biegt es trotzdem wieder richtig.
Das halte ich für total fahrlässig von MS, dnen vielleicht wollte ich
bewusst die Sig abschalten da es mich mordsperformance über das Netzwerk
kostet bei 15.564 1kb großen Dateien ... und schwupps, ist SMB Sig wieder
an, und ich wunder mich, warum meine Konfiguration niocht so geht wie
ich es definiert habe.

MS war es nur leid die Support Anfragen nach SMB zu beantworten, daraufhin
haben sie den Patch rausgebracht, der nach dem Prinzip:
"egal was du machst, ich mach es wie ich es will" arbeitet :-(

Ist einer von Norberts "Lieblings-Artikeln" :-)

Tschö
Mark
--
Mark Heitbrink - MVP Windows Server - Group Policy

Homepage: www.gruppenrichtlinien.de - deutsch
Blog: gpupdate.spaces.live.com - english
unknown
2007-04-05 16:01:43 UTC
Permalink
Huhuu,
Post by Mark Heitbrink [MVP]
Nein, aber der Patch erlaubt dir ein komplette Fehlkonfiguration per
GPO oder auch per Hand und er biegt es trotzdem wieder richtig.
Das halte ich für total fahrlässig von MS, dnen vielleicht wollte ich
bewusst die Sig abschalten da es mich mordsperformance über das
Netzwerk kostet bei 15.564 1kb großen Dateien ... und schwupps, ist
SMB Sig wieder an, und ich wunder mich, warum meine Konfiguration
niocht so geht wie
das halte ich aber für einen wichtigen Hinweis,
den Du IMHO auf Deiner SMB-Seite erwähnen solltest.
Du hast doch über Ostern genug Zeit ;-)
--
Regards from Mainz/Germany
Yusuf Dikmenoglu - MVP Windows Server
Blog: http://blog.dikmenoglu.de
http://www.faq-o-matic.net
Norbert Fehlauer [MVP]
2007-04-07 19:23:34 UTC
Permalink
Mark Heitbrink [MVP] wrote:
Hi,
Post by Mark Heitbrink [MVP]
Post by Mark Heitbrink [MVP]
@Norbert: nein ich möchte nicht über Q916846 sprechen :-))
Wieso denn nicht, ist doch ein hervorragendes Thema ;) Und immerhin gibts ja
inzwischen auch eine halbwegs vernünftige Verteilmethode mittels WSUS (nach
nur 8 Monaten). :D
Post by Mark Heitbrink [MVP]
Nein, aber der Patch erlaubt dir ein komplette Fehlkonfiguration per
GPO oder auch per Hand und er biegt es trotzdem wieder richtig.
Das halte ich für total fahrlässig von MS, dnen vielleicht wollte ich
bewusst die Sig abschalten da es mich mordsperformance über das
Netzwerk kostet bei 15.564 1kb großen Dateien ... und schwupps, ist
SMB Sig wieder an, und ich wunder mich, warum meine Konfiguration
niocht so geht wie
ich es definiert habe.
Naja man kann immer noch unsigniert konfigurieren. Man muß es nur bewußt
tun. Und genau deswegen find ich den Patch so überflüssig. ;)
Post by Mark Heitbrink [MVP]
Ist einer von Norberts "Lieblings-Artikeln" :-)
Merkt man das?

Bye
Norbert

Loading...