SQL Server Agent Proxy - Una cuenta confusa
por Luis Ramirez
SQL Server Agent nos permite configurar una cuenta PROXY la cual podemos usar para dar permiso a usuarios que no tienen el rol de sysadmin para ejecutar cmdshell o Scripts de Microsoft ActiveX bajo el contexto de seguridad de dicha cuenta.
¿En donde se podría aplicar?
Supongamos que tenemos el siguiente escenario:
- Un Archivo en una carpeta compartida en otro servidor.
- SQL Server Agent corriendo con cuenta local de la Maquina.
- Un paquete calendarizado en un SQL JOB que necesita acceder el recurso.
Como los jobs correrán bajo el contexto del cual el Agente este corriendo, en este caso cuenta local, este job marcara acceso denagado:
Executed as user: SQL2000RA\SYSTEM. DTSRun: Loading... DTSRun: Executing... DTSRun OnStart: DTSStep_DTSDataPumpTask_1 DTSRun OnError: DTSStep_DTSDataPumpTask_1, Error = -2147467259 (80004005) Error string: Error opening datafile: Access is denied.
Para solucionar esto podemos:
- Correr SQL Server con una cuenta de Dominio con acceso al recurso compartido.
- Configurar una cuenta de dominio con acceso al archivo como cuenta proxy dentro de SQL Server para poder ejecutar el Job.
Si vamos a configurar una cuenta proxy tenemos que validar ciertas condiciones:
1) En la creación del DTS tener cuidado en utilizar recursos enlazados a letras de unidades (MAP) para evitar errores como:
Error String:'Z:\Folder\Archivo.MDB' is not valid path. Make sure that the path name is spelled correctly and that you are connected to the server on which the file resides. error source: Microsoft Jet Database Engine.
Esto se debe a que, cada cuenta tiene un diferente contexto de unidades enlazadas, pero lo mas importante es que los servicios no funcionan con perfiles de usuarios por lo tanto no tendrán unidades enlazadas.
2) Si tenemos componentes COM en Script ActiveX revisar que la cuenta tenga los permisos apropiados la cuenta proxy pueda ejecutarlos
3) La cuenta Proxy debe tener los permisos apropiados para conectarse a SQL Server.
Hay que tomar en consideración que habilitar esta cuenta también puede incrementar riesgos de seguridad.
Ejemplo
Estos son los pasos que seguí para poder ejecutar mi DTS calendarizado “PAQUETE” que transfiere información de un archivo de texto info.txt localizado en la carpeta compartida en servidor DCBASE a mi servidor de base de datos SQL Server 2000.
1) SQL Agent ejecutandose bajo Local Account:
2) Carpeta compartida en Servidor Remoto DCBASE:
3) La Carpeta tiene permisos solo para la cuenta Dominio\Usuario:
4) Se realizo un paquete sencillo que acede al archivo y lo exporta a la base de datos local:
5) Se calendarizo el paquete:
6) De las cosas importante a notar en las propiedades del paquete el dueño del paquete tiene que ser una cuenta que no sea SYSADMIN o la cuenta Proxy.
7) Me conecte al Enterprise manager con la cuenta Proxy que elegí Dominio\Usuario, nótese que el Job fue invocado por esta cuenta:
8) En los Detalles del error vemos que intente correrlo con la cuenta local, la cual obviamente no tiene acceso al servidor remoto:
9) Habilitamos la cuenta proxy, esto se hace dando botón derecho a SQL Agent -> propiedades y después al tabulador Job System. Ahí deseleccionamos la opción de:
Only Users with SysAdmin privileges can execute CmdExec and ActiveScripting job steps.
10) Inmediatamente nos viene la opción para poner la cuenta proxy que usaremos para correr el job.
11) Volvemos a correrlo nótese que ahora lo invoque por SA:
12) En los detalles del job muestra la cuenta PROXY Dominio\Usuario que fue usada para ejecutarlo.
Artículos Relacionados
- How to enable non-sysadmin accounts to execute the "xp_cmdshell" extended stored procedure in SQL Server 2000
- INF: How to Run a DTS Package as a Scheduled Job
- Reset proxy and the SQLAgentCmdExec account
DCOM