MS SQL SELECT-Recht verweigert obwohl es erteilt ist

[Auge]

Hallo

hast Du schonmal den SQL Server durchgestartet? Zuweilen cached der Bursche Rechte und ist deshalb anderer Meinung als das AD.

Und es gibt nicht nur GRANT, sondern auch DENY. Ein DENY hat Vorrang vor einem GRANT. D.h. wenn der User einen SELECT GRANT hat, aber auch einen SELECT DENY, dann zieht der. Wie man die effektiven Rechte eines Securables zusammenträgt, weiß ich allerdings nicht. Bin zu Hause, habe keinen SQL Server da.

Du hast mich auf die richtige Spur geführt. Dieser eine Benutzer ist, anders als seine Mitstreiter in der Gruppe, deren Rechte ich nach vorne, hinten, oben, unten, rechts und links geprüft habe, noch in einer anderen Gruppe (warum ich ihn auch immer dort hineingesteckt habe).

Mit der Abfrage aus der akzeptierten Lösung dieser Frage auf StackOverflow habe ich die Rechte des Benutzers mit denen anderer Benutzern der selben Gruppe als auch seine Rechte in verschiedenen Gruppen miteinander verglichen. Wie zu erwarten, stimmten die rechte verschiedener Benutzer der selben Gruppe miteinander überein. Seine Rechte in verschiedenen Gruppen waren aber an einer Stelle unterschiedlich

| DatabaseUserName | Role | PermissionType | PermissionState |---| | abc | Gruppe A | ALTER | DENY | abc | Gruppe A | CONTROL | GRANT | abc | Gruppe A | DELETE | DENY | abc | Gruppe A | INSERT | DENY | abc | Gruppe A | REFERENCES | GRANT | abc | Gruppe A | SELECT | GRANT | abc | Gruppe A | TAKE OWNERSHIP | DENY | abc | Gruppe A | UPDATE | GRANT | abc | Gruppe A | VIEW CHANGE TRACKING | DENY | abc | Gruppe A | VIEW DEFINITION | GRANT | abc | Gruppe B | ALTER | DENY | abc | Gruppe B | CONTROL | DENY | abc | Gruppe B | DELETE | DENY | abc | Gruppe B | INSERT | DENY | abc | Gruppe B | REFERENCES | GRANT | abc | Gruppe B | SELECT | GRANT | abc | Gruppe B | TAKE OWNERSHIP | DENY | abc | Gruppe B | UPDATE | GRANT | abc | Gruppe B | VIEW CHANGE TRACKING | DENY | abc | Gruppe B | VIEW DEFINITION | GRANT

Der einzige Unterschied zwischen den Berechtigungen der Gruppen A und B ist CONTROL. Die Berechtigung wird für Gruppe A erteilt aber für Gruppe B nicht. Nachdem ich den Benutzer aus Gruppe B herausgeholt habe, kann auch er wieder auf die fragliche Tabelle zugreifen.

Danke für deinen Denkanstoß.

Jetzt muss ich nur noch einmal darüber nachdenken, warum ich den Benutzer in die Gruppe B gesteckt habe, warum ich dieser die Berechtigung CONTROL vorenthalten habe und ob die Gruppe überhaupt noch benötigt wird (ist mMn eine mittlerweile obsolete Altlast, aber das benötigt Rücksprache).

[edit]
Fürs Archiv:

• Benutzer in Gruppe B: er war da zu recht
• vorenthaltenes Recht: Fehlkonfiguration
• Existenz der Gruppe: wird weiterhin benötigt

[/edit]

Danke noch einmal.

Tschö, Auge