adminSDholder wirkt ohne protected Groups

[Baw 10]

Hallo zusammen

 

Wir haben folgendes Problem: Nach dem Einspielen eines Exchange Patchs muss, wenn ein Benutzer Mails im Namen eines anderen Benutzers verschicken will, im AD die Send As Berechtigung zugeteilt werden. Das funktioniert an sich ganz gut, aber jetzt haben wir das Problem, dass wir offenbar Benutzer haben, die mal Domänenadmin waren, es jetzt aber nicht mehr sind, deren ACL aber offenbahr immer noch vom adminSDholder zurückgesetzt werden.

Die Benutzer sind nicht mehr Mitglied einer Protected Group.

Noch was zur Umgebung:

drei DCs, W2K3 SP1

 

Hat jemand von euch schon mal so was erlebt, bzw. hat jemand eine Idee, woran es liegen könnte, dass adminSDHolder immer noch wirkt...

[NorbertFe 2.027]

Hat jemand von euch schon mal so was erlebt, bzw. hat jemand eine Idee, woran es liegen könnte, dass adminSDHolder immer noch wirkt...

 

Ja. Der Haken, dass der Nutzer die Berechtigungen erben sollen fehlt bei diesen Konten. Den mußt du entweder manuell setzen, oder per Skript (gibts in der MSKB).

 

Bye

Norbert

[Baw 10]

Danke für die schnelle Antwort, aber es wird wirklich jedes mal wieder neu überschrieben (halt wie bei Admins). Ich kann einstellen, wass ich will, nach einer Stunde wird es zurück gestellt.

Ich habe testhalber einen Benutzer, der noch nie admin war, in die Domänenadmin Gruppe aufgenommen und ihn wieder entfehrnt. Nun habe ich exakt das selbe Problem bei diesem Benutzer.

Prüfen, ob adminSDholder ausgefürht wurde mache ich übrignes mit dem Attribut AdminCount.

[olc 18]

Hallo Baw,

 

aller Wahrscheinlichkeit nach ist der Benutzer bzw. sind die Benutzer doch noch in einer der geschützten Gruppen - unter Umständen verschachtelt, nicht direkt.

 

Wenn die Verschachtelung nicht über Verteilergruppen erfolgt, bekommst Du das - angemeldet als der betroffene Benutzer - mit einem "whoami /all" heraus --> zumindest in welchen Gruppen er Mitglied ist, jedoch nicht über welchen "Verschachtelungspfad".

Erfolgt die Verschachtelung über Verteilergruppen wird es schwierig.

 

Laß doch einmal das VB-Script aus Delegated permissions are not available and inheritance is automatically disabled durchlaufen - wenn der AdminCount tatsächlich wieder hochgezählt wird, kannst Du sicher sein, daß es an den Gruppenmitgliedschaften hängt.

 

Das Script setzt übrigens auch gleich das Vererbungsflag zurück, d.h. die Vererbung ist wieder aktiv.

 

Viele Grüße

olc

[Baw 10]

Hallo

 

Hab ich gleich mal überprüft, aber es ist wirklich so, dass der Benutzer sich in keiner der geschützten Gruppen befindet (den Standard kann man ja nicht ändern, oder?!:confused:)

Der KB-Artikel den du angegeben hast kenne ich (leider:rolleyes:) schon beinahe ausswendig. Das Script bewirkt nicht anderes, als es das Attribut AdminCount auf 0 setzt und das Vererbungsflag setzt. Das habe ich auch schon (von Hand) versucht, hatte aber keinen Einfluss. AdminCount wird auf 1 gesetzt, vererbung wieder deaktiviert... (ich habe testhalber die Vererbung auf dem adminSDholder Container aktiviert und das wurde problemlos übernommen).

 

Um ganz sicher zu sein mache ich gerade einen kleinen Test:

- komplett neuer User angelegt

- User zur Gruppe "Administrators" hinzugefügt

- Warten bis adminSDholder wirkt

- Gruppe "Administrators" entfehrnt

- Vererbungsflag gesetzt

- ein weiterer User unter Security hinzugefügt und Full Control gegeben

- Warten... (darauf, dass admiNSDholder wieder wirkt)

[olc 18]

Hi Baw,

 

Hab ich gleich mal überprüft, aber es ist wirklich so, dass der Benutzer sich in keiner der geschützten Gruppen befindet

 

Wie oben geschrieben siehst Du nicht alle Gruppenmitgliedschaften mit "whoami /all", wenn z.B. Verteilergruppen dazwischenliegen.

 

(den Standard kann man ja nicht ändern, oder?!:confused:)

 

Doch, grundsätzlich kann man dies ändern - wobei Du jedoch nur Accounts ausschließen kannst, nicht neue hinzufügen. Ohne jetzt gleich etwas zu ändern (!), kannst Du einmal das folgende Attribut überprüfen: CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=<domain>,DC=<tld> --> "dsHeuristics". Was für ein Wert hat das Attribut? Interessant ist die 16. Stelle von vorn gezählt. Wenn das Attribut keinen Wert hat ("not set"), ist das ebenfalls in Ordnung - es wurde in diesem Fall nichts geändert.

 

Das Script bewirkt nicht anderes, als es das Attribut AdminCount auf 0 setzt und das Vererbungsflag setzt.

 

Das weiß ich. ;) Wollte nur sicher gehen, daß das Vererbungsflag von Dir gesetzt wurde und zur Überprüfung der AdminCount auf "0" ist.

 

(ich habe testhalber die Vererbung auf dem adminSDholder Container aktiviert und das wurde problemlos übernommen).

 

Was Du auf jeden Fall schnellstmöglich wieder rückgängig machen solltest. ;)

 

