Schlagworte: berechtigungen

Berechtigungen auf Serverebene

Wenn man eine Datenbank auf einen anderen Server überträgt, werden die darin enthaltenen Berechtigungen mitgegeben. Für die Übertragung der Logins (mit Passwort) gibt es verschiedene Möglichkeiten. Was ist aber mit den Berechtigungen auf Serverebene?

Full story »

SSIS 2012 Remote Administrieren

Mit der Version SQL Server 2012 ist einiges sicherer geworden, aber nicht unbedingt einfacher. Wer mit seinem Management Studio remote auf die Integration Services auf einem Server zugreifen möchte und dort kein lokaler Admin ist, muss erst mal einige Hürden überwinden.

Full story »

Umzug in eine neue Domäne

In diesem Artikel werden die Schritte beschrieben, die ich vor und während des Umzugs eines SQL Servers in eine neue Domäne durchgeführt habe. Bei anderen Server sind sicherlich Abweichungen zu beachten.

Full story »

Error: 18456, Severity: 14, State: 11

Auch wenn ich die Ursache dieses Problems noch nicht klären konnte, will ich hier eine kurze Beschreibung geben und eine Lösungsmöglichkeit aufzeigen.
Vor einer Serverumstellung hatte ich schon mal auf dem neuen System einige Testdatenbanken restored und schon ein paar Logins angelegt. Diese Logins hatten die Datenbanken als Default-Datenbank. Während der Umstellung wurden die produktiven Datenbanken (Full + Differential) auf das neue System restored. Die vorher angelegten Logins blieben erhalten. Alle weiteren Logins wurden angelegt.

Nur bei den vorher angelegten Logins bekamen die Anwender Fehlermeldungen:

Error: 18456, Severity: 14, State: 11.
Login failed for user 'Domäne\Konto'. 
Reason: Token-based server access validation failed with an infrastructure error. 
Check for previous errors. 

Bei der Suche nach der Ursache habe ich zuerst die Liste der Status-Codes gefunden, welche sich ohne den Support bearbeiten lassen.
Status 11 sagt also "Valid login but server access failure". Bei der weiteren Suche bin ich dann auf ein SQL gestossen, was mir die Berechtigungen der Logins anzeigt
SELECT t2.name,t1.*
FROM  sys.server_permissions t1 , sys.server_principals t2
WHERE t1.grantee_principal_id = t2.principal_id
AND t1.TYPE<>'R'
ORDER BY name;

Bei der Liste fiel auf, dass für die problembehafteten Logins kein Eintrag vorhanden war. Nun galt es nur noch die fehlende Berechtigung zu setzen:
USE MASTER
GO
GRANT connect sql TO [Domäne\Konto];

und schon konnten die User sich anmelden.

Serverweite Berechtigungen und verwaiste Benutzer

Ausgehend von der Fragestellung, einen Überblick über die Berechtigungen in den verschiedenen Datenbank eines Servers zu erstellen, fand ich die dahinter gelagerten Möglichkeiten auch recht reizvoll.

Nachdem ich bereits vor einigen Wochen ein kleines Skript gepostet habe, welches die Berechtigungen in einer Datenbank darstellt, kam jetzt die Anforderung auf, die Berechtigungen in allen Datenbanken eines ganzen Servers zu dokumentieren. Was lag da näher, als die undokumentierte Prozedur sp_MSforeachdb zu verwenden. Diese Prozedur befindet sich in der master-Datenbank und erwartet im einfachsten Falle einen Befehl, in dem das Fragezeichen als Platzhalter für den Datenbanknamen steht.

Beispielaufruf

exec sp_MSforeachdb @command1='use [?]; select db_name()'
Dieses Skript wechselt also zuerst den Datenbank-Kontext und ruft danach die Funktion zur Ermittlung des Datenbank-Namens auf.

Ermittlung der Berechtigungen

Hier deklariere ich zuerst eine Variable, der ich den Code der Abfrage zuweise und rufe danach die oben beschriebene Prozedur auf. Damit ich die Werte aber dauerhaft habe, lege ich vorher noch eine temporäre Tabelle an, die ich anschliessend für weitere Auswertungen verwenden kann. Hierbei fiel mir auf, dass in einigen Datenbanken WINDOWS_USER existieren, die Spalte Login aber NULL ist. Die Ursache war schnell gefunden: Das Login wurde auf dem Server gelöscht und der Benutzer blieb erhalten. Ähnliches kann auch passieren, wenn man eine Datenbank per Backup/Restore auf einen anderen Server bringt, wo nicht die gleichen Logins angelegt sind. Spontan fielen mir folgende Suchen ein:

  • WINDOWS_USER ohne Login
  • SQLUSER ohne Login
  • DBOs ohne Login

Ich denke, die Möglichkeiten dieser Sammlung werden schnell deutlich. Vielleicht fallen ja dem ein oder anderen noch interessante Ergänzungen ein, die er hier als Kommentar posten möchte.

1 2 »