Technischer Blog

Nach der Vorstellung des neuen Berechtigungskonzepts sind sich im Gespräch mit dem Kunden in der Regel alle Beteiligten einig, es ab jetzt anders und besser zu machen als bisher. Die Realität holt einen dann aber oft schneller ein als einem lieb ist, denn häufig scheitert es krachend an der Umsetzung bzw. dem "Leben" des neuen Berechtigungskonzept. Das mag auf der einen Seite bei dem ein-oder anderem Beteiligten, an mangelndem Verständnis der Notwendigkeit liegen, in jedem Falle spielt der Faktor Zeit eine Rolle. Es ist ja auch nur zu bequem "einfach" einen SQL-Login zu erstellen, um den Kollegen einen Zugang zum SQL Server (am besten auch noch mit SA-Rechten! ;) ) zu ermöglichen. Oder es wird aufgrund eines fehlendes Konzepts ein Active-Directory Account direkt auf der Datebank-Instanz berechtigt. In jedem Falle verliert man so in kürzester Zeit den Überblick wer eigentlich was darf und wo eigentlich. Systemsicherheit sieht anders aus!

Ein wiederkehrendes Szenario bei Auftraggebern ist, das neue Berechtigungskonzept auf neuen SQL Server Instanzen umzusetzen, und die bestehenden Instanzen zu bereinigen. Oft genug verändern sich AD-Accounts, werden gelöscht oder der Accountname ändert sich. Diese Änderung spiegelt sich jedoch nicht auf der SQL Server Instanz wieder, das heißt die Accounts bleiben dort bestehen und der Name ändert sich nicht entsprechend. Um hier wieder etwas Ordnung zu haben, empfiehlt sich ein Abgleich dieser Accounts mit dem Active Directory, anhand der SID. Für diesen Zweck habe ich die folgende Lösung hier (Externer Link) implementiert. Das SQL zur Auswertung der AD-Accounts wird auf der SQL Server Instanz ausgeführt und als CSV gespeichert. Anschliessend führt man das Powershell-Script aus, um die jeweilige SID gegen das Active-Directory zu prüfen. So wird es möglich, in einer effizienten Art und Weise die Logins einer SQL Server Datenbankinstanz zu bereinigen.