AD-Gruppenmitglieder an Datenbank berechtigen

[Maverick1302 0]

Hi,

 

ich hoffe ihr könnt mir helfen. Ich habe das Problem, dass wir Benutzer per AD-Gruppe an einer SQL-Serverdatenbank berechtigt haben, die Abarbeitung von diversen Abfrage über eine Anwendung aber ewig dauert, wenn die Benutzer über eine AD-Gruppe an der Datenbank berechtigt wurden. Deshalb möchte ich nun die Benutzer möglichst einfach einzeln an der Datenbank berechtigen.

Es müsste doch möglich sein, per Script, die AD-Gruppe auszulesen, nachzuschauen, ob die Benutzer im SQL-Server und der Datenbank bereits existieren und wenn nicht, diese entsprechend anzulegen und an der Datenbank zu berechtigen. Weiß jemand, wie ich so etwas bewerkstelligen kann?

[Dukel 457]

Hast du es schon getestet, ob es dann schneller ist?

[NilsK 2.969]

Moin,

 

ich wage auch zu bezweifeln, dass daraus eine Beschleunigung resultiert. Geprüft wird, ob das Access Token des Users die nötigen Einträge enthält, die in den Berechtigungen auftauchen. Das macht praktisch keinen Unterschied, ob die betreffende SID die des Users ist oder einer der Gruppen, denen er angehört. Dafür hätte man bei deinem Ansatz den Nachteil, dass die Pflege der Berechtigungen sehr aufwändig wird.

 

Gruß, Nils

 

[Maverick1302 0]

Wir haben es getestet. Wenn wir einen Benutzer herauspicken und als Windows-Benutzer in der Datenbank anlegen, ist der entsprechende Vorgang in 3 Sekunden erledigt. Wird der Benutzer wieder herausgenommen und nur über die Gruppenmitgliedschaft am SQL Server berechtigt, dauert der Vorgang 12-15 Sekunden.

[NilsK 2.969]

Moin,

 

das überrascht - und es sollte m.W. so nicht sein. Gibt es Besonderheiten in der Umgebung, sind z.B. die User in sehr vielen Gruppen Mitglied? Finden evtl. innerhalb der Datenbank eigene Abfragen der Berechtigungen statt, die am normalen Windows-Berechtigungssystem vorbeigehen?

 

Gruß, Nils

 

[Maverick1302 0]

Ja, die Benutzer sind Mitglied in vielen anderen Gruppen, das scheint allerdings keine Auswirkungen zu haben. Wir haben einen Testuser aus allen anderen Gruppen herausgenommen und damit getestet und konnten das gleiche Verhalten beobachten.

Das Verfahren selbst hat eine eigene Benutzerverwaltung. Es kann sein, dass hier innerhalb der Anwendung noch Berechtigungsabfragen laufen.

Der Hersteller der Anwendung empfiehlt uns, die ODBC-Verbindung über einen festen SQL-Server Benutzer herzustellen. Dann würde das Performanceproblem nicht mehr auftreten, wir könnten aber auch nicht den Benutzer identifizieren, der gerade dabei ist, die Datenbank übermäßig zu belasten. Deswegen würde ich gerne den Umweg über ein entsprechendes Script gehen, wenn das möglich ist.

 

[NilsK 2.969]

Moin,

 

bevor ich so eine Umstellung machte, überprüfte ich noch näher die Zusammenhänge. So wäre es sinnvoll, sich für beide Szenarien die Ausführungspläne anzusehen. Das kann Hinweise geben, aus welcher Richtung die Performanceprobleme kommen.

 

Misstrauisch macht mich die Aussage des Herstellers. Wenn er empfiehlt, die ODBC-Verbindung (wirklich ODBC? Das ist Technik der Neunziger ...) über einen festen User herzustellen, verliert ihr nicht nur die Identifikation des Users, sondern effektiv auch sämtliche Windows-Berechtigungen - es wäre dann ja immer derselbe User. Das wiederum deutet darauf hin, dass die Datenbank tatsächlich an Windows vorbei die Berechtigungen überprüft. Das ist jetzt nur Spekulation, aber wenn es so wäre, wäre es weitab jeder Best Practice. In dem Fall wäre es ein ausgesprochen schmutziger Workaround, auf Userberechtigungen umzustellen - die Nachteile liegen ja auf der Hand.

 

Gruß, Nils

 

[Maverick1302 0]

Ja, definitv ODBC über den zum SQL-Server passenden Native Client.

Wie kann ich mir diesen Ausführungsplan anzeigen lassen. Über eine Abfrage geht es ja nicht, da ich die Programminternen Abfragen nicht kenne.

