Was ist der Unterschied zwischen EXECUTE AS USER und EXECUTE AS LOGIN, der dazu führt, dass sich der zweite unerwartet verhält?

Kürzlich habe ich EXECUTE AS LOGIN verwendet, um zu überprüfen, ob eine bestimmte Person eine Tabellenfunktion in einer unserer Datenbanken verwenden kann oder nicht. Die Tests zeigten, dass er konnte, aber er meldete wiederholt einen Fehler.

Die Person verwendet Login 'WEB', um eine Verbindung zur Datenbank herzustellen, und sie hat den Benutzer 'WEB' in dieser Datenbank, der mit Login 'WEB' verknüpft ist. Daher habe ich die folgenden Skripte ausprobiert:

-- part 1
EXECUTE AS USER = 'WEB'
GO
SELECT 
    USER_NAME() AS 'user_name'
    ,SUSER_NAME() AS 'suser_name'
    ,SUSER_SNAME() AS 'suser_sname'
    ,SYSTEM_USER AS 'system_user'
GO
REVERT
GO

und

-- part 2
EXECUTE AS LOGIN = 'WEB'
GO
SELECT 
    USER_NAME() AS 'user_name'
    ,SUSER_NAME() AS 'suser_name'
    ,SUSER_SNAME() AS 'suser_sname'
    ,SYSTEM_USER AS 'system_user'
GO
REVERT
GO

Der erste Teil war in Ordnung mit dem Ergebnis von:

WEB | WEB | WEB | NETZ

Das zweite Ergebnis war jedoch etwas verwirrend:

dbo | WEB | WEB | NETZ

Was ist der Unterschied zwischen EXECUTE AS USER und EXECUTE AS LOGIN, der den zweiten zum Scheitern bringt? Außerdem ist der erste natürlich die Datenbankebene und der zweite der Identitätswechsel auf Serverebene, was mir bekannt ist und was die Situation hier nicht erklärt.

sql-server-2008 security

— Gemisigo
quelle

Der zweite Fehler ist nicht "fehlgeschlagen", sondern zeigt nur an, dass dem Login eine Serverrolle (sysadmin) zugewiesen ist. Haben Sie die vom Benutzer angeforderten Schemas überprüft? Hatte das vorher, wo das dbo-Standardschema nicht das ist, was die Entwickler erwartet hatten. Besser im Code durch vollständige Bezugnahme auf die Tabelle behoben

— Stuart Moore

Ein Mitglied einer sysadminGruppe wird immer zugeordnet dbo, auch wenn es einen expliziten Benutzer in der Datenbank hat. Es sieht also so aus, als ob das Login WEBMitglied von ist sysadminund daher im zweiten Fall USER_NAME()korrekt zurückgegeben dbowird.

— Remus Rusanu
quelle

Überprüft und bestätigt. Es war in der Tat ein Mitglied von sysadmin. Es stellte sich heraus, dass dieser Bericht einen der anderen Entwickler erreicht hat und anstelle der richtigen Lösung einfach die Login-Systemadministratorrolle zugewiesen hat. Ich würde nicht einmal daran denken, ich bin wirklich enttäuscht. Wir werden uns ernsthaft unterhalten, wenn er zurückkommt. Habe heute etwas Neues gelernt, danke.

— Gemisigo

Dies bedeutet auch, dass Ihre Anwendung (Bericht?) Eine Identitätsberechtigung für ein Sysadmin-Mitglied besitzt. Überprüfen Sie, wie genau dies in der Berechtigungshierarchie gewährt wird. Es ist wahrscheinlich, dass der Bericht auch jetzt noch ein anderes sysadminMitglied darstellen kann, wenn er dies wünscht. Daher ist die Berichtsanwendung ein De-facto-Systemadministrator. Dh. Dies ist ein möglicher Angriffsvektor für die Erhöhung von Berechtigungen. Er kann von einem Hacker oder wahrscheinlicher von Ihren Mitarbeitern verwendet werden.

— Remus Rusanu

Wenn die Bericht-App die Berechtigung IMPERSONATE aktiviert hat WEBund von WEBdieser entfernt wurde, sysadminwird die Tür geschlossen. Aber es lohnt sich trotzdem zu überprüfen.

— Remus Rusanu

Ja, wir müssen noch einmal alles überprüfen, was die Rechte betrifft, um festzustellen, ob andere Probleme auf diese Weise "behoben" wurden. Im

— Moment