通过代理执行 SSIS 时代理帐户失败

发布于 2024-10-06 09:52:46 字数 210 浏览 0 评论 0原文

最近,当我创建一个 SQL Server Agent(2008) 作业来使用代理帐户执行 SSIS 包时,它失败并显示以下错误消息。这个例外是关于什么的?是什么原因造成的以及如何解决?

错误信息 以用户身份执行:blaw。无法为作业 0xD5A5 的步骤 1 创建进程(原因:客户端不拥有所需的权限)。这一步失败了。

注意:-它与代理服务帐户运行良好。

谢谢

Recently when I created a SQL Server Agent(2008) job to execute a SSIS package with proxy account, it failed with the below error message. What is this exception about? What causes it and how do I resolve it?

Error Message
Executed as user: blaw. The process could not be created for step 1 of job 0xD5A5 (reason: A required privilege is not held by the client). The step failed.

Note:-It is working fine with Agent Service account.

Thanks

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

情未る 2024-10-13 09:52:46

您没有具体提到如何进行身份验证,但无论如何,这里有一个用于创建登录名、凭据和代理并向 SSIS 包授予权限的脚本:

CREATE LOGIN [MyLogin] FROM WINDOWS WITH DEFAULT_DATABASE=[master], DEFAULT_LANGUAGE=[us_english]
GO

GRANT CONNECT TO [MyLogin]
go

CREATE ROLE MyRole
GO

EXEC sp_addrolemember @membername = N'MyLogin', @rolename = N'MyRole'
GO

CREATE CREDENTIAL MyCredential WITH IDENTITY = 'MyLogin', SECRET = 'MyPassword';

GO

USE [msdb]
GO

EXEC msdb.dbo.sp_add_proxy @proxy_name=N'MyProxy',@credential_name=N'MyCredential', 
        @enabled=1
GO

EXEC msdb.dbo.sp_grant_proxy_to_subsystem @proxy_name=N'MyProxy', @subsystem_id=11
GO

EXEC msdb.dbo.sp_grant_login_to_proxy @proxy_name=N'MyProxy', @login_name=N'MyLogin'
GO


CREATE ROLE MyRole
GO

EXEC sp_addrolemember @membername = N'MyRole', @rolename = N'db_ssisadmin'
GO

EXEC sp_addrolemember @membername = N'MyRole', @rolename = N'db_ssisoperator'
GO

EXEC sp_addrolemember @membername = N'MyLogin', @rolename = N'MyRole'
GO

You've not mentioned exactly how you're authenticating, but regardless, here's a script for creating a login, credential and proxy and granting permissions to SSIS packages:

CREATE LOGIN [MyLogin] FROM WINDOWS WITH DEFAULT_DATABASE=[master], DEFAULT_LANGUAGE=[us_english]
GO

GRANT CONNECT TO [MyLogin]
go

CREATE ROLE MyRole
GO

EXEC sp_addrolemember @membername = N'MyLogin', @rolename = N'MyRole'
GO

CREATE CREDENTIAL MyCredential WITH IDENTITY = 'MyLogin', SECRET = 'MyPassword';

GO

USE [msdb]
GO

EXEC msdb.dbo.sp_add_proxy @proxy_name=N'MyProxy',@credential_name=N'MyCredential', 
        @enabled=1
GO

EXEC msdb.dbo.sp_grant_proxy_to_subsystem @proxy_name=N'MyProxy', @subsystem_id=11
GO

EXEC msdb.dbo.sp_grant_login_to_proxy @proxy_name=N'MyProxy', @login_name=N'MyLogin'
GO


CREATE ROLE MyRole
GO

EXEC sp_addrolemember @membername = N'MyRole', @rolename = N'db_ssisadmin'
GO

EXEC sp_addrolemember @membername = N'MyRole', @rolename = N'db_ssisoperator'
GO

EXEC sp_addrolemember @membername = N'MyLogin', @rolename = N'MyRole'
GO
意中人 2024-10-13 09:52:46

刚刚解决了这个问题并得出了不同的解决方案。全球安全政策阻碍了这一进程。事实证明,出现此问题的开发服务器意外地应用了比运行良好的生产服务器更为严格的策略。不确定该策略下的哪个覆盖权限导致了该问题,但限制较少的策略仍然解决了该问题。基本上,请咨询您的 Active Directory 管理员,看看本地安全策略是否在出现问题的服务器上被锁定。

Just worked through this issue and came to a different resolution. A global security policy was getting in the way. It turns out the development server that was presenting this issue accidentally had a much more restrictive policy being applied than the production counterpart that was working fine. Not exactly sure which overridden permission under the policy was causing the issue, but a less restrictive policy resolved the issue nonetheless. Basically, check with your Active Directory admin if the Local Security Policy is locked down on the server presenting the issue.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文