PS. Wir verwenden in diesem Fall noch SQL Server 2012.

bearbeitet 11. September 2018 von Maverick1302

[NilsK 2.969]

Moin,

 

so: https://www.google.de/search?q=sql+server+execution+plan

 

In deinem Fall würde ich aber auch noch mal mit dem Hersteller sprechen, ob die Vermutung bezüglich der Berechtigungsprüfung im Anwendungscode zutrifft. Mit "echter" Windows-Authentisierung kann es zu solchen Phänomenen eigentlich nicht kommen.

 

Gruß, Nils

 

[magheinz 110]

Am 10.9.2018 um 16:48 schrieb NilsK:

Das wiederum deutet darauf hin, dass die Datenbank tatsächlich an Windows vorbei die Berechtigungen überprüft. Das ist jetzt nur Spekulation, aber wenn es so wäre, wäre es weitab jeder Best Practice.

Das ist gängige Praxis aus verschiedenen Gründen. Einer wäre das eine Software auch mit anderen Datenbanksystemen laufen soll, ein anderer wäre das die Software unabhängig von einer Windowsauthentifizierung funktionieren soll.

Mir ist auch keine Software bekannt die das anders macht was nicht bedeutet das es solche Software gibt. Im Enterprisesegment dürfte das aber eher selten sein.

[NilsK 2.969]

Moin,

 

OK, vielleicht anders formuliert: So ein Verfahren ist weitab von dem, was Windows dafür an Mechanismen und Optimierungen hat und vermutlich das am wenigsten effiziente Vorgehen - wie man im konkreten Fall ja sieht, sofern die Spekulation zutrifft.

 

Es gibt durchaus zahlreiche SQL-gestützte Anwendungen, die direkt die vorgesehenen Mechanismen nutzen. Es gibt dafür im System ja auch eine ganze Reihe Hilfestellungen. Portabilität mag ein Argument in die andere Richtung sein, aber sie erzeugt in so einem Fall dann eben erhebliche Kosten - Vorgänge um das Fünffache verlängern, weil man eine Kompatibilitätsschicht einsparen will, ist ganz gewiss nicht Best Practice. Nur weil es viele machen, ist es ja nicht gut.

 

Ich ergänze noch: Diese Betrachtungen helfen dem TO erst mal wenig, schließlich hat er die Software ja nicht gebaut. Aber es wäre lohnenswert, den Hersteller genau danach zu fragen, um die Handlungsoptionen einzuschätzen. Vielleicht geht erst mal kein Weg daran vorbei, die Berechtigungen selbst aufzulösen, aber vielleicht gibt es auch einen besseren Weg, das Problem anzugehen. Wir spekulieren ja hier schließlich nur.

 

Gruß, Nils

 

bearbeitet 12. September 2018 von NilsK
Ergänzung, damit die Diskussion dem TO auch was bringt

[magheinz 110]

Blöde Frage, aber laufen diese Mechanismen auch mit SQL wenn man den unter Linux laufe lässt?

Ich bin derzeit nicht im Büro, sonst würde ich mir das mal näher anschauen(bin da schon als Beta-Tester dabei)...

[NilsK 2.969]

Moin,

 

kann ich dir nicht sagen. Ist aber an der Stelle auch egal: Offenbar gibt es ja etwas in der Applikation, das die Windows-Berechtigungen (bzw. Gruppenmitgliedschaften) ausliest, das muss ja ohnehin an Windows angepasst sein. Auf einem Linux-System bräuchte man dann eine andere Logik dafür - Portabilität erfordert nun mal in der Regel Anpassungen im Detail.

 

Wenn man der Meinung ist, das so machen zu müssen, wäre es aber vielleicht schlauer, dies einmal beim Verbindungsaufbau zu erledigen (wenn der ein paar Sekunden länger läuft, ist das meist egal) und nicht erst beim Zugriff jedes Mal mit viel Zeitaufwand aufzulösen. Speichert man das Ergebnis der Auflösung einmal in einer Tabelle, dann kann man auf die schnell zugreifen. Effektiv würde man das Access-Token-Prinzip von Windows nachbilden und nach diesem Schritt die Vorteile dieses Mechanismus nutzen.

 

Bleibt aber weiterhin Spekulation, sodass das für den Thread hier auch nicht weiterhilft.

 

Gruß, Nils

 

[Dukel 457]

Unter Linux funktioniert das mit dem MSSQL Server mittels Kerberos genau so. Hier kann man AD Benutzer nutzen.

[magheinz 110]

Gut zu wissen. Dann werde ich demnächst mal damit rumspielen. 

Seit der betaphase läuft der nämlich zum rumprobieren eh auf meinem Notebook.