Um ganz sicher zu sein mache ich gerade einen kleinen Test:

- komplett neuer User angelegt

- User zur Gruppe "Administrators" hinzugefügt

- Warten bis adminSDholder wirkt

- Gruppe "Administrators" entfehrnt

- Vererbungsflag gesetzt

- ein weiterer User unter Security hinzugefügt und Full Control gegeben

- Warten... (darauf, dass admiNSDholder wieder wirkt)

 

Ok, warten wir erst einmal ab.

 

Viele Grüße

olc

[Baw 10]

Dass Verteilerlisten gebraucht wurde bezweifle ich zwar sehr, ist aber nicht unmöglich...

 

 

 

CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=<domain>,DC=<tld> --> "dsHeuristics"

 

Der Pfad habe ich zwar gefunden, aber das Attribut dsHeuristics scheint es bei mir nicht zu geben...

 

 

 

Was mein Test angeht, der verlief erfolgreich (also, meine gesetzten Einstellugnen wurden so belassen, ohne vom adminSDholder überschrieben zu werden).

Was mich aber verwirrt ist, dass ich bei meinem eigenen User (war noch nie in der Adminsitratorengruppe) nachdem ich ihn kurzzeitig in die Administratorengruppe hinzugefügt habe, die selben "Symtome" aufweisst. Ich bin mir allerdings nicht mehr ganz sicher, ob er diese nicht schon vorher hatte...

 

 

Ich werde jetzt mal ins Wochenende gehen und mich nächsten Mittwoch wieder der Sache annehmen. Falls aber jemand noch Ideen hat, nur posten:)

 

Danke für eure Hilfe

Gruess

Baw

 

PS: Falls es irgendwas damit zu tun haben könnte: Es wurde früher mal ein Update von Windows 2000 auf Windows 2003 getätigt.

[olc 18]

Hallo,

 

der Test bestätigt also im Grunde, daß kein Fehlverhalten vorliegt.

 

Auch wenn Du scheinbar immer noch nicht überzeugt bist: Die betroffenen Benutzer sind mit Sicherheit Mitglied in einer der im KB-Artikel aufgeführten Gruppen.

 

Ich bin meist eher zurückhaltend mit "definitiven" Statements - aber in diesem Fall bin ich mir recht sicher... ;)

 

EDIT: Achso, eine Sache ist mir noch eingefallen: Unter Umständen laufen irgendwelche Scripts, die die Rechte ändern?

Du könntest das zumindest auf die Schnelle im Ansatz gegenprüfen, indem Du in den Metadaten eines betroffenen Objekts nachprüfst, auf welchem System der nTSecurityDescriptor zuletzt geändert wurde. Ist es der PDCe der Domäne ist die Chance immer noch so hoch, daß es sich um Mitglieder geschützter Gruppen handelt.

Ansonsten bleibt noch Auditing auf die Objekte, um den Verursacher festzustellen.

 

Ich denke jedoch weiterhin, daß Du bei den Gruppenmitgliedschaften suchen solltest. ;)

 

Viele Grüße

olc

[NorbertFe 2.027]

Was mein Test angeht, der verlief erfolgreich (also, meine gesetzten Einstellugnen wurden so belassen, ohne vom adminSDholder überschrieben zu werden).

 

In welchen weiteren Gruppen ist denn der betroffene User? Ich kenne Fälle, da wurde über Kontenoperatoren bzw. Druckoperatoren (auch geschachtelt) genau dieses Problem verursacht.

 

Bye

Norbert

 

PS: Dein Update hat damit nichts zu tun.

[Baw 10]

Hallo zusammen

 

Hier mal ein Update:

Ich bin meist eher zurückhaltend mit "definitiven" Statements - aber in diesem Fall bin ich mir recht sicher...

.. und du hast recht.

Die Benutzer, die Probleme verursachten waren (verschachtelt über mehrere Gruppen) Mitglied in der Drucker-Operatoren Gruppe.

Anzumerken ist, dass das Tool "whoami" (auch mit dem Schalter all) offenbahr nicht mehrfach verschachtelte Gruppe anzeigt, sondern nur die Gruppen der Gruppen in denen man Mitglied ist.

 

Danke für eure Hilfe :)

 

Gruess

Baw

[olc 18]

Hi Baw,

 

schön, daß es doch noch geklappt hat. :)

 

Whoami /all zeigt auch verschachtelte Gruppenmitgliedschaften an, es werden die Gruppenmitgliedschaften expandiert. Jedoch gibt es bei Verschachtelungen mit Verteilergruppen Probleme (siehe oben).

 

Eine andere Sache, die mir gerade noch eingefallen ist: Wo hast Du den whoami /all Export gezogen? Auf einem Client oder einem DC? Ich bin mir nicht 100% sicher, aber ich habe da so etwas im Hinterkopf, daß nur die dem ausführenden System bekannten Gruppen expandiert werden können. Vielleicht kann es hier Probleme geben, wenn es auf einem Client ausgeführt wird und ggf. nicht alle Gruppen korrekt auflösen kann. Aber wie gesagt, da bin ich mir nicht sicher. Käme auf einen Test an. ;)

 

Viele Grüße

olc

[NorbertFe 2.027]

Hallo zusammen

 

Hier mal ein Update:

 

.. und du hast recht.

Die Benutzer, die Probleme verursachten waren (verschachtelt über mehrere Gruppen) Mitglied in der Drucker-Operatoren Gruppe.

 

;) Grins schön, dass es so einfach ist ;)

 

Bye

Norbert

[Baw 10]

Wo hast Du den whoami /all Export gezogen?

 

Auf dem Client.

In der Verschachtelung waren keine Verteilerlisten drin.

 

Gruess

Baw