![]()
madecapital.com
thefinancialtrading.com
grandesbodas.com
mundoface.com
goodtradings.com
good-trades.com
lasjugueterias.com
takenprofit.com
takesprofit.com
thetradingexperience.com
sqlenlinea.com
Hola!
Tengo algunas dudas sobre lo que explicas. Disculpame, soy un poco novata en el asunto.
El usuario svc_sqlserver siempre es con el que se ejecutan los comandos shell desde SQL 2005?
Este usuario debe existir en mi Active Directory de Windows?
Hay alguna manera de hacerlo ejecutar el xp_cmdshell con otro usuario?
Gracias Ivaldosan !
Comentarios
No hay problema, puedes realizar las preguntas que quieras !.
El usuario svc_sqlserver es el usuario que levanta los servicios de SQL Server y por ende al ejecutar el extended stored procedure 'xp_cmdshell' sale al shell de windows con sus privilegios y se aconseja para ejecutar job's batch realizarlos con esta cuenta.
El usuario que levanta los servicios de SQL si debe existir en el AD, que en este caso, nosotros damos como ejemplo a un usuario que llamamos svc_sqlserver.
Sí, al ´xp_cmdshell´ puedes darles permisos a otros usuarios para que puedan ejecutarlo. De la siguiente manera:
Se debe correr el siguiente stored procedure con una cuenta de autenticación trusted-windows sobre el SQL Server 2005, para que cree la credencial necesaria y de esta manera salir al OS y realizar operaciones en el shell:
EXEC sp_xp_cmdshell_proxy_account 'MTS_MIAPLIC', '12345678'
Reemplazar 'MTS_MIAPLIC' por la cuenta deseada y '12345678' por la clave deseada.
Luego se generara una credencial con el nombre ##xp_cmdshell_proxy_account##
Luego asignarle permisos de ‘execute’ sobre el extended stored procedure ‘xp_cmdshell’ a la cuenta deseada en este caso 'MTS_MIAPLIC'.
GRANT EXECUTE ON xp_cmdshell TO MTS_MIAPLIC
Una última aclaración, las credenciales pueden estar asignadas a varios login´s pero los login´s solo a una credencial.
Abrazo virtual !
nalonso
El usuario svc_sqlserver es un usuario que levanta el DBMS. Si es un job agendado en SQL Server te lo va a ejecutar con los privilegios de esta cuenta, es decir va a salir al shell o command prompt y ejecutara comandos con los permisos y user rights que posea esta cuenta en windows.
El usuario debe existir en AD.
Hay que tener en cuenta que debes habiliar esta opción (xp_cmdshell) por la SAC o el stored procedure 'sp_configure' en SQL Server 2005, en tanto, para SQL Server 2008 puedes realizarlo directamente por el managent studio o utilizar el mismo stored procedure.
Acordate del ejemplo que dimos en el blog:
"
Si bien podemos solucionarlo dando permisos de ‘execute’ al ‘xp_cmdshell’ y crear una credencial y asociarlo a la cuenta windows de la aplicación 'MTS_MIAPLIC', NO SE PUEDE ejecutar a través de un job batch agendado en SQL Server, pues, siempre impersona la cuenta que ejecuta el servicio de scheduler de SQL Server y no funciona.
Para los que quieran crear la credencial para la cuenta aplicación y llamarlo de otra manera y no por batch job, es decir SIN EJECUTAR por ej: "exec sp_start_job ‘mijobaplicacion’"; deben correr el siguiente stored procedure con una cuenta de autenticación trusted-windows sobre el SQL Server 2005, para que cree la credencial necesaria y de esta manera salir al OS y borrar los archivos sobre el directorio citado con anterioridad:
EXEC sp_xp_cmdshell_proxy_account 'MTS_MIAPLIC', '12345678'
Generara una credencial con el nombre ##xp_cmdshell_proxy_account##
Luego asignarle permisos de ‘execute’ sobre el extended stored procedure ‘xp_cmdshell’ a la cuenta 'MTS_MIAPLIC'.
GRANT EXECUTE ON xp_cmdshell TO MTS_MIAPLIC
Una última aclaración, las credenciales pueden estar asignadas a varios login´s pero los login´s solo a una credencial. "
Espero te sirva, Jlopez
nalonso