The Command Shell

Question

The Command Shell

Viewing 2 posts - 76 through 76 (of 76 total)

You must be logged in to reply to this topic. Login to reply

Jeff Moden SSC Guru Points: 1004329 More actions · Answer 1

Jim P. (4/11/2013)
More than once we ran into an IT staff that said "We can't give you the SA password." We had a choice, go around you and change the SA password, or wait for you to give it to us. We didn't care if you changed it after the upgrade.
The problem is that if you don't trust your vendors you are not logical. We don't want to harm the end-user or anyone else. We want the upgrade to work.

You've just proven why some vendors actually are the enemy and don't deserve the trust nor the business. It's definitely not a logical fear. It's a time proven observation. Even with your best intentions at heart, it's not your box and you're not ultimately responsible for it or the data it contains. Yet you saw fit to break into the box as "SA" instead of working with the person who actually is responsible for the box. You could have even cost that person their job for doing their job.

Such actions on you and your team's part not only break the policies of nearly every company I've ever worked for or ever hope to work for, they break SOX, SEC, and ISO policies/regulations, as well. Had you been an outside vendor, your actions would have broken many State and Federal laws.

The logical way to have done this would have been to take the proper steps where the people you went around could have been alerted to properly sanctioned company actions. You and your upgrade team could have been granted "SA" privs without knowing the "SA" password instead of taking matters into your own hands.

I do, however, thank you tons for proving my point that no one other than the DBA's should ever be granted "SA" privs. 😉

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)

Eric M Russell SSC Guru Points: 125561 More actions · Answer 2

Regarding vendors who support a client owned server, or clients who lease a vendor hosted server, there can be an account setup with elevated permissions that you enable or disable for them as needed. However, they don't really need sysadmin membership just to deploy objects or run DBCC commands. That requires only db_ddladmin or db_owner membership. They don't need permissions that grant control of the server.

As for things like 3rd party applications or monitoring tools, they don't need sysadmin privilege at all. They just need a "poweruser" account with: data reader, maybe writer, view server state, showplan, view schema definition, and that should cover it. If their software is designed in a such a way that it just won't perform it's normal daily functions without membership in 'SA', then that calls into question whether the developers really know what they're doing. You don't want someone or something with less SQL Server knowledge than yourself running roughshod over your server.

When an organization is evaluating 3rd party applications, that should be a primary consideration:

How much privilege do they require over the server for their software to be functional?

"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho