Capture setuser events with SQLServer Auditing

Since SETUSER is a deprecated feature, it is not captured through Audit Specification, although the BOL said so. It is not even possible through a trace (EventClassIds 132 & 133). But I would be less concerned as compared to EXECUTE AS, as SETUSER is only allowed to sysadmins and the database owner.

Now, for sysadmins, you cannot do much about, as they can always get around any audit specification.

For database owner, the strange thing is, although BOL states that the user must be a member of db_owner fixed database role, only the actual owner

SELECT SUSER_SNAME(OWNER_SID) 
FROM sys.databases 
WHERE [name] = 'DBNAME'

can use the SETUSER statement successfully (I am talking about the recent builds and If someone can make it work as stated in BOL, then please correct me by posting an example. Would be very much appreciated). Hence, you are left with only one user.

Now the solution part; I guess one of the few options would be the DDL triggers. You can LOG / ROLLBACK the statements by use of the ORIGINAL_LOGIN() function (Which will identify the actual user). A generic database trigger example is as follows. You can modify it according to your need

CREATE TRIGGER LogAllDDL ON DATABASE
WITH ENCRYPTION
FOR DDL_DATABASE_LEVEL_EVENTS
AS
DECLARE @data XML
SET @data = EVENTDATA()

INSERT  Audit.AuditDDLOperations
        (
         OriginalLoginName
        ,LoginName
        ,UserName
        ,PostTime
        ,EventType
        ,DDLOp
        )
VALUES  (
         ORIGINAL_LOGIN()
        ,SYSTEM_USER
        ,CURRENT_USER
        ,GETDATE()
        ,@data.value('(/EVENT_INSTANCE/EventType)[1]', 'nvarchar(100)')
        ,@data.value('(/EVENT_INSTANCE/TSQLCommand)[1]', 'nvarchar(2000)')
        )
RETURN ;
GO

Hope it helps.

Are you using an account that is dbo?

From BOL :

The scope of impersonation in the SETUSER statement is implicit. If the statement is called by a member of sysadmin, server-level impersonation is used. If the statement is called by an account that is dbo, database-level impersonation is used.

So maybe you need SERVER_PRINCIPAL_IMPERSONATION_GROUP rather than DATABASE_PRINCIPAL_IMPERSONATION_GROUP

Also you shouldn't have an issue if you stick with EXECUTE AS

SETUSER is included for backward compatibility only. SETUSER may not be supported in a future release of SQL Server. We recommend that you use EXECUTE AS instead.