none
Firewall per GPO nur für bestimmte Gruppen/User RRS feed

  • Frage

  • Hallo zusammen,

    zunächst möchte ich mich entschuldigen. Die Frage wurde wahrscheinlich schon 1000 mal gestellt, aber entweder finde ich die Threads nicht oder sie sind so alt, dass ich einfach nochmal nachhören möchte, ob es mittlerweile eine Lösung gibt -.-

    Problem: Im Grunde möchten wir die Arbeitsergebnisse in einem Labor, welche mit einer Software erstellt und bearbeitet werden für eine bestimmte Benutzergruppe abschotten. Bedeutet, Mitglieder dieser Gruppen sollen explizit nur Zugang zu bestimmten Servern (z.B. Lizenzserver, DNS, Updateserver etc.) erhalten - jeglicher anderer Traffic soll blockiert werden. Anwender, die nicht zu dieser Gruppe gehören, sollen von diesen Einstellungen NICHT betroffen sein.

    Die notwendigen FW-Regeln zu setzen war kein Problem, aber da es sich ja leider um Computerrichtlinien handelt, kann ich den Scope nicht auf eben diese explizite Usergruppe beschränken.

    Könnt Ihr mir eine Lösung verraten oder auch einen Workaround mit dem sich das gewünschte Verhalten bewerkstelligen lässt? ...oder ist es einfach mit normalen Mitteln nicht möglich.

    Vielen Dank schonmal wenn jemand die Muße findet nochmals auf diese Frage zu antworten :-)

    Umgebungsbeschreibung:

    AD auf Win Srv 2012 R2
    Clients Windows 10 Ent.

    Clients und User liegen in verschiedenen OUs.

    Mittwoch, 7. September 2016 15:04

Antworten

  • Hi,
     
    Am 07.09.2016 um 17:04 schrieb St_Marcel:
    > leider um Computerrichtlinien handelt, kann ich den Scope nicht auf
    > eben diese explizite Usergruppe beschränken.
     
    Das geht nicht. Wie du schon gemerkt hast, gelten die FW Regeln für
    Computer. Das kannst du nicht in Abhängigkeit des Anwenders konfigurieren.
    Die Firewall müsste "Benutzer" verstehen, aber das tut die MS eigene FW
    nicht.
     
    Eventuell können das Drittanbiter, aber die sind dann nicht per GPO
    steuerbar, aber haben vielleicht eine eigene zentrale Management Konsole.
     
    Tschö
    Mark
    --
    Mark Heitbrink - MVP Group Policy - Cloud and Datacenter Management
     
    Homepage:  http://www.gruppenrichtlinien.de - deutsch
     
    • Als Antwort markiert St_Marcel Donnerstag, 8. September 2016 07:20
    Mittwoch, 7. September 2016 19:52
  • Moin,

    also wenn davon mein Feierabend abhinge, würden mir schon ein paar Lösungsansätze einfallen. Die wären aber in dem vorliegenden Fall alle mega krude und zum Kreischen, denn "mal eben einfach mit Bordmitteln" geht es tatsächlich nicht. Was Du versuchst, ist ja, wie Mark Minasi das mal treffend ausdrückte, "a silicon-based solution to a carbon-based problem".

    Here goes:

    1. Den Usern der betroffenen Gruppe so viele Rechte "andelegieren", dass sie den Computer aus OU1 in OU2 verschieben können, und dann in deren Login-Skript eben genau das tun.

    2. (etwas eleganter, aber immer noch zum Kreischen) Einen geplanten Task "bei Benutzer-Anmeldung" einrichten, der prüft, ob der User zu der besagten Gruppe gehört, und falls ja, (im System- oder Admin-Kontext) die notwendigen Firewall-Zusatzregeln setzt - und falls nein, diese deaktiviert.

    3. (so ist es *eigentlich* gemeint, aber zugegebenermaßen nicht ganz einfach umzusetzen) auf allen Systemen, auf die diese Benutzergruppe nicht zugreifen soll, das per Zugriffsrechte verbieten.

    4. (und das einzige, was wirklich funktioniert) ein 3rd Party-Produkt mit benutzerbezogenem Regelwerk einsetzen.

    5. (funktioniert meistens auch, zumindest für eine Weile) den Leuten klar machen, dass wenn sie auf irgendwelche Systeme außer X, Y und Z zugreifen, jemand kommt und sie im Schlaf erdrosselt.

    Aber was ich nicht ganz verstehe: Was wollt ihr mit dieser Methode erreichen?


    Evgenij Smirnov

    msg services ag, Berlin -> http://www.msg-services.de
    my personal blog (mostly German) -> http://it-pro-berlin.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com

    In theory, there is no difference between theory and practice. In practice, there is.

    • Als Antwort markiert St_Marcel Donnerstag, 8. September 2016 07:15
    Mittwoch, 7. September 2016 21:01
  • Zugegebener Maßen, war Securitygroup filtering respektive Zielgruppenaddressierung, so knapp vor Feierabend etwas zu kurz gegriffen... ():-)

    In Richtung Evgenijs "2" kreisten auch gerade meine Gedanken:

    • Firewall-Regeln per GPO im Computer-Kontext setzten, aber nicht aktivieren
    • bei der einzuschränkenden Usergruppe per Log-On und Log-Off Skript, die entsprechenen Regeln aktivieren/deaktivieren (notwendige Credentials als Secure-String übergeben)

    Abgesehen von "nicht schön" - hab ich was übersehen?

    Gruß TechnikSC885


    PS: wobei mir persönlich "5" auch sehr gut gefällt ;)

    • Bearbeitet TechnikSC885 Mittwoch, 7. September 2016 22:31 PS
    • Als Antwort markiert St_Marcel Donnerstag, 8. September 2016 07:15
    Mittwoch, 7. September 2016 21:24
  • Guten Morgen zusammen!

    Zu diesem traurigen Schluss bin ich mit einem befreundeten Sysadmin nach diversen Kalthopfengetränken gestern Abend auch gekommen. Es ist einfach nicht vorgesehen. ILT, WMI-Filter etc. können auch erst angewendet werden, wenn das Kind bereits in den Brunnen gefallen ist. Die einzige dreckige und reudige Lösung, auf die wir gekommen sind, ist so ziemlich das, was Evgenij auch schon geschrieben hat. In unserem Fall:

    1. Lokalen Serviceaccount mit entsprechenden Rechten erzeugen.
    2. PS-Skript mit Aktivierung/Deaktivierung entsprechender Regeln schreiben
    3. Via Logon/Logoff-Skript Gruppenzugehörigkeit prüfen und jenachdem das PS-Skript mit secured Creds im Userkontext des Srvaccs ausführen. Bei Logoff die Regeln wieder außer Kraft setzen.

    Das ist aber eine ziemlich dreckige Lösung wie ich finde und ich möchte diese Maßnahmen eigentlich nicht ergreifen. Gerade denke ich über Vorschlag 5 von Evgenji nach :D

    Um deine Frage zu beantworten, wofür der ganze Spaß ist: Bei der angesprochenen User-Gruppe handelt es sich um Studenten, deren Prüfungsleistung darin besteht mit der Software zu arbeiten und ein Modell zu entwickeln. Wir wollen verhindern, dass die Arbeitsdateien in irgendeiner Weise mit von Außen erreichbar sind, manipuliert oder unter den Studenten ausgetauscht werden können. Ich bin hier gerne für andere Lösungsvorschläge offen!

    Ansonsten möchte ich euch allen für eure Antworten danken! Es gibt nicht für jedes Probleme eine einfache und schöne Lösung.

    • Als Antwort markiert St_Marcel Donnerstag, 8. September 2016 07:20
    Donnerstag, 8. September 2016 07:15

