Windows ACL | Gruppe deny, aber User hat dennoch Zugriff.

[tschulian]

Hallo,
bislang war ich der Meinung, dass wenn ein User Mitglied mehrerer Gruppe ist, der Zugriff auf einen Ordner/Datei verwehrt wird, wenn er sich in einer Gruppe befindet, die für den Zugriff blockiert wurde - auch wenn er unter Umständen in mehreren Gruppen Mitglied.

Szenario:

User testertoni ist in folgenden AD Gruppen
Gruppe_Steuerungskreis
Gruppe_Angestellte
usw.

Der Folder _Geheimes hat folgende DENYS:
Gruppe_Angestellte
Gruppe_Projektleiter
... usw.

Dadurch das für den Folder _Geheimes ein DENY für Gruppe_Angestellte eingestellt ist, sollte doch der User testertoni keinen Zugriff mehr haben.
Ich habe zum testen einen neuen User  newuser erstellt und ihn in die exakt die selben Gruppen und sogar Mailverteiler wie testertoni gesteckt.
newuser kann wie zu erwarten auf _Geheimes NICHT zugreifen, testertoni aber schon - obwohl diese in den selben AD Gruppen sind.

Ich weiß wirklich nicht weiter......

Bearbeitet 25. April 2019 von tschulian

[tschulian]

Gefixed!

Neben mir gibt es noch einen User, der einen Domänen-Admin Account (testertoniadmin) besitzt....

Der betroffene User (testertoni) hatte - wie auch immer das passieren konnte - hier seinen Domain Admin User (testertoniadmin) für den \\fileserver hinterlegt:



Dadurch wurden alle \\fileserver Freigaben, die per Logon Script eingebunden wurden, unter dem Domain Admin User gemappt, der dann natürlich überall Rechte hat.
Ich weiß nicht warum ich überhaupt in die Anmeldeinformationsverwaltung geschaut habe, aber das war des Rätels Lösung und erklärt auch, wieso ein User, der 1:1 in den selben Gruppen wie der betroffene User war eben keinen Zugriff auf den Ordner _Geheimes hatte.

Sorry...

Bearbeitet 26. April 2019 von tschulian

[_n4p_]

Hallo,

in dem Fall müsste man doch in der Computerverwaltung unter Freigaben und offene Sitzungen den "falschen" Benutzer finden können?

[Maniska]

Doofe Frage, aber warum arbeitet man mit dem Recht "Verweigern" wenn man einerseits mit unterbrochener Vererbung und "gar nicht erst das Recht geben" arbeiten könnte?

Mir wurde von allen Seiten eingebleut, niemals mit Verweigern zu arbeiten, da das die Fehlersuche unendlich verkompliziert.

[tschulian]

Wir arbeiten mit DENYS weil wir die Rechte zentral über ein Excel Sheet gesteuert täglich prüfen und setzen bzw. entfernen wenn das Recht für einen User abgelaufen ist. Das Tabellenblatt in dem alle Rechte stehen, kann dann pivotiert werden und der Geschäftsleitung zur Prüfung ausgedruckt und übersichtlich vorgelegt werden.

Das Excel ist wiefolgt aufgebaut:
Account kann ein User oder eine Gruppe sein.
Date ist das Datum, bis wann das Recht gültig sein darf. (je nachdem ist isValid dann falsch oder wahr)




Das Log wenn etwas geändert wird sieht wiefolgt aus (bezieht sich nicht auf den Screenshot von oben):


 

Ganz am Ende das "outdated" ist der Grund, wieso eine Änderung (REMOVING oder ADDING) stattfand.
Hier steht bei ADDING z.B als Grund immer "missing in Filesystem". Da im Excel das Recht vorhanden ist, aber im Filesystem noch nicht, wird es eben dann hinzugefügt.

Die beiden Rechte hier wurden am 11.04 entfernt, weil diese Seit 11.04 nichtmehr gültig sind.

Das Tool haben wir selber in C# geschrieben und funktioniert wirklich super gut.

Bearbeitet 26. April 2019 von tschulian

[tschulian]

vor einer Stunde schrieb _n4p_:

Hallo,

in dem Fall müsste man doch in der Computerverwaltung unter Freigaben und offene Sitzungen den "falschen" Benutzer finden können?

Da hatte ich nicht reingeschaut. Guter Tipp! Vielen Dank! Beim nächsten Mal (was eigentlich nciht wieder vorkommen sollte) werde ich dran denken

Bearbeitet 26. April 2019 von tschulian

[Listener]

