none
Bestimmte User aus GPP Laufwerkszuweisung automatisiert entfernen RRS feed

  • Frage

  • Hallo zusammen,

    im vergangenen halben Jahr habe ich damit angefangen unsere IT-Umgebung im Bezug auf Laufwerkszuweisungen von KiXtart Anmeldeskripten auf GroupPolicy Preferences umzustellen.

    Nun stellt sich mir die folgende Frage.

    Gibt es eine Möglichkeit ein konkretes Benutzerkonto aus mehreren Laufwerkszuweisungen (speziell der "Zielgruppenadressierung" aus den "gemeinsamen Optionen") dieser Laufwerkszuweisungen zu entfernen?

    Vielen Dank schonmal für eure Hilfe

    schöne Grüße

    tkisc2

    Freitag, 16. Februar 2018 06:52

Antworten

  • Hallo,

    ich verstehe nicht ganz. Simpel betrachtet hast Du doch für jedes Laufwerksmapping eine Sicherheitsgruppe, wenn Du das über Zielgruppenaddressierung steuerst. Wieso sollten jetzt Benutzer das Laufwerk nicht bekommen, wenn diese der Gruppe angehören? Pack die doch dann einfach aus der Gruppe raus.

    Was genau benutzt Du für Gruppen? Das hört sich stark nach "Abteilungs-Gruppen" an. Würde ich von absehen, zumindest beim Laufwerksmapping, da die Dateizugriffe stark individuell sind. 

    Wir machen das so: DFS, zugriffsbasierte Aufzählung, Gruppen verschachtelt, für jeden Ordner im DFS eine Gruppe, jeweils zwei Gruppen für jeden Unterordner des Ordner im DFS (Lesen, Schreiben). Ein GPO für das Laufwerksmapping. Eine Read-Gruppe auf den Subnamespace, wo die o.g. Gruppen Mitglied sind. Somit sieht jeder nur das, was er berechtigt hat.

    Um viele Sicherheitsgruppen kommst Du halt nicht herum, wenn Du eine relativ große Umgebung hast.

    MfG, Jannik

    • Als Antwort markiert tkisc2 Freitag, 16. Februar 2018 11:42
    Freitag, 16. Februar 2018 08:34
  • Hallo,

    Jannik du hast es erfasst. ich benutze Abteilungsgruppen, teilweise auch Fachlich bezogenene abteilungsübergreifende Gruppen, die Zugriff auf mehrere Laufwerke gleichzeitig garantieren. Wenn ich euch jetzt richtig verstehe, ist der Vorschlag anstelle dieser bislang verwendeten Gruppen, für die Laufwerkszuweisung pro Laufwerk jeweils eine Sicherheitsgruppe zu erstellen und die User dementsprechend nur den Gruppen zuzuordnen, die den jeweilig zuzuweisenden Laufwerken zugeordnet sind. In den Zielgruppenadressierungen der Laufwerkszuweisungen wird dann nur noch die Mitgliedschaft in dieser einen Sicherheitsgruppe geprüft.

    Habe ich das so richtig verstanden? Wenn ja finde ich diese Lösung genial :)

    schöne Grüße

    tkisc2


    • Bearbeitet tkisc2 Freitag, 16. Februar 2018 09:52
    • Als Antwort markiert tkisc2 Freitag, 16. Februar 2018 11:42
    Freitag, 16. Februar 2018 09:51
  • auch wieder richtig. So würdest Du halt einem Rechte-Rollen-Konzept näher kommen:

    User hat die Rolle "Zugriff auf Marketing über Buchstabe R" und bekommt somit neben dem Mapping auch den Zugriff, dadurch dass die Rolle Mitglied ist in "Zugriff auf Marketing".

    Auf lange Sicht ist das Festhalten an vielen Laufwerksbuchstaben pro Benutzer allerdings nicht ratsam. Viel besser hat sich ein "Einsprungspunkt" mit DFS dahinter und ABE darunter bewährt. Aber da muss man einige Gräben in den Köpfen überwinden.


    Evgenij Smirnov

    I work @ msg services ag, Berlin -> http://www.msg-services.de
    I blog (in German) @ http://it-pro-berlin.de
    my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
    Exchange User Group, Berlin -> https://exusg.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 tkisc2 Freitag, 16. Februar 2018 11:56
    • Tag als Antwort aufgehoben tkisc2 Freitag, 16. Februar 2018 11:57
    • Als Antwort markiert tkisc2 Freitag, 16. Februar 2018 11:57
    Freitag, 16. Februar 2018 11:46

