Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
              Van toepassing op:SQL Server
Azure SQL Database
Azure SQL Managed Instance
In SQL Server kunt u de uitvoeringscontext definiëren van de volgende door de gebruiker gedefinieerde modules: functies (behalve inline tabelwaardefuncties), procedures, wachtrijen en triggers.
Door de context op te geven waarin de module wordt uitgevoerd, kunt u bepalen welk gebruikersaccount de Database Engine gebruikt om machtigingen te valideren voor objecten waarnaar wordt verwezen door de module. Dit biedt extra flexibiliteit en controle over het beheren van machtigingen in de objectketen die bestaat tussen door de gebruiker gedefinieerde modules en de objecten waarnaar wordt verwezen door deze modules. Machtigingen moeten alleen worden verleend aan gebruikers in de module zelf, zonder dat ze expliciete machtigingen hoeven te verlenen voor de objecten waarnaar wordt verwezen. Alleen de gebruiker die de module uitvoert, moet machtigingen hebben voor de objecten die door de module worden geopend.
              
              
              Transact-SQL syntaxis-conventies
Syntaxis
In deze sectie wordt de SQL Server-syntaxis voor EXECUTE ASbeschreven.
Functies (behalve inline tabelwaardefuncties), opgeslagen procedures en DML-triggers:
{ EXEC | EXECUTE } AS { CALLER | SELF | OWNER | 'user_name' }
DDL-triggers met databasebereik:
{ EXEC | EXECUTE } AS { CALLER | SELF | 'user_name' }
DDL-triggers met serverbereik en aanmeldingstriggers:
{ EXEC | EXECUTE } AS { CALLER | SELF | 'login_name' }
Wachtrijen:
{ EXEC | EXECUTE } AS { SELF | OWNER | 'user_name' }
Arguments
BELLER
Hiermee geeft u de instructies in de module worden uitgevoerd in de context van de aanroeper van de module. De gebruiker die de module uitvoert, moet niet alleen over de juiste machtigingen beschikken voor de module zelf, maar ook voor databaseobjecten waarnaar wordt verwezen door de module.
              CALLER is de standaardinstelling voor alle modules behalve wachtrijen en is hetzelfde als het gedrag van SQL Server 2005 (9.x).
              CALLER kan niet worden opgegeven in een CREATE QUEUE of ALTER QUEUE instructie.
SELF
              EXECUTE AS SELF is gelijk aan EXECUTE AS <user_name>, waarbij de opgegeven gebruiker de persoon is die de module maakt of wijzigt. De werkelijke gebruikers-id van de persoon die de modules maakt of wijzigt, wordt opgeslagen in de execute_as_principal_id kolom in de sys.sql_modules of sys.service_queues catalogusweergave.
              SELF is de standaardinstelling voor wachtrijen.
Opmerking
Als u de gebruikers-id van de execute_as_principal_id kolom in de sys.service_queues catalogusweergave wilt wijzigen, moet u expliciet de EXECUTE AS instelling in de ALTER QUEUE instructie opgeven.
EIGENAAR
Hiermee geeft u op dat de instructies in de module worden uitgevoerd in de context van de huidige eigenaar van de module. Als de module geen opgegeven eigenaar heeft, wordt de eigenaar van het schema van de module gebruikt. 
              OWNER kan niet worden opgegeven voor DDL- of aanmeldingstriggers.
Belangrijk
              OWNER moet worden toegewezen aan een singleton-account en kan geen rol of groep zijn.
'user_name'
Hiermee geeft u de instructies in de module die worden uitgevoerd in de context van de gebruiker die is opgegeven in user_name. Machtigingen voor objecten in de module worden gecontroleerd op basis van user_name. user_name kan niet worden opgegeven voor DDL-triggers met serverbereik of aanmeldingstriggers. Gebruik in plaats daarvan login_name .
              user_name moet bestaan in de huidige database en moet een singleton-account zijn. 
              user_name kan geen groep, rol, certificaat, sleutel of ingebouwd account zijn, zoals NT AUTHORITY\LocalService, NT AUTHORITY\NetworkServiceof NT AUTHORITY\LocalSystem.
