none
Terminal-Server-GPO für Remote Sitzungshost RRS feed

  • Frage

  • Hi all,

    ich hoffe ihr könnt mir helfen, da ich so langsam verzweifle.

    ich habe eine spezielle GPO für die Terminalserver festgelegt. Dazu
    eine OU angelegt, in welcher die Terminalserver auch sind. Diese
    GPO habe ich dann auch mit der Terminalserver-OU verknüpft.

    Anschließend habe ich eine Gruppe für die Terminal-Server-User
    angelegt, "RDS_Restrictiv" Diese Gruppe habe ich nun bei der Terminal-Server-GPO bei der
    Sicherheitsfilterung hinzugefügt. Die Rechte bestehen aus lesen und GPO
    übernehmen. Authentifizierte User und Admins haben dieses Recht nicht,
    da es sich ja nur auf die Mitglieder der Gruppe Terminal-Server beziehen
    soll.

    Alles schön und gut, nur funktionieren die Einschränkungen der User
    nicht auf dem Terminalserver. Das ganze funktioniert aber dann, wenn ich
    auch die Terminalserver selbst in die Sicherheitsfilterung mit hinzu
    nehme. Das verstehe ich nicht. Ich habe ja schließlich schon die
    Termin-GPO mit der Terminal-OU verknüpft. Warum sollte ich den dann noch
    die Terminalserver in die Sicherheitsfilterung mit auf nehmen? Außerdem habe ich nun das Phänomen, dass ich manche Anwendungen als Admin nicht mehr deinstallieren kann und bekomme die Fehlermeldung, dass ich dies Aufgrund den Systemrichtlinien nicht deinstallieren darf.

    Habe ich einen logischen Fehler? es stimmt doch, dass man die Terminalserver nicht nochmal in die Sicherheitsfilterung der GPO mit aufnehmen muss, wenn die Terminalserver-GPO mit dem Container der Terminalserver verknüpft ist, oder?

    Danke im Voraus!


    Grüße

    Marc

    PS. Loopback "zusammenführen" ist aktiviert.

    • Bearbeitet Matthiasss Montag, 4. August 2014 06:38
    Montag, 4. August 2014 06:37

Antworten

  • Kannst Du denn noch wenigstens die GUID der Gruppenrichtlinie irgendwo sehen (ist so eine ellenlange Kombination in geschweiften Klammern, z.B.  {000A435345-dfdf....}?

    Grundsätzlich sind alle Richtlinien lokal in Dateien gespeichert und zwar unter C:\WINDOWS\SYSVOL\sysvol\<FQDN>\Policies. Wenn Du die GUID nicht mehr findest, könntest Du versuchen, in dem genannten Ordner einfach per Doppelklick jeden Ordner zu öffnen. Bei dem Ordner, wo Dir der Zugriff verweigert wird, übernimmst Du dann einfach den Besitz und schon hast Du wieder die Berechtigungen. :-)

    Alternative: Richtlinie löschen und neu erstellen. Ist natürlich aufwändig, wenn Du viele Einschränkungen drin hast.

    • Als Antwort markiert Matthiasss Mittwoch, 6. August 2014 06:26
    Montag, 4. August 2014 15:19
  • > Ich weiß welche GUID im Sysvol-Ordner die Terminal-GPO ist. Das hab ich
     
    Sysvol reicht nicht! Du mußt auch die Rechte im AD korrigieren
    (Domain\System\Policies\{GUID}).
     

    Martin

    Mal ein GUTES Buch über GPOs lesen?

    NO THEY ARE NOT EVIL, if you know what you are doing: Good or bad GPOs?
    And if IT bothers me - coke bottle design refreshment :))
    • Als Antwort markiert Matthiasss Mittwoch, 6. August 2014 06:26
    Dienstag, 5. August 2014 10:16