Alle Antworten

  • Moin,

    nun, da Du vernünftigerweise die Zielgruppenadressierung über Gruppen gemacht hast, brauchst Du den fraglichen User nur aus diesen Gruppen zu entfernen. Ist es keine Option, dann kannst Du natürlich in der Zielgruppenadressierung auch den konkreten User als "ist nicht" angeben.


    Evgenij Smirnov

    I work @ msg services ag, Berlin -> http://www.msg-services.de
    I blog (in German) @ http://it-pro-berlin.de
    my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
    Exchange User Group, Berlin -> https://exusg.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.

    Freitag, 16. Februar 2018 07:00
  • Hallo,

    vielleicht habe ich mich etwas unkonkret ausgedrückt. Ich spreche von einer IT-Umgebung mit ca. 1600 Usern. Mein Problem besteht schlichtweg in der Menge der einem User zugeordneten Netzlaufwerke. Scheidet ein Mitarbeiter aus dem Dienst aus, muss ich alleine aus Performancegründen den User aus der Zielgruppenadressierung entfernen. Selbst wenn dieser User nur 3 oder 4 Netzlaufwerke zugewiesen bekommt, artet dies in riesigen Zeitaufwand aus. Besonders, da ich ja nicht explizit anhand des Benutzerkontos nachvollziehen kann, welche Netzlaufwerke diesem zugewiesen sind.

    Edit: Habe nicht ganz deutlich gelesen... Ja ich habe natürlich mit Sicherheitsgruppen gearbeitet, allerdings ergibt sich in meiner Umgebung eine Vielzahl von Usern die Trotz Zugehörigkeit zu einer bestimmten Gruppe ein normalerweise darüber zugewiesenes Laufwerk nicht erhalten dürfen, daher stehen auch viele einzelne  User "ist nicht" .. Zuweisungen drin... Wenn ich das über Sicherheitsgruppen mache habe ich nachher eine Unmenge an Sicherheitsgruppen :(

    Daher meine Frage nach einer automatisierten Möglichkeit?

    schöne Grüße

    tkisc2


    • Bearbeitet tkisc2 Freitag, 16. Februar 2018 07:12
    Freitag, 16. Februar 2018 07:07
  • Moin,
    für die Zukunft: über Gruppen adressieren
    für den Augenblick: inventarisieren, wer was gemappt bekommt. Oder Du schaust Dir die Sachen von SDM Software an, die können das rausziehen. Oder Du skriptest die COM-Objekte der GPMC

    Evgenij Smirnov

    I work @ msg services ag, Berlin -> http://www.msg-services.de
    I blog (in German) @ http://it-pro-berlin.de
    my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
    Exchange User Group, Berlin -> https://exusg.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.


    Freitag, 16. Februar 2018 07:23
  • Hallo,

    vielen Dank erstmal für deine schnelle Antwort. Ist es denn eine organisatorisch kluge Lösung Sicherheitsgruppen für jedes Laufwerk zu erstellen, das jemand nicht zugewiesen bekommt?

    Dann erhalte ich im worst case ja eine zusätzliche Anzahl von Sicherheitsgruppen in Höhe der Anzahl der vorhandenen Laufwerkszuweisungen. Gibt es da keine effizientere Lösung?

    schöne Grüße

    tkisc2

    Freitag, 16. Februar 2018 07:56
  • Moin,

    irgendwie reden wir aneinander vorbei. Natürlich sollen keine Gruppen "Bekommt NICHT das LW R:" erstellt werden. Vielmehr sollte man beim Item Level Targeting ausschließlich mit Gruppen a la "BEKOMMT das LW R: vom Server FS01" arbeiten. Dann entsprechen idealerweise die gemappten Laufwerke den Mitgliedschaften in den Gruppen. Und mehr als 25 Gruppenmitgliedschaften pro User können bzw. sollten es ja nicht werden ;-) 

    Jetzt hast Du, wenn ich es richtig verstehe, so gemacht, dass Du das Single Item Targeting nicht per Gruppe, sondern per User gemacht hast, und somit kannst Du im Nachhinein nicht mehr sagen, welche Laufwerke User X aus welchen GPP-Objekten gemappt bekommt. Das kannst Du entweder "im Feld" inventarisieren und gleich in Gruppenmitgliedschaften ummünzen, oder Du musst einen Weg finden, die GPP-Einstellungen für da Item Level Targeting maschinell auszulesen.


    Evgenij Smirnov

    I work @ msg services ag, Berlin -> http://www.msg-services.de
    I blog (in German) @ http://it-pro-berlin.de
    my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
    Exchange User Group, Berlin -> https://exusg.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 tkisc2 Freitag, 16. Februar 2018 11:42
    • Tag als Antwort aufgehoben tkisc2 Freitag, 16. Februar 2018 11:42
    Freitag, 16. Februar 2018 08:33
  • Hallo,

    ich verstehe nicht ganz. Simpel betrachtet hast Du doch für jedes Laufwerksmapping eine Sicherheitsgruppe, wenn Du das über Zielgruppenaddressierung steuerst. Wieso sollten jetzt Benutzer das Laufwerk nicht bekommen, wenn diese der Gruppe angehören? Pack die doch dann einfach aus der Gruppe raus.

    Was genau benutzt Du für Gruppen? Das hört sich stark nach "Abteilungs-Gruppen" an. Würde ich von absehen, zumindest beim Laufwerksmapping, da die Dateizugriffe stark individuell sind. 

    Wir machen das so: DFS, zugriffsbasierte Aufzählung, Gruppen verschachtelt, für jeden Ordner im DFS eine Gruppe, jeweils zwei Gruppen für jeden Unterordner des Ordner im DFS (Lesen, Schreiben). Ein GPO für das Laufwerksmapping. Eine Read-Gruppe auf den Subnamespace, wo die o.g. Gruppen Mitglied sind. Somit sieht jeder nur das, was er berechtigt hat.

    Um viele Sicherheitsgruppen kommst Du halt nicht herum, wenn Du eine relativ große Umgebung hast.

    MfG, Jannik

    • Als Antwort markiert tkisc2 Freitag, 16. Februar 2018 11:42
    Freitag, 16. Februar 2018 08:34
  • Hallo,

    Jannik du hast es erfasst. ich benutze Abteilungsgruppen, teilweise auch Fachlich bezogenene abteilungsübergreifende Gruppen, die Zugriff auf mehrere Laufwerke gleichzeitig garantieren. Wenn ich euch jetzt richtig verstehe, ist der Vorschlag anstelle dieser bislang verwendeten Gruppen, für die Laufwerkszuweisung pro Laufwerk jeweils eine Sicherheitsgruppe zu erstellen und die User dementsprechend nur den Gruppen zuzuordnen, die den jeweilig zuzuweisenden Laufwerken zugeordnet sind. In den Zielgruppenadressierungen der Laufwerkszuweisungen wird dann nur noch die Mitgliedschaft in dieser einen Sicherheitsgruppe geprüft.

    Habe ich das so richtig verstanden? Wenn ja finde ich diese Lösung genial :)

    schöne Grüße

    tkisc2


    • Bearbeitet tkisc2 Freitag, 16. Februar 2018 09:52
    • Als Antwort markiert tkisc2 Freitag, 16. Februar 2018 11:42
    Freitag, 16. Februar 2018 09:51
  • Ja, richtig.

    Und diese Gruppen können ja auch in die jetzigen Abteilungsgruppen gesteckt werden, um die Berechtigungen auf den Laufwerken beibehalten zu können.


    Evgenij Smirnov

    I work @ msg services ag, Berlin -> http://www.msg-services.de
    I blog (in German) @ http://it-pro-berlin.de
    my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
    Exchange User Group, Berlin -> https://exusg.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.

    Freitag, 16. Februar 2018 10:19
  • Super. Das Integrieren in die vorhandenen Gruppen ist aber doch nicht zwingend notwendig. Oder liege ich da falsch? Die Berechtigungen ändern sich ja nicht. Und die veränderte Zuweisung der Laufwerke wirkt sich ja nicht auf die Überprüfung der Zugriffsrechte aus.

    Die Änderung ist wahrscheinlich ratsam, der Übersichtlichkeit halber aber nicht zwingend erforderlich. So lautet jedenfalls meine Denkweise?

    schöne Grüße

    tkisc2

    Freitag, 16. Februar 2018 10:43
  • auch wieder richtig. So würdest Du halt einem Rechte-Rollen-Konzept näher kommen:

    User hat die Rolle "Zugriff auf Marketing über Buchstabe R" und bekommt somit neben dem Mapping auch den Zugriff, dadurch dass die Rolle Mitglied ist in "Zugriff auf Marketing".

    Auf lange Sicht ist das Festhalten an vielen Laufwerksbuchstaben pro Benutzer allerdings nicht ratsam. Viel besser hat sich ein "Einsprungspunkt" mit DFS dahinter und ABE darunter bewährt. Aber da muss man einige Gräben in den Köpfen überwinden.


    Evgenij Smirnov

    I work @ msg services ag, Berlin -> http://www.msg-services.de
    I blog (in German) @ http://it-pro-berlin.de
    my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
    Exchange User Group, Berlin -> https://exusg.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 tkisc2 Freitag, 16. Februar 2018 11:56
    • Tag als Antwort aufgehoben tkisc2 Freitag, 16. Februar 2018 11:57
    • Als Antwort markiert tkisc2 Freitag, 16. Februar 2018 11:57
    Freitag, 16. Februar 2018 11:46
  • OK. Alles klar.

    Dann setze ich mich da kommende Woche mal dran. Vielen Dank euch zwei.

    Schönes Wochendende

    tkisc2

    Freitag, 16. Februar 2018 11:59
  • Moin,

    ich habe nachgeschaut. Die GPP für Drive Maps sind als gutartige XML-Dateien abgespeichert. D.h. mit etwas Skripten kriegst Du den Kram inventarisiert, und mit etwas Glück findest Du dazu auch ein fertiges Skript. Die XML heißen jeweils "\\dom.ain\SYSVOL\dom.ain\Policies\{GUID}\User\Preferences\Drives\Drives.xml"

    Hier ein schneller Snippet:

    $username = "SRCDOM\ab"
    Get-ChildItem "\\srcdom.lab\SYSVOL\srcdom.lab\Policies" -Directory | foreach {
        $gpo = (Get-GPO -Guid ($_.Name)).DisplayName
        $xmlfile = "$($_.FullName)\User\Preferences\Drives\Drives.xml"
        if (Test-Path $xmlfile) {
            foreach ($drv in ([xml](Get-Content $xmlfile)).Drives) {
                if ($drv.Drive.Filters.FilterUser.Name -like $username) {
                    Write-Host "User $username bekommt Laufwerk $($drv.Drive.name) aus der Policy $gpo"
                }
            }
        }
    }


    Evgenij Smirnov

    I work @ msg services ag, Berlin -> http://www.msg-services.de
    I blog (in German) @ http://it-pro-berlin.de
    my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
    Exchange User Group, Berlin -> https://exusg.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.

    Freitag, 16. Februar 2018 20:27
  • Senf dazu :)

    Settings in GPOs finden: https://activedirectory.ncsu.edu/advanced-topics/scripting-center/gpo-setting-search-powershell-example/

    Und als best Practice: Ersetze ALLE Laufwerkzuordnungen durch ein einziges DFS-Root. Aktiviere dort ABE und stecke alle bisherigen Laufwerke in Unterverzeichnisse mit entsprechenden Gruppen. Damit sieht jeder nur noch das, in dessen Gruppen er ist, und Du mußt nie wieder Zuordnungen nachpflegen, sondern nur noch Gruppenmitgliedschaften (aber das mußt Du ja eh, oder? :-))

    Samstag, 17. Februar 2018 16:40
    Beantworter
  • Und als best Practice: Ersetze ALLE Laufwerkzuordnungen durch ein einziges DFS-Root. Aktiviere dort ABE und stecke alle bisherigen Laufwerke in Unterverzeichnisse mit entsprechenden Gruppen. Damit sieht jeder nur noch das, in dessen Gruppen er ist, und Du mußt nie wieder Zuordnungen nachpflegen, sondern nur noch Gruppenmitgliedschaften (aber das mußt Du ja eh, oder? :-))

    Schrub ich oben auch schon ;-)

    Evgenij Smirnov

    I work @ msg services ag, Berlin -> http://www.msg-services.de
    I blog (in German) @ http://it-pro-berlin.de
    my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
    Exchange User Group, Berlin -> https://exusg.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.

    Samstag, 17. Februar 2018 18:27