Creating SQL Server Agent Proxies

A SQL Server Agent proxy defines the security context for a job step. A proxy provides SQL Server Agent with access to the security credentials for a Microsoft Windows user. Each proxy can be associated with one or more subsystems. A job step that uses the proxy can access the specified subsystems by using the security context of the Windows user. Before SQL Server Agent runs a job step that uses a proxy, SQL Server Agent impersonates the credentials defined in the proxy, and then runs the job step by using that security context.

Note

After upgrading from Microsoft SQL Server 2000 to Microsoft SQL Server 2005, all user proxy accounts that existed before upgrading are changed to the temporary global proxy account UpgradedProxyAccount. The UpgradedProxyAccount is only granted access to those subsystems that were explicitly used, and does not have access to all subsystems after upgrading.

About SQL Server Agent Proxies

Note

Job steps that execute Transact-SQL do not use SQL Server Agent proxies. Transact-SQL job steps run in the security context of the owner of the job. To set the security context for a Transact-SQL job step, use the database_user_name parameter in the sp_add_jobstep stored procedure. For more information, see sp_add_jobstep (Transact-SQL).

SQL Server Agent proxies use credentials to store information about Windows user accounts. The user specified in the credential must have "Log on as a batch job" permission on the computer on which SQL Server is running.

SQL Server Agent checks subsystem access for a proxy and gives access to the proxy each time the job step runs. If the proxy no longer has access to the subsystem, the job step fails. Otherwise, SQL Server Agent impersonates the user that is specified in the proxy and runs the job step.

Creation of a proxy does not change the permissions for the user that is specified in the credential for the proxy. For example, you can create a proxy for a user that does not have permission to connect to an instance of SQL Server. In this case, job steps that use that proxy are unable to connect to SQL Server.

A user must have access to a proxy to use the proxy in a job step. Access can be granted to three types of security principals:

• SQL Server logins
• Server roles
• Roles within the msdb database

If the login for the user has access to the proxy, or the user belongs to any role with access to the proxy, the user can use the proxy in a job step.

Note

Members of the sysadmin fixed server role have access to all proxies in the instance.

The following section provides links to common tasks for working with proxies.

To create a proxy

• How to: Create a Proxy (SQL Server Management Studio)
• sp_add_proxy (Transact-SQL)

To modify a proxy

• How to: Modify a Proxy (SQL Server Management Studio)
• sp_update_proxy (Transact-SQL)

To delete a proxy

• How to: Delete a Proxy (SQL Server Management Studio)
• sp_delete_proxy (Transact-SQL)

To set permissions for a user

• How to: Configure a User to Create and Manage SQL Server Agent Jobs (SQL Server Management Studio)

See Also

Tasks

How to: Create a Credential (SQL Server Management Studio)

Concepts

SQL Server Agent Subsystems

Other Resources

CREATE CREDENTIAL (Transact-SQL)

Help and Information

Getting SQL Server 2005 Assistance

Change History

Release	History
14 April 2006	Changed content: Removed the section, "Using Proxies When the SQL Server Agent Service Runs under a Windows Local User Account," which described the following limitation: Jobs that use proxies will fail if the SQL Server Agent service is run under a local user account, and the SQL Server service is run under a different account. This issue has been fixed in SQL Server 2005 Service Pack 1.
5 December 2005	New content: Added the section, "Using Proxies When the SQL Server Agent Service Runs under a Windows Local User Account."