Bad Decisions: Not Just For The Young Hollywood Elite
I give you exhibit A: The Last Straw:
Yes, Third Party Software vendors out there are still trying to ruffie our SQL Servers. I encountered these instructions yesterday when reviewing a pending installation process. What you don’t see here though are items 1-11 in their instructions (one being a requirement for SQL Server 2000). Did I mention that these are the CURRENT INSTRUCTIONS?
For your benefit, here are items 1-11.
-
Application, database, web services, and file server must all be hosted on the same server. All components must run from same logical drive.
-
We don’t support RAID, whatever that is.
-
You must use the keyboard attached directly to the server. If you attempt to perform this installation remotely it will fail and we will know about it. We will send a skinhead to your local animal shelter to neuter stray puppies, with his teeth, for each failed remote installation you attempt.
-
Click following sequence on the keyboard to use Administrator Mode: Up Arrow, Up Arrow, Down Arrow, Down Arrow, B, A, Start
-
Place your Microsoft SQL Server 2000 floppy disk 1 into your 3.5″ drive slot on the server.
-
Navigate to A:\ and type Setup.exe
-
Click Next> 314 times. Repeat with disks 2-42, clicking Next> a random number of times until you run across the option to click Finish.
-
Click Finish.
-
Reminder: installation process will fail if monitor is turned on. This was instituted as an arrangement with the Society Of Blind DBAs (SOB-DBA) to conform with the ADA. Suck it up, Seers. We walk on the Dark Side here Beeyoches! If you did not know this until now then you should have read all the instructions first. Reformat your hard drive and start over.
-
We hate you. We just wanted you to know.
-
Do not install any SQL Server service packs. We don’t have time to test enhancements to SQL Server 2000 and will not support any newer releases.
Note: There was also a business card attached to the documentation for some guy named Uncle Touchy: Clown for Children’s Parties and Baby Sitting. Hand-scrawled on the back was “this is going to take you a while. Call this guy, he’s great with kids if you can’t make it home for a couple days.” They obviously know that if we’re willing to use sa for the sa user password we’re up for making any number of bad choices in our daily life: letting pedophiles in grease paint watch our kids, getting engaged to Tara Reid, buying tickets for a Nickleback concert… Anything.
So what do you do when it comes to service accounts for SQL Server? What should you do with the sa standard login? Secure your installs by assigning a domain user (NOT domain admin) with local administrator rights to the SQL Server Service. Use a different AD account for each SQL Server instance in your domain. As for the sa login be sure to give it a very-extremely-mondo-mega-hard password that is painful for you to enter so you’ll be loathe to do so. Then don’t use the sa login for anything. Don’t make it the owner of any databases if you can avoid it. Don’t make it the owner of any SQL Server Agent jobs. If you need a SQL login with sysadmin role rights (which is what the sa login is) then create a new one with a cryptic name so as to obscure it’s importance if your systems are compromised and give it an equally-hard password.
I don’t have a start button on my keyboard. Does that mean I can’t install?
I’ve actually seen some of your joke instructions in real vendor docs, including “everything must be on the same server” and “the service must be run under the LocalSystem account with sysadmin rights”. I even had one case where the application insisted on using sa, with a blank password. Yep, that’s right. Blank. This from the same vendor who insisted it made no difference performance wise that their database had no clustered indexes and no primary keys. I swear on my life if I ever own a software company I will make software that makes DBAs (and tech people in general) smile, instead of cringe in fear.
I am curious, you mentioned not having databases owned by sa? So would you have them owned by say, the domain account that SQL Server runs under, or another local user? We do have all the DBs owned by sa (except in a few cases where the applications demand otherwise), but at least we use big long nasty GUIDs as passwords.
Just don’t put anything other than sa in as the password. Otherwise you’ll get to the end of the install only to find out that all the connections to the database have the username and password hard coded into them. Furthermore it uses localhost as the servername, hence the requirements in step 1.
Not quite sure which fail point to respond to in that comment Bob. There are quite a few. 🙂