I’m running SQL Server 2012 (I know, ancient…) and trying to work out why users don’t have permission to execute some procedures.
I’m logged in as
sa, just in case my own id doesn’t have sufficient authority to impersonate.
When I try:
EXECUTE AS LOGIN = 'MBASAHFOS_GRP'
I get the message:
Cannot execute as the server principal because the principal "MBASAHFOS_GRP" does not exist, this type of principal cannot be impersonated, or you do not have permission.
As far as I can tell, it meets the requirements:
select * from sys.server_principals where name = 'MBASAHFOS_GRP' name principal_id sid type type_desc is_disabled create_date modify_date default_database_name default_language_name credential_id owning_principal_id is_fixed_role MBASAHFOS_GRP 413 0x0105000000000005150000007CEB240DCD7C4166235F636BC8040000 G WINDOWS_GROUP 0 2017-12-01 10:00:45.050 2017-12-01 10:00:45.057 cpr_prod us_english NULL NULL 0
sa, so surely I have permission. It exists. Which only leaves “cannot be impersonated”. Why can’t it be impersonated?
Below are the methods you can try. The first solution is probably the best. Try others if the first one doesn’t work. Senior developers aren’t just copying/pasting – they read the methods carefully & apply them wisely to each case.
This is not supported by design.
Specifies the statements inside the module execute in the context of
the user specified in user_name. Permissions for any objects within
the module are verified against user_name. user_name cannot be
specified for DDL triggers with server scope or logon triggers. Use
user_name must exist in the current database and must be a singleton
account. user_name cannot be a group, role, certificate, key, or
built-in account, such as NT AUTHORITYLocalService, NT
AUTHORITYNetworkService, or NT AUTHORITYLocalSystem.
There are workarounds you can use.