Clarificare cu privire la motivul pentru care EXECUTE AS USER/LOGIN nu returnează rezultatele așteptate? (Programare, Sql, Server Sql, Sql Server 2008, Sql Server 2008 R2, Ssms)

athom a intrebat.

Execut următoarea interogare pe o bază de date:

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

Dar apare următoarea eroare:

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

Utilizatorul este dbo al bazei de date, iar atunci când deschid proprietățile în Management Studio, pot vedea că este asociat cu acel login. Se execută EXECUTE AS LOGIN = 'domainusername' returnează rezultate, pe de altă parte. Și dacă execut în mod explicit EXECUTE AS USER = 'dbo', , obțin rezultate. De asemenea, am o altă bază de date în care același scenariu returnează rezultate cu ambele EXECUTE AS USER și EXECUTE AS LOGIN.

Într-un alt scenariu cu un alt utilizator, am rulat EXECUTE AS LOGIN = 'domainusername' și nu am obținut rezultate, dar am obținut rezultate cu EXECUTE AS USER = 'domainusername'.

Amândoi utilizatorii din aceste scenarii sunt asociați cu autentificări care sunt membri ai grupului db_owner pentru baza de date.

Poate cineva să-mi spună de ce aceste interogări nu returnează rezultatele pe care le aștept? Și să mă anunțe dacă îmi scapă vreo informație importantă. Vă mulțumesc!

3 răspunsuri
RBarryYoung

Problema este că, din cauza faptului că, din cauza faptului că Login domainusername este dbo al bazei de date, acel de asemenea, înseamnă că numele utilizatorului corespunzător din baza de date este dbo și nu domainusername.

Comentarii

  • Ceea ce mă derutează este că EXECUTE AS USER = 'domainusername' funcționează pe o altă bază de date în care utilizatorul este dbo, dar nu și pe această bază de date. Aveți vreo idee de ce ar putea fi așa? –  > Por athom.
  • Bănuiala mea ar fi că au folosit pentru a fi un utilizator non-DBO și mai târziu a devenit proprietarul bazei de date, dar vechea lor intrare de utilizator a plecat în urmă. Asta nu ar trebui să se întâmple, dar am văzut cu siguranță acest lucru. –  > Por RBarryYoung.
  • Am verificat să văd care sunt diferențele dintre cei doi utilizatori. Utilizatorul la care a fost înregistrată EXECUTE AS USER interogarea nu funcționa are rolurile de server dbcreator, public și security admin. Utilizatorul la care interogarea funcționa avea toate rolurile de server. După ce i-am dat aceleași roluri ca și celuilalt utilizator, am obținut aceleași rezultate ca și celălalt utilizator. –  > Por athom.
  • Atunci, problema a fost probabil că contextul dvs. de execuție inițial nu avea permisiunea de a impersonifica utilizatorul. –  > Por RBarryYoung.
Remus Rusanu

executați ALTER AUTHORIZATION ON DATABASE::[<yourdb>] TO [sa]

Comentarii

  • Nu doresc să modific nimic în ceea ce privește baza de date, deoarece aplicația care rulează această interogare va fi folosită în cele din urmă pe mașini client. Pur și simplu doresc să obțin permisiunile unui anumit utilizator/login pentru a determina dacă este configurat corect. Dacă nu cumva am înțeles greșit ce face de fapt această interogare. –  > Por athom.
Jim Miller

Am avut aceeași eroare pentru o procedură stocată pe care am scris-o.

Am descoperit că eroarea a fost cauzată de modul în care am specificat numele bazei de date în interogare

SELECT emp_no 
FROM   db_name.employee 
WHERE  emp_no = 1234

Am executat procedura pe db_name2 odată ce am eliminat numele bazei de date din scriptul meu

SELECT emp_no 
FROM   employee 
WHERE  emp_no = 1234

a funcționat bine.

Nu cred că drepturile de acces reduse ale jurnalului permit utilizarea altor baze de date sau a use db_name comandă.