De gebruikers-id van de uitvoeringscontext wordt opgeslagen in metagegevens en kan worden weergegeven in de execute_as_principal_id kolom in de sys.sql_modules of sys.assembly_modules catalogusweergave.
'login_name'
Hiermee geeft u de instructies in de module die worden uitgevoerd in de context van de SQL Server-aanmelding die is opgegeven in login_name. Machtigingen voor objecten in de module worden geverifieerd op basis van login_name. login_name kan alleen worden opgegeven voor DDL-triggers met serverbereik of aanmeldingstriggers.
              login_name kan geen groep, rol, certificaat, sleutel of ingebouwd account zijn, zoals NT AUTHORITY\LocalService, NT AUTHORITY\NetworkServiceof NT AUTHORITY\LocalSystem.
Opmerkingen
Hoe de database-engine machtigingen evalueert voor de objecten waarnaar in de module wordt verwezen, is afhankelijk van de eigendomsketen die bestaat tussen het aanroepen van objecten en objecten waarnaar wordt verwezen. In eerdere versies van SQL Server was eigendomsketen de enige methode die beschikbaar was om te voorkomen dat de aanroepende gebruiker toegang moet verlenen tot alle objecten waarnaar wordt verwezen.
Eigendomsketen heeft de volgende beperkingen:
- Alleen van toepassing op DML-instructies: SELECT,INSERT,UPDATEenDELETE.
- De eigenaren van het aanroepen en de aangeroepen objecten moeten hetzelfde zijn.
- Dit geldt niet voor dynamische query's in de module.
Ongeacht de uitvoeringscontext die is opgegeven in de module, zijn de volgende acties altijd van toepassing:
- Wanneer de module wordt uitgevoerd, controleert de database-engine eerst of de gebruiker die de module uitvoert, gemachtigd is - EXECUTEvoor de module.
- Eigendomsketenregels blijven van toepassing. Dit betekent dat als de eigenaren van de aanroepende en aangeroepen objecten hetzelfde zijn, er geen machtigingen worden gecontroleerd op de onderliggende objecten. 
Wanneer een gebruiker een module uitvoert die is opgegeven voor uitvoering in een andere context dan CALLER, wordt de machtiging van de gebruiker om de module uit te voeren gecontroleerd, maar worden aanvullende machtigingen gecontroleerd op objecten die door de module worden geopend, op basis van het gebruikersaccount dat in de EXECUTE AS component is opgegeven. De gebruiker die de module uitvoert, imiteert de opgegeven gebruiker.
De context die is opgegeven in de EXECUTE AS component van de module is alleen geldig voor de duur van de uitvoering van de module. Context wordt teruggezet naar de aanroeper wanneer de uitvoering van de module is voltooid.
Een gebruikersnaam of aanmeldingsnaam opgeven
Een databasegebruiker of serveraanmelding die is opgegeven in de EXECUTE AS component van een module, kan pas worden verwijderd nadat de module is gewijzigd om te worden uitgevoerd in een andere context.
De gebruiker of aanmeldingsnaam die in de EXECUTE AS component is opgegeven, moet bestaan als een principal in sys.database_principals respectievelijk sys.server_principals, of anders mislukt de bewerking voor het maken of wijzigen van de module. Daarnaast moet de gebruiker die de module maakt of wijzigt IMITATE-machtigingen voor de principal hebben.
Als de gebruiker impliciete toegang heeft tot de database of het exemplaar van SQL Server via een Windows-groepslidmaatschap, wordt de gebruiker die is opgegeven in de EXECUTE AS component impliciet gemaakt wanneer de module wordt gemaakt wanneer een van de volgende vereisten bestaat:
- De opgegeven gebruiker of aanmelding is lid van de vaste serverfunctie sysadmin .
- De gebruiker die de module maakt, is gemachtigd om principals te maken.
Wanneer aan geen van deze vereisten wordt voldaan, mislukt de bewerking voor het maken van de module.
Belangrijk
Als de SQL Server-service (MSSQLSERVER) wordt uitgevoerd als een lokaal account (lokale service of lokaal gebruikersaccount), heeft deze geen bevoegdheden om de groepslidmaatschappen te verkrijgen van een Windows-domeinaccount dat is opgegeven in de EXECUTE AS component. Hierdoor mislukt de uitvoering van de module.
Stel bijvoorbeeld dat u de volgende voorwaarden hebt:
- CompanyDomain\SQLUsersde groep heeft toegang tot de- Salesdatabase.
- CompanyDomain\SqlUser1is lid van- SQLUsersen heeft daarom toegang tot de- Salesdatabase.
- De gebruiker die de module maakt of wijzigt, heeft machtigingen om principals te maken. 
Wanneer de volgende CREATE PROCEDURE instructie wordt uitgevoerd, wordt de CompanyDomain\SqlUser1 instructie impliciet gemaakt als een database-principal in de Sales database.
USE Sales;
GO
CREATE PROCEDURE dbo.usp_Demo
WITH EXECUTE AS 'CompanyDomain\SqlUser1'
AS
SELECT USER_NAME();
GO
Zelfstandige instructie EXECUTE AS CALLER gebruiken
Gebruik de EXECUTE AS CALLER zelfstandige instructie in een module om de uitvoeringscontext in te stellen op de aanroeper van de module.
Stel dat de volgende opgeslagen procedure wordt aangeroepen door SqlUser2.
CREATE PROCEDURE dbo.usp_Demo
WITH EXECUTE AS 'SqlUser1'
AS
SELECT USER_NAME(); -- Shows execution context is set to SqlUser1.
EXECUTE AS CALLER;
SELECT USER_NAME(); -- Shows execution context is set to SqlUser2, the caller of the module.
REVERT;
SELECT USER_NAME(); -- Shows execution context is set to SqlUser1.
GO
EXECUTE AS gebruiken om aangepaste machtigingensets te definiëren
Het opgeven van een uitvoeringscontext voor een module kan handig zijn als u aangepaste machtigingensets wilt definiëren. Sommige acties, zoals TRUNCATE TABLE geen toekenningsmachtigingen hebben. Door de TRUNCATE TABLE instructie in een module op te nemen en op te geven dat deze module wordt uitgevoerd als een gebruiker die machtigingen heeft om de tabel te wijzigen, kunt u de machtigingen uitbreiden om de tabel af te kapen naar de gebruiker aan wie u machtigingen voor de module verleent EXECUTE .
Als u de definitie van de module met de opgegeven uitvoeringscontext wilt weergeven, gebruikt u de catalogusweergave sys.sql_modules .
Best practice
Geef een aanmelding of gebruiker op met de minste bevoegdheden die nodig zijn om de bewerkingen uit te voeren die in de module zijn gedefinieerd. Geef bijvoorbeeld geen account voor de database-eigenaar op, tenzij deze machtigingen zijn vereist.
Permissions
Als u een module wilt uitvoeren waarmee EXECUTE ASis opgegeven, moet de aanroeper machtigingen hebben EXECUTE voor de module.
Als u een CLR-module wilt uitvoeren die is opgegeven met EXECUTE AS die toegang tot resources in een andere database of server, moet de doeldatabase of -server de verificator vertrouwen van de database waaruit de module afkomstig is (de brondatabase).
Als u de EXECUTE AS component wilt opgeven wanneer u een module maakt of wijzigt, moet u machtigingen hebben IMPERSONATE voor de opgegeven principal en ook machtigingen voor het maken van de module. Je kunt jezelf altijd imiteren. Wanneer er geen uitvoeringscontext is opgegeven of EXECUTE AS CALLER is opgegeven, IMPERSONATE zijn machtigingen niet vereist.
Als u een login_name of user_name wilt opgeven die impliciete toegang tot de database heeft via een Windows-groepslidmaatschap, moet u machtigingen hebben CONTROL voor de database.
Voorbeelden
In het volgende voorbeeld wordt een opgeslagen procedure gemaakt in de AdventureWorks2022-database en wordt de uitvoeringscontext toegewezen aan OWNER.
CREATE PROCEDURE HumanResources.uspEmployeesInDepartment
@DeptValue INT
WITH EXECUTE AS OWNER
AS
SET NOCOUNT ON;
SELECT e.BusinessEntityID,
       c.LastName,
       c.FirstName,
       e.JobTitle
FROM Person.Person AS c
     INNER JOIN HumanResources.Employee AS e
         ON c.BusinessEntityID = e.BusinessEntityID
     INNER JOIN HumanResources.EmployeeDepartmentHistory AS edh
         ON e.BusinessEntityID = edh.BusinessEntityID
WHERE edh.DepartmentID = @DeptValue
ORDER BY c.LastName, c.FirstName;
GO
-- Execute the stored procedure by specifying department 5.
EXECUTE HumanResources.uspEmployeesInDepartment 5;
GO