EXECUTE AS (Transact-SQL)

Le nom d'utilisateur ou de connexion spécifié dans EXECUTE AS <context_specification> doit exister en tant que principal respectivement dans sys.database_principals ou sys.server_principals, sinon l'instruction EXECUTE AS échoue. De plus, les autorisations IMPERSONATE doivent être accordées sur le principal. À moins que l'appelant soit le propriétaire de la base de données ou un membre du rôle serveur fixe sysadmin, le principal doit exister même lorsque l'utilisateur accède à la base de données ou à une instance de SQL Server par le biais d'une appartenance à un groupe Windows. Par exemple, supposons les conditions suivantes :

• Le groupe CompanyDomain\SQLUsers a accès à la base de données Sales.

• L'utilisateur CompanyDomain\SqlUser1 est membre de SQLUsers ; il a donc un accès implicite à la base de données Sales.

Bien que CompanyDomain\SqlUser1 ait accès à la base de données du fait de son appartenance au groupe SQLUsers, l'instruction EXECUTE AS USER = 'CompanyDomain\SqlUser1' échoue parce que CompanyDomain\SqlUser1 n'existe pas comme principal dans la base de données.

Si l'utilisateur est orphelin (la connexion associée n'existant plus) et qu'il n'a pas été créé au moyen de la clause WITHOUT LOGIN, l'instruction EXECUTE AS échoue pour l'utilisateur.

Spécifiez une connexion ou un utilisateur bénéficiant du minimum de privilèges indispensable pour effectuer les opérations dans la session. Par exemple, ne spécifiez pas de nom de connexion avec des autorisations de niveau serveur, si seules les autorisations de niveau base de données sont requises ; ne spécifiez pas non plus un compte de propriétaire de base de données à moins que ces autorisations ne soient nécessaires.

Attention

L'instruction EXECUTE AS peut aboutir dès l'instant où le Moteur de base de données est en mesure de résoudre le nom. S'il existe un utilisateur de domaine, Windows peut être en mesure de résoudre l'utilisateur pour le Moteur de base de données, même si l'utilisateur Windows n'a pas accès à SQL Server. Cela peut aboutir à une condition dans laquelle une connexion sans accès à SQL Server semble être établie, bien que le nom de connexion emprunté ne dispose que des autorisations accordées au public ou à un invité.

Lorsque l'instruction EXECUTE AS comporte la clause WITH NO REVERT facultative, le contexte d'exécution d'une session ne peut pas être réinitialisé à l'aide de REVERT ou en exécutant une autre instruction EXECUTE AS. Le contexte défini par l'instruction reste en vigueur jusqu'à ce que la session soit supprimée.

Lorsque la clause WITH NO REVERT COOKIE = @varbinary_variable est spécifiée, le Moteur de base de données SQL Server transmet la valeur du cookie à @varbinary_variable. Le contexte d'exécution défini par cette instruction ne peut être restauré au contexte précédent que si l'instruction REVERT WITH COOKIE = @varbinary_variable appelante contient la même valeur @varbinary_variable .

Cette option est utile dans un environnement où le groupement de connexions est utilisé. Le groupement de connexions est la maintenance d'un groupe de connexions de base de données à réutiliser par des applications sur un serveur d'applications. Comme la valeur passée à @varbinary_variable n'est connue que de l'appelant de l'instruction EXECUTE AS, celui-ci peut garantir que le contexte d'exécution qu'il établit ne peut pas être modifié par une tierce personne.

Utilisez la fonction ORIGINAL_LOGIN pour retourner le nom de la connexion utilisée pour se connecter à l'instance de SQL Server. Vous pouvez utiliser cette fonction pour retourner l'identité de la connexion originale dans les sessions dans lesquelles il y a beaucoup de changements de contexte explicites ou implicites.

L'exemple suivant crée une pile d'exécutions de contexte à l'aide de plusieurs principaux. L'instruction REVERT est ensuite utilisée pour réinitialiser le contexte d'exécution à l'appelant précédent. L'instruction REVERT est exécutée plusieurs fois en remontant la pile jusqu'à ce que le contexte d'exécution soit défini pour l'appelant d'origine.

USE AdventureWorks2008R2;
GO
--Create two temporary principals
CREATE LOGIN login1 WITH PASSWORD = 'J345#$)thb';
CREATE LOGIN login2 WITH PASSWORD = 'Uor80$23b';
GO
CREATE USER user1 FOR LOGIN login1;
CREATE USER user2 FOR LOGIN login2;
GO
--Give IMPERSONATE permissions on user2 to user1
--so that user1 can successfully set the execution context to user2.
GRANT IMPERSONATE ON USER:: user2 TO user1;
GO
--Display current execution context.
SELECT SUSER_NAME(), USER_NAME();
-- Set the execution context to login1. 
EXECUTE AS LOGIN = 'login1';
--Verify the execution context is now login1.
SELECT SUSER_NAME(), USER_NAME();
--Login1 sets the execution context to login2.
EXECUTE AS USER = 'user2';
--Display current execution context.
SELECT SUSER_NAME(), USER_NAME();
-- The execution context stack now has three principals: the originating caller, login1 and login2.
--The following REVERT statements will reset the execution context to the previous context.
REVERT;
--Display current execution context.
SELECT SUSER_NAME(), USER_NAME();
REVERT;
--Display current execution context.
SELECT SUSER_NAME(), USER_NAME();

--Remove temporary principals.
DROP LOGIN login1;
DROP LOGIN login2;
DROP USER user1;
DROP USER user2;
GO

L'exemple suivant définit le contexte d'exécution d'une session sur un utilisateur spécifié et précise la clause REVERT WITH COOKIE = @varbinary_variable. L'instruction REVERT doit spécifier la valeur passée à la variable @cookie dans l'instruction EXECUTE AS pour ramener le contexte à l'appelant. Pour exécuter cet exemple, la connexion login1 et l'utilisateur user1 créés dans l'exemple A doivent exister.

DECLARE @cookie varbinary(100);
EXECUTE AS USER = 'user1' WITH COOKIE INTO @cookie;
-- Store the cookie in a safe location in your application.
-- Verify the context switch.
SELECT SUSER_NAME(), USER_NAME();
--Display the cookie value.
SELECT @cookie;
GO
-- Use the cookie in the REVERT statement.
DECLARE @cookie varbinary(100);
-- Set the cookie value to the one from the SELECT @cookie statement.
SET @cookie = <value from the SELECT @cookie statement>;
REVERT WITH COOKIE = @cookie;
-- Verify the context switch reverted.
SELECT SUSER_NAME(), USER_NAME();
GO