SQL Server中EXECUTE AS与直接登录userA权限不一致问题咨询

这种权限不一致的情况其实挺常见的，核心问题出在**EXECUTE AS USER模拟的权限上下文，和直接以SQL Server身份验证登录时的上下文完全不同**，下面给你拆解最可能的几个原因，以及对应的排查方法：

1. 你的SQL Server登录名userA拥有服务器级高权限 #

当你直接用SQL Server身份验证登录userA时，这个登录名可能被加入了sysadmin、dbcreator这类服务器角色。这些角色的成员会被自动授予所有数据库的全权限——哪怕你在数据库层面给userA显式加了DENY UPDATE，服务器级的高权限会直接覆盖数据库级的限制。

而EXECUTE AS USER = 'userA'只是模拟数据库用户的权限，不会继承其对应登录名的服务器角色权限，所以此时你的DENY规则能正常生效。

你可以跑这条SQL检查登录名的服务器角色：

SELECT roles.name AS ServerRole
FROM sys.server_principals logins
JOIN sys.server_role_members members ON logins.principal_id = members.member_principal_id
JOIN sys.server_principals roles ON members.role_principal_id = roles.principal_id
WHERE logins.name = 'userA';

2. 数据库用户userA属于高权限数据库角色 #

如果userA是db_owner角色的成员，那数据库层面的DENY对它根本不起作用——db_owner是数据库内的最高权限角色，成员拥有该库的所有操作权限，不受任何DENY规则限制。

另外，如果userA在被DENY之前就加入了db_datawriter这类自带UPDATE权限的角色，虽然理论上DENY优先级高于角色的GRANT，但如果同时存在服务器级权限的叠加，也可能出现绕过的情况。

检查数据库角色归属的SQL：

SELECT roles.name AS DatabaseRole
FROM sys.database_principals users
JOIN sys.database_role_members members ON users.principal_id = members.member_principal_id
JOIN sys.database_principals roles ON members.role_principal_id = roles.principal_id
WHERE users.name = 'userA';

3. 登录名和数据库用户的映射不匹配 #

你设置DENY的是数据库用户userA，但直接登录的SQL Server登录名userA可能根本没映射到这个数据库用户！比如：

• 如果登录名userA是sysadmin角色，登录后会默认映射到数据库的dbo用户，而dbo拥有所有权限；
• 或者数据库里存在另一个同名的userA用户，你把DENY加错了对象。

验证映射关系的SQL（在DW数据库中执行）：

SELECT dp.name AS DatabaseUser, sp.name AS LoginName
FROM sys.database_principals dp
JOIN sys.server_principals sp ON dp.sid = sp.sid
WHERE dp.name = 'userA';

如果结果为空，说明登录名userA没映射到目标数据库用户，自然不受DENY限制。

按这个顺序排查：

• 先查登录名的服务器角色，排除高权限角色的影响；
• 再查数据库用户的角色归属，确认是否有db_owner这类绕权限的角色；
• 最后验证登录名和数据库用户的映射关系，确保你限制的是正确的对象。

内容的提问来源于stack exchange，提问作者Angie Chuah