Jeff Moden (4/21/2014)

---

Eric M Russell (4/21/2014)

---

Jeff Moden (4/20/2014)

---

Tom Brown (4/15/2014)

---

However on this particular project they don't like linked servers/openquery etc - So I don't have the Access level required - and almost certainly the DBA here would not allow it into production.

Shifting subjects a bit, you'd love me as a DBA. 🙂 I give the Devs "SA" privs on the Dev box (ONLY) and tell them to "Go for it, the sky's the limit. Just don't do any DBA stuff. If you need something like a linked server, come see me and we'll hammer it out together." I also tell them "You write it, I'll figure out a way to run it safely or a way to rewrite it so it is". I also do 100% code reviews that I use as "one-on-one mentoring" time and, I can assure you, the Devs aren't the only ones learning during such sessions. 😉

What is a DBA to do when the Dev or BI team insists that they need access to the "SA" account, and managment agrees with them?

Below is one solution. 😉

use MASTER

go

alter login sa DISABLE;

go

alter login sa with name = [sa_bak];

go

create login sa with PASSWORD = '<strong password>', DEFAULT_DATABASE = master;

go

use CorpDb;

go

drop user sa;

go

create USER sa for login sa;

go

exec sp_addrolemember 'db_datareader', 'sa';

-- etc. whatever other minimal persmissions they need.

go

Oh you sneaky devil you! 😛 Nice!

Fortunately for me and for any of the jobs I've had, all I have to do is remind management that they won't pass a SOC 2, SOX, SEC, PCI, or any other type of audit if they grant users/apps "SA" privs on the servers that I'm responsible for (and that would be all of them) and they suddenly backoff and listen to what actually needs to be done. 😛