Chiarimento sul motivo per cui EXECUTE AS USER/LOGIN non restituisce i risultati previsti?

Sto facendo funzionare la seguente query in un database:Chiarimento sul motivo per cui EXECUTE AS USER/LOGIN non restituisce i risultati previsti?

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

Ma il seguente errore si butta:

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.

l'utente è il dbo del database, e quando ho aperto la proprietà in studio di gestione, posso vedere che è associato con quel login. L'esecuzione di EXECUTE AS LOGIN = 'domain\username' restituisce risultati, d'altra parte. E se eseguo esplicitamente EXECUTE AS USER = 'dbo', ottengo risultati. Ho anche un database diverso in cui questo stesso scenario restituisce risultati sia con EXECUTE AS USER e EXECUTE AS LOGIN.

In un altro scenario con un altro utente, ho eseguito EXECUTE AS LOGIN = 'domain\username' e non ottengo risultati, ma ottengo risultati con EXECUTE AS USER = 'domain\username'.

Entrambi gli utenti in questi scenari sono associati agli accessi che sono membri di db_owner per il database.

Qualcuno può dirmi perché queste query non restituiscono i risultati che mi aspetto? E fammi sapere se mi mancano informazioni importanti. Grazie!

fonte

2012-10-23 athom

Il problema è che, poiché l'accesso domain\username è il dbo del database, che anche significa che il nome del loro corrispondente per l'utente all'interno di tale database è dbo e nondomain\username.

fonte

2012-10-23 19:55:46 RBarryYoung

La cosa che mi confonde è che "EXECUTE AS USER = 'domain \ username'' funziona su un altro database dove l'utente è il dbo ma non su questo database. Qualche idea sul perché potrebbe essere? – athom

La mia ipotesi sarebbe che erano un utente non DBO e in seguito sono diventati i proprietari del database, ma la loro vecchia voce utente è rimasta indietro. Non dovrebbe accadere, ma l'ho sicuramente visto. – RBarryYoung

Ho controllato per vedere quali differenze c'erano tra i due utenti. L'utente in cui la query 'EXECUTE AS USER' non funzionava ha i ruoli del server di admin dbcreator, public e security.L'utente su cui ha funzionato la query aveva tutti i ruoli del server. Una volta che gli ho dato gli stessi ruoli dell'altro utente, ho ottenuto gli stessi risultati dell'altro utente. – athom

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

fonte

2012-10-23 19:50:18

Non desidero modificare nulla sul database, poiché l'applicazione che esegue questa query verrà infine utilizzata sui computer client. Voglio semplicemente ottenere le autorizzazioni di un utente/accesso specifico per determinare se è configurato correttamente. A meno che non fraintenda cosa sta effettivamente facendo quella query. – athom

Ho avuto lo stesso errore per una procedura memorizzata che ho scritto.

ho trovato l'errore è stato causato dal modo in cui avevo specificato il nome del database nella query

SELECT emp_no 
FROM db_name.employee 
WHERE emp_no = 1234

mi stava eseguendo la procedura a db_name2 una volta ho rimosso il nome del database dal mio script

SELECT emp_no 
FROM employee 
WHERE emp_no = 1234

ha funzionato bene.

Non credo che i diritti di accesso ridotti del registro consentano l'utilizzo di altri database o il comando use db_name.

fonte

2014-08-20 10:31:29

Chiarimento sul motivo per cui EXECUTE AS USER/LOGIN non restituisce i risultati previsti?

risposta

Problemi correlati