我们有一个运行仓库的旧式AS400主机系统。我们希望它能够安全地触发运行其余业务的SQL Server上的作业，以在两个系统之间实现自动及时的数据交换。
当前，我们已经在旧的Windows SQL 2005服务器上安装了IBM iSeries Access Windows客户端软件。这使AS400可以在Windows框中运行远程命令。 AS400使用此客户端软件来运行批处理文件，这些批处理文件在SQL 2005服务器框中执行dtexec，然后运行SSIS程序包，以在AS400与生产SQL服务器之间交换数据。 SQL 2005框仅用作AS400与生产SQL服务器之间的接口。此设置的两个问题是：
AS400客户端软件作为系统进程而不是网络帐户运行，因此SQL登录信息必须包含在SSIS文件的纯文本中。
运行dtexec时，它将两个条目添加到Windows事件日志中。我们有几个过程每隔几分钟或在某些情况下几秒钟就轮询一次新数据，因此事件日志会持续清除较旧的条目，从而留下大约4个小时的事件。这么说很难解决此框上的错误，这是轻描淡写。
我们正在淘汰旧的SQL 2005服务器，因此我必须在较新的服务器上复制此功能。我想先解决这两个问题。
我尝试使用sqlcmd，但是由于AS400客户端软件在本地系统进程下运行，因此无法连接到使用Windows身份验证模式设置的生产SQL服务器。我尝试使用psexec，如果我为用户打开一个RDP会话，但仍需要纯文本格式的用户名和密码，则可以使用该方法。我一直在测试让批处理文件将空白文件写入目录，并让WMI事件触发SQL作业。在测试中，这种方法行得通，但是在需要连续多次快速触发工作（例如我们的大多数工作都需要）时，这种方法并不可靠。
我也研究过使用Windows安全类和/或数据保护API（DPAPI）使用C＃和.NET来存储密码，但是我充其量只是中级.NET程序员，因此对于我。
这是将较旧的主机系统与SQL Server集成的一个普遍问题，因此我假设必须有一个解决方案，允许主机系统以安全的方法调用SQL Server。如果不是直接作业，请运行可以触发该作业的存储过程。不需要密码/用户名以纯文本格式保存在某处且不使用dtexec的任何替代方法都将受到欢迎。
答案 0 :(得分：1)
LocalSystem Account“在本地计算机上拥有广泛的特权，并且可以充当网络上的计算机。”
这意味着您可以通过为“计算机帐户”创建登录名来授予它对远程SQL Server的访问权限。如果您的服务器名为MyServer，域为MyDomain，则：
use msdb
create login [MyDomain\MyServer$] from windows
create user [MyDomain\MyServer$] for login [MyDomain\MyServer$]
alter role SQLAgentOperatorRole add member [MyDomain\MyServer$]
在另一台服务器上作为LocalSystem运行的进程将能够通过Windows Integrated Auth连接并运行SQL Agent作业。