JohnFTamburo (12/31/2013)
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
You'll get no argument from me that DBAs should have "SA" privs... especially since it allows them to do useful things with xp_CmdShell. 😉 Nor will you get an argument from me that you should hire someone that you can trust with the proverbial keys to the city.
I just hate to see something like the incredibly useful xp_CmdShell take it on the chin as a "security risk" when it's usually something else that's the real security risk.
--Jeff Moden
Change is inevitable... Change for the better is not.