Alle Antworten

  • Hallo Marc,

    doch, das ist völlig normal. Wenn Du eine Richtlinie erstellst und dann die Sicherheitsfilterung manuell anpasst, muss mindestens das Zielobjekt - in dem Fall der/die Terminalserver - in der Lage sein, die Richtlinie zu lesen. 

    Normal ist ja immer "Authentifizierte Benutzer" hinterlegt. Das umfasst sowohl alle Benutzer- als auch ALLE COMPUTERKONTEN ("Benutzer" ist in dem Fall irreführend). 

    Normalerweise hast Du Recht - das Computerkonto muss eine Richtlinie, die nur Benutzereinstellungen enthält, nicht lesen können. Bei Terminalservern ist das aber anders, da Du dort ja Benutzerrichtlinien anwenden willst, die aber nur auf dem Terminalserver gelten sollen (sonst würdest Du die GPO ja auf die OU mit den Benutzerkonten direkt verknüpfen).

    Langer Rede kurzer Sinn:
    1. In der Richtlinie muss die Einstellung "Loopbackverarbeitung" aktiviert sein --> hast Du schon
    2. In der Sicherheitsfilterung muss die Benutzergruppe UND das Computerkonto des/der Terminalserver (bei mehreren Servern am Besten eine eigene Gruppe erstellen) hinterlegt sein --> keine Admins und keine "Authentifizierte Benutzer"-Gruppe!
    3. In der Benutzergruppe darf kein Administrator enthalten sein (der hat auch so Zugriffsrechte, ansonsten direkt auf dem Server in der Gruppe "Remotedesktopbenutzer" hinterlegen)

    Ich schätze, dass der Fehler irgendwo bei Punkt 2 oder 3 liegt, da sich Deine Einschränkungen auch auf den Admin auswirken.

    Gruß

    Ben

    Montag, 4. August 2014 09:22
  •  
    > 2. In der Sicherheitsfilterung muss die Benutzergruppe UND das
    > Computerkonto des/der Terminalserver (bei mehreren Servern am Besten
    > eine eigene Gruppe erstellen) hinterlegt sein --> keine Admins und keine
    > "Authentifizierte Benutzer"-Gruppe!
     
    Reden wir über Loopback "Merge" oder "Replace"? Bei "Merge" stimmt das
    "UND" oben.
     
    Der (durch mich verursachte :-)) KB dazu:
     

    Martin

    Mal ein GUTES Buch über GPOs lesen?

    NO THEY ARE NOT EVIL, if you know what you are doing: Good or bad GPOs?
    And if IT bothers me - coke bottle design refreshment :))
    Montag, 4. August 2014 09:43
  • ops, ich hab die Admins (Domänden-Admin und Orga-Admin) bei den Rechten der GPO rausgenommen. Jetzt kann ich nicht mehr auf die GPO selbst mehr zugreifen bzw. bearbeiten, da mir das Leserecht fehlt... :-/

    Was nun?


    • Bearbeitet Matthiasss Montag, 4. August 2014 13:00
    Montag, 4. August 2014 12:59
  • Kannst Du denn noch wenigstens die GUID der Gruppenrichtlinie irgendwo sehen (ist so eine ellenlange Kombination in geschweiften Klammern, z.B.  {000A435345-dfdf....}?

    Grundsätzlich sind alle Richtlinien lokal in Dateien gespeichert und zwar unter C:\WINDOWS\SYSVOL\sysvol\<FQDN>\Policies. Wenn Du die GUID nicht mehr findest, könntest Du versuchen, in dem genannten Ordner einfach per Doppelklick jeden Ordner zu öffnen. Bei dem Ordner, wo Dir der Zugriff verweigert wird, übernimmst Du dann einfach den Besitz und schon hast Du wieder die Berechtigungen. :-)

    Alternative: Richtlinie löschen und neu erstellen. Ist natürlich aufwändig, wenn Du viele Einschränkungen drin hast.

    • Als Antwort markiert Matthiasss Mittwoch, 6. August 2014 06:26
    Montag, 4. August 2014 15:19
  • Danke Dir!

    Ich weiß welche GUID im Sysvol-Ordner die Terminal-GPO ist. Das hab ich anhand des Datums feststellen können. Ich habe nun bei den Hauptordner einfach die Berechtigungen neu gesetzt, aber funktioniert immer noch nicht. Ich werde mich dann mal durch die Ordner durchklicken, evtl. wurde nicht alle Berechtigungen der Unterordner ersetzt.


    • Bearbeitet Matthiasss Montag, 4. August 2014 15:41
    Montag, 4. August 2014 15:40
  • funktioniert leider nicht.

    Werden morgen den Ordner löschen und die GPO neu anlegen.. Trotzdem Danke

    Montag, 4. August 2014 15:50
  • muss ich noch irgendetwas beachten? schließlich würde ich die gpo gerne sauber entfernen.

    Dienstag, 5. August 2014 05:56
  • Hi,

    es wundert mich etwas, dass das mit den Berechtigungen nicht funzt... Naja.

    Normalerweise sollte es reichen, wenn Du den Ordner löschst. Du kannst ja den Ordner einfach umbenennen (in .old) und schauen, ob sie in der GPO-Konsole verschwindet. Wenn nicht, dann muss sie wohl anderweitig gelöscht werden, wie, weiß ich jetzt aber leider nicht. In dem Fall nimmst Du das .old erstmal wieder raus, damit alles wieder ist wie vorher.

    Gruß

    Ben

    Dienstag, 5. August 2014 06:23
  • > Ich weiß welche GUID im Sysvol-Ordner die Terminal-GPO ist. Das hab ich
     
    Sysvol reicht nicht! Du mußt auch die Rechte im AD korrigieren
    (Domain\System\Policies\{GUID}).
     

    Martin

    Mal ein GUTES Buch über GPOs lesen?

    NO THEY ARE NOT EVIL, if you know what you are doing: Good or bad GPOs?
    And if IT bothers me - coke bottle design refreshment :))
    • Als Antwort markiert Matthiasss Mittwoch, 6. August 2014 06:26
    Dienstag, 5. August 2014 10:16
  • Aaaaahhhh, da war ja was - Du hast recht, danke! :-)
    Dienstag, 5. August 2014 10:46
  • hat geklappt! super! danke euch beiden!
    Dienstag, 5. August 2014 12:59
  • Kein Problem! Bitte noch die Antwort(en) entsprechend markieren. :-)
    Dienstag, 5. August 2014 14:35