Hier ist mal ein interessantes Problem....

[mcbelly 10]

Ich habe einen Terminalserver in einer eigenen OU. an diesem TS melden sich User an, die in einer anderen OU liegen. In der TS OU gibt es bestimmte restriktive policies, die den Server "dichtmachen" (wie im KB Artikel "Locking down Windows 2003 Terminal Server Sessions").

 

Das Problem ist bisher nur bei einem User aufgetreten.

Dieser hat sich am Freitag von seiner normalen, lokalen WS abgemeldet, hat sich _nicht_ am TS angemeldet, hat sich am Montag an seiner WS wieder angemeldet und (tataa!) es greift die policy vom Terminalserver. Weder die WS, noch der User sind in der TS OU, die policy ist auch nur dort verlinkt. Auch das GP result tool bestätigt das, laut dem stimmen die Einstellungen nicht mit der Realität überein. Wenn ich mich jetzt mit einem anderen User (auch Dom.Admin)an der Maschine anmelde habe ich auch Einschränkungen (kann nicht runterfahren, kein cmd, etc). Wenn der User sich an einer anderen Maschine anmeldet, geht auch nix.

 

Jetzt wirds richtig lustig : Wenn er von einer anderen Maschine per RDP auf seinen Client zugreift und sich anmeldet - dann geht (fast) alles....

Ich hab jetzt eine neue OU erstellt, User und Maschine rein und die TS policy gegenteilig eingestellt. D.h. in der Original Policy steht z.B. "Zugriff auf cmd verbieten" - Aktiviert, dann hab ich das auf deaktiviert gesetzt. Einiges funktioniert jetzt wieder (er darf seinen PC wieder runterfahren!), aber das ist noch weit von "befriedigend" entfernt.

Ich tippe darauf, dass sich einige Registry Einträge "irgendwie" ins Profil geschrieben haben, da er local Admin ist, darf er natürlich auch in die Maschinenregistry schreiben. Ich würde ihm ja gerne ein neues Profil geben, aber er ist Palmuser - und den muss er vorher deinstallieren, sonst zerschiesst er sich gleich sein Postfach mit. Das geht aber nicht, weil - richtig geraten- der Zugriff auf die Systemsteuerung nicht erlaubt ist......

 

Auch so Sachen wie policy durchdrücken, etc greifen nicht.

 

Hat jemand auch nur Ansatzweise eine Idee ? Sowas hab ich noch nie gesehen....

 

 

Gruß

mcbelly

[FLOST 10]

hast du in der neuen ou die vererbung der gp aktiv oder nicht? wenn sie aktiv ist, könnte da noch was von der vermurksten reinspielen.

 

aber sonst reichlich kurios!

 

fg

 

fLOST

[mcbelly 10]

Nein nein - die TS- policy greift nicht auf die neue OU - die ist ganz woanders, kann auch nicht vererbt werden....

 

Ich bin uahc irgendwo zwischen amüsiert und verärgert. Vor allem : das glaubt einem ja auch keiner....

 

 

 

Gruß

mcbelly

[uheeb 10]

hast du auf der station zugriff auf die mmc? (ausführen: mmc -a) wenn ja dann füge das snap-in "sicherheitskonfiguration- und analyse" ein. rechte maustaste aufs snap-in/datenbank öffnen... dann erstellst du eine neue datenbank. als nächstes wählst du eine vorlage aus (setup security ist der auslieferungszustand) anschliessend "computer jetzt analysieren..."

 

anschliessend kannst du die lokalen sicherheitsrichtlinien durchforsten und allenfalls anpassen. wenn die einstellungen so sind, wie du sie brauchst, dann kannst du den "computer jetzt konfigurieren..." jetzt solltest du wieder alles machen können, was du willst... (lokal)

 

hoffentlich hilft dir das weiter. viel glück...

 

 

zur active directory:

sieht diese ungefähr so aus:

 

domain

|

|- OU: Benutzer

|- OU: Computer

|- OU: Terminalserver

 

wenn dem so ist, würde ich die default domain policy mal noch kurz kontrollieren, da hier die vererbung nicht einwirken kann...

 

gruss urs

[mcbelly 10]

Hi Urs,

 

ja, so ungefähr sieht das AD aus. Das mit der lokalen Sicherheitsrichtlinie hab ich gemacht, hat soweit auch geholfen, nur leider sind einige Sachen, die in der User Config eingestellt werden so nicht machbar und wenn es in der DEfault wäre, würde es ja für alle User greifen...

 

Ich hab ihn jetzt wieder soweit, das alles funktioniert - mit einer "Gegenpolicy"....

 

Naja, ich bin froh das alles wieder geht. Vielen Dank für eure Hilfe.

 

Gruß

mcbelly