AD组用户无法通过应用访问执行SQL Server存储过程求助

咱们一步步来定位问题，先从最基础的环节开始排查：

1. 确认连接字符串的正确性 #

先检查你的连接字符串里Integrated Security的取值是否规范，正确的写法是这两种：

Data Source=YourServerName;Initial Catalog=YourDatabaseName;Integrated Security=True;

或者等价的Trusted_Connection=True，避免拼写错误或者用了无效取值（比如SSPI虽然兼容，但建议用标准的True）。

2. 验证应用运行身份是否在目标AD组内 #

Integrated Security是用应用运行的Windows身份去访问SQL Server的，所以得确认这个身份是否属于你配置的AD组：

• 如果是IIS托管的Web应用：去IIS管理器看应用池的标识（比如Network Service、Local System，或者自定义的域账户），确认该账户已经加入目标AD组。
• 如果是Windows服务：检查服务的登录账户是不是目标AD组的成员。
• 如果是桌面应用：当前登录的Windows用户必须在AD组里，而且得注销重新登录——AD组的权限变更不会实时生效，必须重新登录才能加载新的组信息。

3. 检查SQL Server侧的AD组Login及权限配置 #

3.1 确认AD组Login存在且启用 #

在SQL Server里执行这个查询，看看你的AD组对应的Login是否存在，而且是启用状态：

SELECT name, type_desc, is_disabled 
FROM sys.server_principals 
WHERE name = 'DOMAIN\YourADGroupName';

如果is_disabled是1，右键Login选择“启用”就行；如果查不到这个Login，就得重新创建AD组对应的服务器登录名。

3.2 确认数据库用户及角色权限 #

AD组Login需要映射到目标数据库的用户，还要确保这个用户被分配了有存储过程执行权限的角色：

1. 先在目标数据库里查有没有AD组对应的用户：

SELECT name, type_desc 
FROM sys.database_principals 
WHERE name = 'DOMAIN\YourADGroupName';

2. 再检查用户所属的角色，以及角色有没有EXECUTE权限：

-- 查看用户所属角色
SELECT dp.name AS UserName, dr.name AS RoleName
FROM sys.database_principals dp
JOIN sys.database_role_members drm ON dp.principal_id = drm.member_principal_id
JOIN sys.database_principals dr ON drm.role_principal_id = dr.principal_id
WHERE dp.name = 'DOMAIN\YourADGroupName';

-- 查看角色对目标存储过程的权限
SELECT pr.name AS RoleName, o.name AS ProcedureName, perm.permission_name
FROM sys.database_permissions perm
JOIN sys.objects o ON perm.major_id = o.object_id
JOIN sys.database_principals pr ON perm.grantee_principal_id = pr.principal_id
WHERE o.type = 'P' AND o.name = 'YourProcedureName';

如果权限缺失，给角色加上EXECUTE权限：

GRANT EXECUTE ON OBJECT::YourProcedureName TO YourRoleName;

4. 排查Kerberos认证问题（远程连接场景） #

如果应用和SQL Server不在同一台机器，大概率需要Kerberos认证才能正常传递AD组权限：

• 在SQL Server里执行SELECT auth_scheme FROM sys.dm_exec_sessions WHERE session_id = @@SPID;，如果返回NTLM，说明Kerberos没生效。
• 给SQL Server服务账户注册SPN（服务主体名称），比如：

  setspn -A MSSQLSvc/YourServerName:1433 DOMAIN\SQLServiceAccount
  setspn -A MSSQLSvc/YourServerName.Domain.com:1433 DOMAIN\SQLServiceAccount
  

  注册完重启SQL Server服务，再检查认证方式是不是变成KERBEROS了。

5. 手动连接测试验证 #

让AD组里的用户用SSMS以Windows认证方式连接SQL Server，直接尝试执行目标存储过程：

• 如果SSMS也报错，说明问题出在AD组或者SQL Server的权限配置上。
• 如果SSMS能正常执行，那问题肯定在应用的运行身份上，回到步骤2重新检查。

6. 查看应用的具体错误日志 #

应用崩溃时的具体错误信息是关键，比如：

• 错误18456：登录失败，说明身份没被SQL Server识别，重点检查AD组Login和应用身份。
• 错误229：权限不足，说明登录成功了，但没权限执行存储过程，回到步骤3检查权限配置。

内容的提问来源于stack exchange，提问作者Mo L