Windows Server 2022上SSIS权限问题：ETL包执行身份异常

你的核心问题是：迁移到Windows Server 2022后，虽然.NET服务以专用账户正常运行并能触发SSIS包执行，但包本身以匿名身份运行，导致权限失败。以下是针对性的排查和解决步骤：

1. 确认SSIS包执行的实际身份 #

先通过SQL查询定位包执行时的真实账户：

SELECT execution_id, login_name, status, start_time 
FROM ssisdb.catalog.executions 
ORDER BY start_time DESC;

查看结果中的login_name字段，如果显示为NT AUTHORITY\ANONYMOUS LOGON，说明身份传递完全失效；如果是其他账户，进一步验证该账户的权限配置。

2. 检查SSIS目录执行配置 #

• 调用ssisdb.catalog.start_execution时，确保未显式指定错误的执行上下文。若依赖代理账户执行包，需确认：
  • Win2022上的SQL Server代理已同步原2016的专用代理账户，且该账户被添加到ssisdb数据库的ssis_admin角色或具备EXECUTE权限。
  • 执行包时是否指定了@proxy_name参数，确保包使用正确的代理身份运行。
• 检查SSIS目录的catalog.configure_catalog设置，确认TRUST_SERVER_CERTIFICATE等安全配置与原2016环境一致。

3. 修复Kerberos身份验证与委派配置 #

Windows Server 2022对Kerberos的默认限制更严格，需确保：

• 专用服务账户在AD中配置了约束委派：针对SQL Server服务（SPN为MSSQLSvc/<SQLServerFQDN>:<端口>）和文件共享服务（SPN为CIFS/<FileServerFQDN>）启用委派权限。
• 验证SQL Server和服务账户的SPN注册：

  # 检查SQL服务账户的SPN
  setspn -L <SQLServiceAccount>
  # 检查专用服务账户的SPN
  setspn -L <YourServiceAccount>
  

  确保存在对应服务器FQDN的SPN，避免NTLM降级导致匿名身份。

4. 调整Windows Server 2022本地安全策略 #

对比原2016服务器的本地安全策略，调整以下项：

• 用户权限分配：确保专用账户拥有替换进程级别令牌、作为批处理作业登录、调整进程内存配额权限。
• 安全选项：将网络安全:LAN管理器身份验证级别设置为与2016一致（推荐：发送NTLMv2响应\拒绝LM和NTLM），避免身份验证协议不兼容。

5. 验证.NET服务的身份传递逻辑 #

• 检查C#代码中的SQL连接字符串，确保使用Integrated Security=True，且未手动设置User ID/Password，保证服务账户的Windows身份被正确传递到SQL Server。
• 确认服务未启用不必要的身份模拟：若代码中使用Impersonation，需验证模拟逻辑在Win2022上是否正常工作，或暂时移除模拟测试。

6. 手动验证权限 #

用专用账户直接登录Win2022服务器，执行以下操作：

1. 通过SSMS连接SQL Server，手动调用ssisdb.catalog.start_execution触发包执行。
2. 访问ETL包依赖的文件共享，确认具备读写权限。
3. 登录目标SQL Server实例，验证账户的数据库访问权限。
   如果手动操作成功，说明问题出在.NET服务的身份传递链中；若手动失败，则聚焦于账户的AD权限或SSIS配置。

内容的提问来源于stack exchange，提问作者Eli Silverman