MS SQL SELECT-Recht verweigert obwohl es erteilt ist

[Auge]

Hallo

Ich bin heute auf ein merkwürdiges Problem in der Rechteverwaltung eines MS SQL Servers 2008 gestoßen.

Ich greife von einem MS Access Frontend aus auf Daten auf einem MS-SQL-Express-Server-2008 zu. Der Zugriffsberechtigungen werden über die Windows-Benutzer-Accounts (über Domänencontroller) geregelt. Jeder relevante Benutzer ist auch auf dem SQL-Server angelegt, und in Gruppen einsortiert, denen Rechte auf Tabellen, Views und Stored Procedures gewährt werden.

Heute meldete ein Benutzer, dass er ein Problem hat, wobei sich herausstellte, dass er auf eine Tabelle keinerlei Rechte mehr hat. Konkret wird der lesende Zugriff (SELECT-Berechtigung) verweigert. Auf diese Tabelle greift er nicht täglich zu, das Problem kann erst heute oder binnen etwa der letzten Woche aufgetreten sein. Auf alle anderen Tabellen vom SQL-Server kann er jedoch zugreifen. Alle anderen Mitglieder seiner auf dem SQL-Server eingerichteten Benutzergruppe haben auf alle Tabellen einschließlich der, mit der dieser eine Benutzer Probleme hat, Zugriff.

• Ich habe ihm als Einzelnutzer die Rechte für die Tabelle gewährt (aktualisieren, auswählen, einfügen), die auch seine Gruppe hat. => kein Erfolg
• Ich habe ihn aus der Gruppe entfernt und wieder hinzugefügt. => kein Erfolg
• Ich habe seinen SQL-Server-Benutzer aus der Gruppe entfernt, ihn gelöscht, dann einen neuen Account angelegt und ihn wieder der Gruppe zugewiesen. => kein Erfolg
• Ich habe eine andere VM mit seinem Windows-Account geöffnet und versucht auf die Tabelle zuzugreifen, um ein Problem mit seiner VM auszuschließen. => kein Erfolg

Es ist nur diese eine Tabelle, auf die er nicht zugreifen kann und ich habe absolut keine Idee, woran das liegen könnte.

Recherchen über Suchmaschinen fördern haufenweise Threads zutage, in denen von Problemen mit Access-basierten Tabellen, mit der Einrichtung von ODBC-Verbindungen oder allgemein der Rechteverwaltung auf einem MS-SQL-Server die Rede ist. Über so ein spezielles Problem wie meines, also erteilter und dennoch verweigerter Rechte, finde ich aber nichts. 😟 Das mag durchaus daran liegen, dass ich nicht die richtigen Suchbegriffe verwende. Ich wüsste aber auch nicht, welche es denn sein sollten.

Ist hier schon irgendwem soetwas oder etwas ähnliches passiert? Hat hier jemand passenden Lesestoff oder gar eine(n) Lösung(sansatz)?

Tschö, Auge

[Rolf B]

Hallo Auge,

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.

Rolf

[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