Die Vorgehensweise ein Excel-Sheet zu nutzen, damit man an die GL reporten kann, ist aber doch auch ein wenig komisch. Normalerweise reportet man aus bestehenden Systemen und entwickelt nicht etwas, mit dem man reporten kann, nur um daraus dann Änderungen in ein bestehendes System zu schreiben.

Wenn es funktioniert, schön und gut, aber Einarbeitungszeit für neue MA, Fehlersuche, Drittsystem anbinden, etc. dürfte damit erschwert werden.

[Maniska]

vor einer Stunde schrieb tschulian:

Wir arbeiten mit DENYS weil wir die Rechte zentral über ein Excel Sheet gesteuert täglich prüfen und setzen bzw. entfernen wenn das Recht für einen User abgelaufen ist.

Wir reden doch hier von einem ganz normalen Datengrab Filesever, auf dem User aus bestimmten Abteilungen in bestimmten Ordnern ihren Müll abladen ihre Dateien ablegen dürfen.

Wird bei euch einmal die Woche per Strohhalm ausgelost wer die nächsten Tage im Einkauf sitzt, Vertrieb macht... oder spielt ihr in der Mittagspause "Reise nach Jerusalem" und wer verliert, bei dem werden die Rechte neu ausgewürfelt?

Warum muss man täglich Berechtigungen anpassen???

[tschulian]

vor 2 Stunden schrieb Listener:

Die Vorgehensweise ein Excel-Sheet zu nutzen, damit man an die GL reporten kann, ist aber doch auch ein wenig komisch. Normalerweise reportet man aus bestehenden Systemen und entwickelt nicht etwas, mit dem man reporten kann, nur um daraus dann Änderungen in ein bestehendes System zu schreiben.

Wenn es funktioniert, schön und gut, aber Einarbeitungszeit für neue MA, Fehlersuche, Drittsystem anbinden, etc. dürfte damit erschwert werden.

Für unsere Zwecke war das die beste Lösung ohne auf 3rd Party Tools zurückzugreifen.

vor 2 Stunden schrieb Maniska:

Wir reden doch hier von einem ganz normalen Datengrab Filesever, auf dem User aus bestimmten Abteilungen un dBestimmten Ordnern ihren Müll abladen ihre Dateien ablegen dürfen.

Wird bei euch einmal die Woche per Strohhalm ausgelost wer die nächsten Tage im Einkauf sitzt, Vertrieb macht... oder spielt ihr in der Mittagspause "Reise nach Jerusalem" und wer verliert, bei dem werden die Rchte neu ausgewürfelt?

Warum muss man täglich Berechtigungen anpassen???

Mir gefällt deine Intention.

Es geht z.B um FreeLancer (die an verschiedenen Projekten arbeiten, und sehr unregelmäßig zu uns kommen, aber natürlich immer ihren AD Account wiederbekommen) die an sich auf Projektverzeichnisse keinen Zugriff haben und dann nur explizit für Projekt XY Zugriff bekommen sollen. Damit das entfernen der Rechte dann auch wirklich passiert, haben wir uns für diese automatisierung entschieden.

Täglich wird im Normalfall nichts angepasst. Freelancer haben immer 3 Monate zugriff auf ein Projekt. Falls Sie dann länger Zugriff brauchen müssen diese eben dann eine Mail an mich schicken, und bekommen erneut Zugriff. So stell ich sicher, dass es keine Schläferrechte gibt. Und ne Mail tut keinem Weh.

[Maniska]

Klingt immer noch verdammt umständlich.

Warum nicht z.B. Ablaufdatum im AD Konto setzen und jede Nacht per Skript alle abgelaufenene Konten aus allen Gruppen (außer Domain User) rauswerfen?

Dann gibt es für jedes Projekt eine eigene Berechtigungsgruppe im AD, und dort wird der Freelancer eingestopft wenn er wieder kommt, ohne Verweigern, ohne Schischi, einfach plain "du da Zugriff".

[Listener]

vor 21 Minuten schrieb tschulian:

Für unsere Zwecke war das die beste Lösung ohne auf 3rd Party Tools zurückzugreifen.

Das ist dennoch so "von hinten durch die Brust ins Auge"...

Mein Vorschlag wäre gewesen via PowerShell Skript die Rechte setzen (siehe @Maniska) und via Powershell einen Userreport erstellen, den man btw. dann auch sicherlich in ein GL-freundliches Format konvertieren kann. Eure Lösung hört sich sehr "gewachsen" an, meistens ein sehr tolles Zeichen