Understanding jobs, owners, linked servers, security contexts
The SQL Server Agent service manages the job schedule and has an owner. The owner can be either a SQL Server logon name or a Windows NT account.
The security context at which the job is run is determined by the owner of the job.
If the job is owned by a member login that is not the sysadmin server role, it will run under the context of that owner.
If the job is owned by an account that is a member of the sysadmin role (SQL Server logon or Windows NT authentication logon), the SQL Agent job will run under the context used to start the SQL Agent service account.
For linked servers, it is recommended that you select the corresponding relationship between the startup account and the remote account. Security attribute, select the login that is not defined in the list, choose to establish a connection using the login current security context, and analyze the following:
If you use the System account (' NT authoritysystem ') to start the proxy service and the proxy connection uses Windows authentication, you will not have permission to access the remote computer.
If you use this account to start the agent service, the proxy connection uses Windows authentication, then the security context of the startup account is verified, the remote does not have the same account name and password of the startup account, and the validation fails.
If the job belongs to a Windows NT domain account, you must start the SQL Server service from a trusted domain with an account from the same domain.
For CmdExec and ActiveScripting job steps, if the execution job user is a member of the sysadmin role, it runs in the context of the account. If not an account in the sysadmin role, see: HTTP://SUPPORT.MICROSOFT.COM/KB/890775/ZH-CN
This article is from the SQL Server deep dives blog, so be sure to keep this source http://ultrasql.blog.51cto.com/9591438/1591641
The storage engine must know-understand the job, owner, linked server, security context