opc.three (9/19/2012)

---

Lynn Pettis (9/19/2012)

---

opc.three (9/4/2012)

---

Jeff Moden (9/4/2012)

---

opc.three (9/4/2012)

---

All sysadmins can execute any commands they wish and those commands will run in the context of the SQL Server service account, i.e. you lose the ability to audit who did what.

Consider that all sysadmins can turn on xp_CmdShell at the drop of a hat. 😉

True, but there is an audit trail associated with that, namely an entry into the SQL Server Error Log is made noting that a system configuration was changed. You can also block this through Policy Management, which can be circumvented as well, but it adds an additional barrier. You're assuming all sysadmins are trusted, which is risky. Any barriers that can be placed in the way of a malicious user the better. Having xp_cmdshell enabled is just one more exposure that is better left disabled (IMHO).

Locked doors only keep honest people out.

If you have the privledges and the will to do something you shouldn't there isn't much to stop you.

Oh c'mon. The locked doors saying is great for a bumper sticker but in practice it just doesn't hold up. If it did then DBAs would not keep strict control over their sa passwords and instead would just have them on a post-it note tacked to their monitors. As an aside I would not have the issue to begin with because I disable sa, but that's yet another security topic we could debate endlessly.

At any rate, the above comments are besides the point. Enabling xp_cmdshell is simply not a secure enough option in any environment. It fails to meet a simple security requirement because it obfuscates the real initiator of an action taken at a cmd shell prompt...unacceptable.