Kommentar
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
gäller för:SQL Server
Azure SQL Database
Azure SQL Managed Instance
Azure Synapse Analytics
Anger körningskontexten för en session.
Som standard startar en session när en användare loggar in och slutar när användaren loggar ut. Alla åtgärder under en session är föremål för behörighetskontroller mot användaren. När en EXECUTE AS sats körs byts sessionens exekveringskontext till den angivna inloggningen eller användarnamnet. Efter kontextbytet kontrolleras behörigheter mot inloggnings- och användarsäkerhetstokens för det kontot istället för den person som anropar uttalandet EXECUTE AS . I grund och botten personifieras användar- eller inloggningskontot under hela sessionen eller modulkörningen, eller så återställs kontextväxeln uttryckligen.
Transact-SQL syntaxkonventioner
Syntax
{ EXEC | EXECUTE } AS <context_specification>
[;]
<context_specification>::=
{ LOGIN | USER } = 'name'
[ WITH { NO REVERT | COOKIE INTO @varbinary_variable } ]
| CALLER
Argument
LOGIN
Applies to: SQL Server 2008 (10.0.x) och senare.
Anger att körningskontexten som ska personifieras är en inloggning. Omfånget för personifiering är på servernivå.
Not
Det här alternativet är inte tillgängligt i en innesluten databas, Azure SQL Database eller Azure Synapse Analytics.
USER
Anger att kontexten som ska personifieras är en användare i den aktuella databasen. Omfattningen för personifiering är begränsad till den aktuella databasen. En kontextväxling till en databasanvändare ärver inte användarens behörigheter på servernivå.
Viktig
Kontextväxlingen till databasanvändaren är aktiv, men alla försök att komma åt resurser utanför databasen gör att instruktionen misslyckas. Detta inkluderar USE database-instruktioner, distribuerade frågor och frågor som refererar till en annan databas som använder tre- eller fyradelade identifierare.
"namn" Är ett giltigt användarnamn eller inloggningsnamn. namn måste vara medlem i sysadmin fast serverroll eller finnas som huvudnamn i sys.database_principals respektive sys.server_principals.
namn kan anges som en lokal variabel.
namn måste vara ett singleton-konto och får inte vara en grupp, roll, certifikat, nyckel eller inbyggt konto, till exempel NT AUTHORITY\LocalService, NT AUTHORITY\NetworkService eller NT AUTHORITY\LocalSystem.
Mer information finns i Ange ett användar- eller inloggningsnamn senare i det här avsnittet.
NEJ REVERT
Anger att kontextväxlingen inte kan återställas till föregående kontext.
NEJ-alternativet REVERT kan bara användas på ad hoc-nivå.
För mer information om att återgå till föregående kontext, se REVERT (Transact-SQL).
COOKIE INTO @VARBINARY_VARIABLE
Specificerar att exekveringskontexten endast kan återställas till föregående kontext om den anropande REVERT WITH COOKIE-satsen innehåller rätt @varbinary_variable värde. Database Engine skickar cookien till @varbinary_variable. Alternativet COOKIE INTO kan endast användas på adhoc-nivå.
@varbinary_variable är varbinary(8000).
Not
Cookien OUTPUT parametern för dokumenteras för närvarande som varbinary(8000) vilket är rätt maximal längd. Den aktuella implementeringen returnerar dock varbinary(100). Program bör reservera varbinary(8000) så att programmet fortsätter att fungera korrekt om cookiens returstorlek ökar i en framtida version.
BESÖKARE
När de används i en modul anger du att instruktionerna i modulen körs i kontexten för modulens anropare.
När den används utanför en modul har instruktionen ingen åtgärd.
Not
Det här alternativet är inte tillgängligt i Azure Synapse Analytics.
Anmärkningar
Ändringen i körningskontexten gäller tills något av följande inträffar:
Ett annat EXECUTE AS uttalande körs.
Ett REVERT uttalande körs.
Sessionen tas bort.
Den lagrade proceduren eller utlösaren där kommandot kördes avslutas.
Du kan skapa en exekveringskontextstack genom att anropa satsen EXECUTE AS flera gånger över flera principer. När satsen REVERT anropas byter den kontexten till inloggningen eller användaren på nästa nivå i kontextstacken. En demonstration av det här beteendet finns i Exempel A.
Ange ett användar- eller inloggningsnamn
Användaren eller inloggningsnamnet som anges i EXECUTE AS<context_specification> måste existera som principal i sys.database_principals respektive sys.server_principals, annars misslyckas satsen EXECUTE AS . Dessutom måste IMPERSONATE-behörigheter beviljas för huvudkontot. Om inte anroparen är databasägaren eller är medlem i sysadmin fast serverroll, måste huvudnamnet finnas även när användaren har åtkomst till databasen eller instansen av SQL Server via ett Windows gruppmedlemskap. Anta till exempel följande villkor:
CompanyDomain\SQLUsers grupp har åtkomst till databasen Sales.
CompanyDomain\SqlUser1 är medlem i SQLUsers och har därför implicit åtkomst till databasen Sales.
Även om CompanyDomain\SqlUser1 har åtkomst till databasen via medlemskap i gruppen SQLUsers misslyckas instruktionen EXECUTE AS USER = 'CompanyDomain\SqlUser1' eftersom CompanyDomain\SqlUser1 inte finns som huvudnamn i databasen.
Om användaren är föräldralös (den associerade inloggningen existerar inte längre), och användaren inte skapades med UTAN LOGIN, EXECUTE AS kommer användaren att misslyckas.
Bästa praxis
Ange en inloggning eller användare som har de lägsta behörigheter som krävs för att utföra åtgärderna i sessionen. Ange till exempel inte ett inloggningsnamn med behörigheter på servernivå, om endast behörigheter på databasnivå krävs. eller ange inte ett databasägarkonto om inte dessa behörigheter krävs.
Försiktighet
Satsen EXECUTE AS kan lyckas så länge Database Engine kan lösa namnet. Om det finns en domänanvändare kanske Windows kan matcha användaren för Database Engine, även om Windows användaren inte har åtkomst till SQL Server. Detta kan leda till ett villkor där en inloggning utan åtkomst till SQL Server verkar vara inloggad, även om den personifierade inloggningen endast skulle ha behörigheter som beviljats till offentlig eller gäst.
Säkerhetsfrågor
Att köra under dbo-ägarkontexten, till exempel genom att använda satsen EXECUTE AS USER = 'dbo', ändrar hur explicita DENY behörigheter utvärderas. När du byter exekveringskontext till dbo-ägarkontexten tillämpas inte behörighetsbaserade DENY begränsningar som gäller för den ursprungliga anropande huvudpersonen under utgivningstiden. Som ett resultat kan en principal som kan byta exekveringskontext till dbo, till exempel genom medlemskap i db_owner fast databasroll, utföra åtgärder som annars skulle blockeras av explicita behörigheter DENY som appliceras på den principalen.
Det här beteendet är avsiktligt. Ta hänsyn till det när du beviljar behörigheter som tillåter personifiering av ägarskap. DENY Behörigheter kan inte fungera som en kompensationskontroll för att begränsa de effektiva behörigheterna för huvudpersoner som kan köras som DBO.
Att använda MED NO REVERT
När satsen EXECUTE AS innehåller den valfria WITH NO-klausulen REVERT kan exekveringskontexten för en session inte återställas med eller REVERT genom att köra ett annat EXECUTE AS sats. Kontexten som anges av -instruktionen gäller tills sessionen har tagits bort.
När klausulen WITH NO REVERT COOKIE = @varbinary_variable anges överför Databasmotor för SQL Server cookievärdet till @varbinary_variable. Exekveringskontexten som sätts av det uttalandet kan endast återställas till föregående kontext om det anropande REVERT WITH COOKIE = @varbinary_variable-satsen innehåller samma @varbinary_variable-värde .
Det här alternativet är användbart i en miljö där anslutningspooler används. Anslutningspooler är underhållet av en grupp databasanslutningar för återanvändning av program på en programserver. Eftersom värdet som skickas till @varbinary_variable endast är känt av anroparen av EXECUTE AS satsen kan anroparen garantera att den exekveringskontext de etablerar inte kan ändras av någon annan.
Fastställa den ursprungliga inloggningen
Använd funktionen ORIGINAL_LOGIN för att returnera namnet på inloggningen som är ansluten till instansen av SQL Server. Du kan använda den här funktionen för att returnera identiteten för den ursprungliga inloggningen i sessioner där det finns många explicita eller implicita kontextväxlar.
Behörigheter
För att specificera EXECUTE AS vid inloggning måste den som ringer ha IMPERSONATE-behörighet på det angivna inloggningsnamnet och får inte nekas IMITATE-behörigheten ALLS LOGIN . För att specificera EXECUTE AS på en databasanvändare måste anroparen ha IMPERSONATE-behörigheter på det angivna användarnamnet. När EXECUTE AS ANROPARE anges krävs inga IMPERSONATE-behörigheter .
Exempel
A. Att använda EXECUTE AS och REVERT för att byta kontext
I följande exempel skapas en kontextkörningsstack med flera huvudnamn. Instruktionen REVERT används sedan för att återställa körningskontexten till den tidigare anroparen. Instruktionen REVERT körs flera gånger när stacken flyttas tills körningskontexten har angetts till den ursprungliga anroparen.
USE AdventureWorks2022;
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
B. Använda WITH COOKIE-satsen
I följande exempel anges körningskontexten för en session till en angiven användare och anger satsen WITH COOKIE INTO @varbinary_variable.
REVERT-instruktionen måste ange värdet som skickas till variabeln @cookie i EXECUTE AS-instruktionen för att återställa kontexten till anroparen. Om du vill köra det här exemplet måste login1 inloggning och user1 användare som skapats i exempel A finnas.
DECLARE @cookie VARBINARY(8000);
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(8000);
-- 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