Alle Antworten

  • Hallo St_Marcel,

    schau dir mal das Thema "Filtern nach Sicherheitsgruppen" bzw. "Zielgruppen-Addressierung" an.
    Damit sollte sich dein Problem meine ich lösen lassen.

    z.B. hier:
    http://www.gruppenrichtlinien.de/artikel/filtern-von-gruppenrichtlinien-anhand-von-benutzergruppen-wmi-und-zielgruppenadressierung/

    Wichtig in dem Zusammenhang => mit MS16-072 hat sich einiges geändert
    http://www.gruppenrichtlinien.de/artikel/sicherheitsfilterung-neu-erfunden-ms16-072-patchday-14062016/

    Gruß TechnikSC885



    • Bearbeitet TechnikSC885 Mittwoch, 7. September 2016 15:41 Typo
    Mittwoch, 7. September 2016 15:40
  • Hi,
     
    Am 07.09.2016 um 17:04 schrieb St_Marcel:
    > leider um Computerrichtlinien handelt, kann ich den Scope nicht auf
    > eben diese explizite Usergruppe beschränken.
     
    Das geht nicht. Wie du schon gemerkt hast, gelten die FW Regeln für
    Computer. Das kannst du nicht in Abhängigkeit des Anwenders konfigurieren.
    Die Firewall müsste "Benutzer" verstehen, aber das tut die MS eigene FW
    nicht.
     
    Eventuell können das Drittanbiter, aber die sind dann nicht per GPO
    steuerbar, aber haben vielleicht eine eigene zentrale Management Konsole.
     
    Tschö
    Mark
    --
    Mark Heitbrink - MVP Group Policy - Cloud and Datacenter Management
     
    Homepage:  http://www.gruppenrichtlinien.de - deutsch
     
    • Als Antwort markiert St_Marcel Donnerstag, 8. September 2016 07:20
    Mittwoch, 7. September 2016 19:52
  • Moin,

    also wenn davon mein Feierabend abhinge, würden mir schon ein paar Lösungsansätze einfallen. Die wären aber in dem vorliegenden Fall alle mega krude und zum Kreischen, denn "mal eben einfach mit Bordmitteln" geht es tatsächlich nicht. Was Du versuchst, ist ja, wie Mark Minasi das mal treffend ausdrückte, "a silicon-based solution to a carbon-based problem".

    Here goes:

    1. Den Usern der betroffenen Gruppe so viele Rechte "andelegieren", dass sie den Computer aus OU1 in OU2 verschieben können, und dann in deren Login-Skript eben genau das tun.

    2. (etwas eleganter, aber immer noch zum Kreischen) Einen geplanten Task "bei Benutzer-Anmeldung" einrichten, der prüft, ob der User zu der besagten Gruppe gehört, und falls ja, (im System- oder Admin-Kontext) die notwendigen Firewall-Zusatzregeln setzt - und falls nein, diese deaktiviert.

    3. (so ist es *eigentlich* gemeint, aber zugegebenermaßen nicht ganz einfach umzusetzen) auf allen Systemen, auf die diese Benutzergruppe nicht zugreifen soll, das per Zugriffsrechte verbieten.

    4. (und das einzige, was wirklich funktioniert) ein 3rd Party-Produkt mit benutzerbezogenem Regelwerk einsetzen.

    5. (funktioniert meistens auch, zumindest für eine Weile) den Leuten klar machen, dass wenn sie auf irgendwelche Systeme außer X, Y und Z zugreifen, jemand kommt und sie im Schlaf erdrosselt.

    Aber was ich nicht ganz verstehe: Was wollt ihr mit dieser Methode erreichen?


    Evgenij Smirnov

    msg services ag, Berlin -> http://www.msg-services.de
    my personal blog (mostly German) -> http://it-pro-berlin.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com

    In theory, there is no difference between theory and practice. In practice, there is.

    • Als Antwort markiert St_Marcel Donnerstag, 8. September 2016 07:15
    Mittwoch, 7. September 2016 21:01
  • Zugegebener Maßen, war Securitygroup filtering respektive Zielgruppenaddressierung, so knapp vor Feierabend etwas zu kurz gegriffen... ():-)

    In Richtung Evgenijs "2" kreisten auch gerade meine Gedanken:

    • Firewall-Regeln per GPO im Computer-Kontext setzten, aber nicht aktivieren
    • bei der einzuschränkenden Usergruppe per Log-On und Log-Off Skript, die entsprechenen Regeln aktivieren/deaktivieren (notwendige Credentials als Secure-String übergeben)

    Abgesehen von "nicht schön" - hab ich was übersehen?

    Gruß TechnikSC885


    PS: wobei mir persönlich "5" auch sehr gut gefällt ;)

    • Bearbeitet TechnikSC885 Mittwoch, 7. September 2016 22:31 PS
    • Als Antwort markiert St_Marcel Donnerstag, 8. September 2016 07:15
    Mittwoch, 7. September 2016 21:24
  • Guten Morgen zusammen!

    Zu diesem traurigen Schluss bin ich mit einem befreundeten Sysadmin nach diversen Kalthopfengetränken gestern Abend auch gekommen. Es ist einfach nicht vorgesehen. ILT, WMI-Filter etc. können auch erst angewendet werden, wenn das Kind bereits in den Brunnen gefallen ist. Die einzige dreckige und reudige Lösung, auf die wir gekommen sind, ist so ziemlich das, was Evgenij auch schon geschrieben hat. In unserem Fall:

    1. Lokalen Serviceaccount mit entsprechenden Rechten erzeugen.
    2. PS-Skript mit Aktivierung/Deaktivierung entsprechender Regeln schreiben
    3. Via Logon/Logoff-Skript Gruppenzugehörigkeit prüfen und jenachdem das PS-Skript mit secured Creds im Userkontext des Srvaccs ausführen. Bei Logoff die Regeln wieder außer Kraft setzen.

    Das ist aber eine ziemlich dreckige Lösung wie ich finde und ich möchte diese Maßnahmen eigentlich nicht ergreifen. Gerade denke ich über Vorschlag 5 von Evgenji nach :D

    Um deine Frage zu beantworten, wofür der ganze Spaß ist: Bei der angesprochenen User-Gruppe handelt es sich um Studenten, deren Prüfungsleistung darin besteht mit der Software zu arbeiten und ein Modell zu entwickeln. Wir wollen verhindern, dass die Arbeitsdateien in irgendeiner Weise mit von Außen erreichbar sind, manipuliert oder unter den Studenten ausgetauscht werden können. Ich bin hier gerne für andere Lösungsvorschläge offen!

    Ansonsten möchte ich euch allen für eure Antworten danken! Es gibt nicht für jedes Probleme eine einfache und schöne Lösung.

    • Als Antwort markiert St_Marcel Donnerstag, 8. September 2016 07:20
    Donnerstag, 8. September 2016 07:15
  • > Die Firewall müsste "Benutzer" verstehen, aber das tut die MS eigene FW
    > nicht.
     
    Doch, tut sie mit IPSec... Und das geht einfacher als man gemeinhin denkt.
     
    Freitag, 9. September 2016 13:19