2012-10-23 11 views
12

ich die folgende Abfrage einer Datenbank leite:Erläuterung, warum EXECUTE AS USER/LOGIN nicht die erwarteten Ergebnisse liefert?

execute as user = 'domain\username' 
select * from fn_my_permissions(null, 'DATABASE') 
order by subentity_name, permission_name 
revert; 

Aber der folgende Fehler ausgelöst wird:

Cannot execute as the database principal because the principal "dev\spadmin" does not exist, this type of principal cannot be impersonated, or you do not have permission.

Der Benutzer die dbo der Datenbank ist, und wenn ich öffnen, die Eigenschaften in Management Studio, kann ich sehen, dass es mit diesem Login verbunden ist. Das Ausführen von EXECUTE AS LOGIN = 'domain\username' gibt jedoch Ergebnisse zurück. Und wenn ich explizit EXECUTE AS USER = 'dbo' ausführen, bekomme ich Ergebnisse. Ich habe auch eine andere Datenbank, in der das gleiche Szenario Ergebnisse mit EXECUTE AS USER und EXECUTE AS LOGIN zurückgibt.

In einem anderen Szenario mit einem anderen Benutzer, habe ich ran und ich bekomme keine Ergebnisse, aber ich bekomme Ergebnisse mit EXECUTE AS USER = 'domain\username'.

Beide Benutzer in diesen Szenarien sind Logins zugeordnet, die Mitglieder von db_owner für die Datenbank sind.

Kann mir jemand sagen, warum diese Abfragen die Ergebnisse, die ich erwarte, nicht zurückgeben? Und lassen Sie es mich wissen, wenn mir wichtige Informationen fehlen. Vielen Dank!

Antwort

9

Das Problem ist, dass, weil die Anmeldung domain\username die dbo der Datenbank ist, dass auch bedeutet, dass der Name ihrer entsprechenden Benutzer innerhalb dieser Datenbank ist dbo und nichtdomain\username.

+0

Die Sache, die mich verwirrt, ist, dass 'EXECUTE AS USER = 'Domäne \ Benutzername'' funktioniert auf einer anderen Datenbank, wo der Benutzer der DBO aber nicht auf dieser Datenbank ist. Irgendeine Idee warum das sein könnte? – athom

+0

Meine Vermutung wäre, dass sie früher ein Nicht-DBO-Benutzer waren und später Besitzer der Datenbank wurden, aber ihren alten Benutzereintrag zurückgelassen haben. Das soll nicht passieren, aber ich habe es definitiv gesehen. – RBarryYoung

+0

Ich überprüfte, was die Unterschiede zwischen den zwei Benutzern waren. Der Benutzer, bei dem die Abfrage "EXECUTE AS USER" nicht funktionierte, hat die Serverrollen dbcreator, public und security admin.Der Benutzer, für den die Abfrage ausgeführt wurde, hatte alle Serverrollen. Sobald ich ihm die gleichen Rollen wie dem anderen Benutzer gab, bekam ich die gleichen Ergebnisse wie der andere Benutzer. – athom

1

Lauf ALTER AUTHORIZATION ON DATABASE::[<yourdb>] TO [sa]

+1

Ich möchte nichts über die Datenbank ändern, weil die Anwendung, die diese Abfrage ausführt, schließlich auf Client-Computern verwendet wird. Ich möchte einfach die Berechtigungen eines bestimmten Benutzers/Logins erhalten, um festzustellen, ob es richtig konfiguriert ist. Wenn ich nicht falsch verstehe, was diese Abfrage tatsächlich macht. – athom

0

Ich hatte den gleichen Fehler für eine gespeicherte Prozedur, die ich schrieb.

fand ich den Fehler wurde durch die Art und Weise verursacht ich den Datenbanknamen in der Abfrage angegeben hatte

SELECT emp_no 
FROM db_name.employee 
WHERE emp_no = 1234 

Ich war die Ausführung der Prozedur auf db_name2, wenn ich den Namen der Datenbank von meinem Skript entfernt

SELECT emp_no 
FROM employee 
WHERE emp_no = 1234 

es hat gut funktioniert.

Ich glaube nicht, dass die reduzierten Zugriffsrechte des Protokolls die Verwendung anderer Datenbanken oder den use db_name Befehl ermöglichen.

Verwandte Themen