May 27, 2008 at 12:28 pm
If you're really concerned, give it a long, one-time password that you don't write down. Randomly bang on 20 keys to get it.
Don't rename it or delete it. You'll get into trouble later. If you can go to Windows auth only, still set a strong password for SA. Never know when someone will change it back.
May 27, 2008 at 12:48 pm
Steve Jones - Editor (5/27/2008)
If you're really concerned, give it a long, one-time password that you don't write down. Randomly bang on 20 keys to get it.
I like that :hehe: You will honestly be able to say you don't know the password.
May 27, 2008 at 1:12 pm
Steve Jones - Editor (5/27/2008)
If you're really concerned, give it a long, one-time password that you don't write down. Randomly bang on 20 keys to get it.Don't rename it or delete it. You'll get into trouble later. If you can go to Windows auth only, still set a strong password for SA. Never know when someone will change it back.
You could also go the extra mile, and mark it as disabled for logins, and deny it access to the DB engine.
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
May 28, 2008 at 10:44 am
Piggy-backing on what's already been said here:
Introduce your users to The Principle of Least Privilege. It's a security principle that says you give the users the rights they need and no more. Now, if an end user can justify needing be able to create databases, manage security on the server, shutdown the SQL Server, etc., then they get the appropriate rights. They can't. You should be able to get backing from your security personnel or auditors if you're in a large enough organization.
Show them the tons of documentation which all state "Don't use the sa account, ever." This is a well known security practice not to use. You can rename and you can disable, but as Steve says, you'll likely get into trouble later. I've written a blog post about a security company that requires it for one of their security products, okay, a rant, but generally, this is a no-brainer.
As previously said, set a strong password. Use a password generator to ensure it is complex and long. 20 characters or more. Make two copies of the password. One sealed and stored on-site in the event of an emergency and one sealed and stoerd off-site with your backups in the event of a disaster. Do this even if you can go to Windows authentication only mode. It's a simple registry change to flip it to mixed mode and then the next time the service restarts, such as when the server reboots due to security patches, you're in mixed mode.
If possible, switch to Windows authentication only mode. SQL Server logins have known weaknesses travelling across the wire and besides, if you can go to Windows auth mode, that means you have one source for security: Active Directory.
K. Brian Kelley
@kbriankelley
May 28, 2008 at 10:51 am
thanks gues for the info and for ur help..its going to happen but things must go slowly.one step at a time.
..>>..
MobashA
June 3, 2008 at 6:04 am
🙂 hello professionals, i think it is a lecture for soft skills. lol
YoU CaN't LoSe WhAt YoU NeVeR HaD;)
June 3, 2008 at 9:35 am
You Should not be able to Delete SA login from the server, But you could be able to DISABLE the SA account from the server.
MCP, MCTS (GDBA/EDA)
June 23, 2008 at 7:23 am
My approach to being a DBA is that I am here to protect the companies data. These to me means that no one ever uses the sa account on any system that I managed. I told this to the management team before I was hired.
As the DBA you are not always popular. You are there to protect the money, which is exactly what information in a companies database is.
Take the hard line of changing the password, then rename sa to something else (good security practise anyway), any only use that account in an emergency. Limit right on databases to only what is required and even question that access.
If you do not protect the data and something happens to it, you are the one that is in trouble. Take the hard line, and in the log run you and your company will be better off for it.
Stacey W. A. Gregerson
June 23, 2008 at 7:51 am
Manoj (6/3/2008)
You Should not be able to Delete SA login from the server, But you could be able to DISABLE the SA account from the server.
Cool... how would you go about doing that?
--Jeff Moden
Change is inevitable... Change for the better is not.
June 23, 2008 at 7:53 am
gregers65 (6/23/2008)
My approach to being a DBA is that I am here to protect the companies data. These to me means that no one ever uses the sa account on any system that I managed. I told this to the management team before I was hired.As the DBA you are not always popular. You are there to protect the money, which is exactly what information in a companies database is.
Take the hard line of changing the password, then rename sa to something else (good security practise anyway), any only use that account in an emergency. Limit right on databases to only what is required and even question that access.
If you do not protect the data and something happens to it, you are the one that is in trouble. Take the hard line, and in the log run you and your company will be better off for it.
I absolutely agree there... Protect the data at all costs. If they don't agree, then maybe it's to start looking for a company that actually knows what a DBA is supposed to do.
Shifting gears... I've never tried renaming SA to something else... how would you do it?
--Jeff Moden
Change is inevitable... Change for the better is not.
June 23, 2008 at 8:24 am
Example:
ALTER LOGIN sa WITH NAME = peanutbuttercup
Available with 2005
Stacey W. A. Gregerson
June 23, 2008 at 8:54 am
Heh... Embarassingly simple. Thanks Stacey.
Mobasha... that's gotta be as good as deleting SA... still, your users are going to know that you can give SA privs to any login... I'm still thinking that this is a lost cause and you and your managers just need to tell folks, "No". 🙂
--Jeff Moden
Change is inevitable... Change for the better is not.
June 23, 2008 at 9:00 am
Just say NO.
you wouldn't expect the sys admin to give everyone full access to the AD.
January 10, 2014 at 5:25 am
Solution
Please try the link below;
http://egementanirer.blogspot.com/2014/01/removing-sysadmin-roles-from-sa-user.html
January 10, 2014 at 5:39 am
Please note: 5 year old thread.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
Viewing 15 posts - 16 through 29 (of 29 total)
You must be logged in to reply to this topic. Login to reply