Jeff Moden (12/31/2013)
What about DBAs using it to elevate their privs as you have just done? It's not the usage of xp_CmdShell that caused that risk. It's the fact that you think DBAs have to have "SA" privs to do their job. 😉
"DBA" is an abbreviation for "Database Administrator"... not "System Administrator". If your DBAs have SA privs and you don't actually want them to be a "security risk", then give them the correct privs for the job instead of blaming xp_CmdShell.
Stop blaming xp_CmdShell for otherwise poor security. Instead, fix the security holes that allow for its misuse.
Sorry, I was not intending to blame xp_cmdshell for anything.
With respect to the proper level of privileges to grant to a production DBA, I agree to disagree. A DBA should have the rights necessary to do her or his job. Generally that requires SA level privileges for the production level DBA, not for the world. The question then becomes: do you trust your DBA? In the case of the original poster of this thread, the poor guy cannot even start the SQL Server agent without jumping through hoops. This seems to me to be excessive control for its own sake, not prudent access management.
I've been in environments where connection strings explicitly log an application in as sa. Luckily, where I am now, that is no longer the case. A DBA's job sometime requires that person to stop and start services, etc. Machine admin is not unreasonable.
Thanks, no worries.
John