DISABLE und DENY LOGIN, DENY USER & Effekt auf Impersonierung und Berechtigungen

Ein kurzer Artikel zu den Effekten – oder fehlenden Effekten – in Bezug auf das Deaktivieren & Verbieten von Connect für Logins und Users auf Impersonierung und Berechtigungen.

Immer mal wieder kann man beobachten, dass Logins oder Usern die Connect-Berechtigung verboten bekommen wurde, oder ein Login deaktiviert wurde.

Die richtige Erwartung und Verständnis kann daher kritisch sein.

Sehen wir uns also eine einfache Demo an: Wir werden das eingebaute sa-Konto, welches von vielen unter anderem als Datenbankbesitzer (mehr dazu bald in einem anderen Artikel – zwischenzeitlich lade ich Sie dazu ein, noch Daten zu der Umfrage zu diesem Thema einzusenden), ein weiteres frisch angelegtes Konto und eine Datenbank, genannt ImpersonateLogin mit dem entsprechenden User + einem weiteren User ohne Login: SQLUser.

Ich deaktiviere also das sa-Konto ebenso wie das „DeniedLogin“-Konto – letzterem verbiete ich außerdem die Connect-Berechtigung (Erinnern wir uns daran: „Berechtigungen können nicht für sa, dbo, Entitäts-Besitzer, information_schema, sys oder für den Benutzer selbst erteilt, verweigert oder aufgehoben werden.“)

Der Datenbank-User „SQLUser“ bekommt die Connect-Berechtigung auf die Datenbank verboten. In der GUI sieht das Ergebnis so aus:

1403_DisabledPrincipals_Setup_Disabled_sa

Nun führen wir 4 Tests durch:

Was diese Abfragen im Wesentlichen machen, ist, zu versuchen, den entsprechenden Login oder User zu impersonieren – und den Erfolg dadurch belegen, dass sie die dann jeweils aktiven Rollen-Mitgliedschaften zurückgeben. Ergebnisse:

DeniedLogin: Impersonierung funktioniert + kein Verlust an Berechtigungen.
In other words: Denying Connect to a Login does not disallow Impersonation. Impersonation is actually another permission which one can use and is not affected even by Disabling the Login!

Dasselbe gilt für den sa: Impersonierung funktioniert + kein Verlust a Berechtigungen.

Im Folgenden ein Test für den User, dem die Connect-Berechtigung auf die Datenbank entzogen worden ist – und nicht als Login verwendet werden kann.

Ergebnisse:

Msg 15517, Level 16, State 1, Line 3

Die Ausführung als Datenbankprinzipal ist nicht möglich, weil der Prinzipal ‚DeniedLogin‘ nicht vorhanden ist,

für diesen Typ von Prinzipal kein Identitätswechsel möglich ist, oder Sie nicht die erforderliche Berechtigung haben.

Msg 916, Level 14, State 1, Line 3

Der Serverprinzipal ‚S-1-9-3-4049223906-1289824279-1154161590-488313048.‘

kann unter dem aktuellen Sicherheitskontext nicht auf die ImpersonateLogin-Datenbank zugreifen.

Das Ergebnis ist für beide Datenbank-User effektiv das gleiche.

Die GUID repräsentiert keinen reellen Server-Prinzipal, denn der User SQLUser hat keinen entsprechenden Login. Daher sagt es uns, dass die User nicht innerhalb der Datenbank impersoniert werden können.

Der Unterschied für den 2. User ist, dass dieser User nur innerhalb der Datenbank existiert, aber zugleich expliziert verboten wurde, sich mit ihr zu verbinden Das hat im Endeffekt dasselbe Resultat, wie ihn zu deaktivieren – genau wie der Guest-User es ist.

Damit wäre gezeigt, dass das Deaktivieren von Logins keinerlei Sicherheit gegenüber Angriffen von Innen gibt. Und sogenannte Privilegien Erweiterung findet in aller Regel z.B. von innen heraus statt.

Auch der alte „Trick“, die Standard-Datenbank des Logins zu löschen, ist da keine Hilfe.

Für Datenbank-User hat es durchaus Effekt und verhindert das Anmelden an der jeweiligen Datenbank – auch „von Innen heraus“.

Konsequenterweise bleiben alle Berechtigungen (natürlich abgesehen von dem jeweiligen Deny) der jeweiligen Logins und User absolut unbeeinflusst von einer Deaktivierung jeglicher Weise.

Das gilt auch im Zusammenhang mit „External Access“-Berechtigung für Logins basierend auf asymmetrischen Schlüsseln. (Hier ein Forum-Thread, in dem die Frage auftauchte: “SQL Login „disabled“ flag does not work with asymmetric key??”)

ALTER LOGIN ist auch hier in BOL erklärt: technet.microsoft.com/en-us/library/ms189828.aspx

Ich hoffe, diese Dinge erklären einiges und speziell Empfehlungen in Sicherheits-Aspekten.