2

Answers and comments at a recent popular question Does changing "sa" password require a SQL restart (in mixed mode)? indicate that renaming and disabling sa at build time is a best practice.

Any time you have a well-known account, like administrator on a Windows system or sa for SQL Server, you should take certain steps to secure it. Let's look at specifically what you should do with sa:

Set a hard to guess password.

Rename sa.

Disable sa.

Ensure that no other accounts exist named sa.

Source

But what if it has been years since the instance was built? the original DBA is long gone, I don't know what strange things they might have done. It's a production server, I can't just change make changes to the sa login and fix things as they come to light.

If I rename and disable the sa account years later, what issues might I have?

Can all the possible issues be identified and addressed, before making changes to the sa account?

Community
  • 1
James Jenkins
  • 6,228
  • 6
  • 45
  • 87
  • testing on development is a good start.. – kevinskio Feb 21 '19 at 17:20
  • 4
    Can all the possible issues be identified and addressed, before making changes to the sa account? No, some legacy app, somewhere, that only connects once a year, could still be out there. There will always be some cleanup, afterwards. – Sean Gallardy Feb 21 '19 at 17:28
  • 1
    I don't know that I really buy that renaming sa is valuable. If your password policy is good, and you don't blindly give it to everyone who asks for it, it shouldn't matter; if you give a crappy password to whatever account you use in sa's place, or share that one in the same way, it's not like finding sysadmin role members is tough for anyone with connect rights. This seems like security theater, like changing the port SQL Server is running on simply because it will take a port scanner half a second longer to find it. – Aaron Bertrand Feb 21 '19 at 18:21
  • @AaronBertrand I think it really comes down to what the non-disabled sa account gets assigned to run/own. If it is disabled it really does not matter. But if it's not disabled there can be issues. I recall something about the sa account being DB_Owner and that providing a back door, I believe there are several examples. – James Jenkins Feb 21 '19 at 18:27
  • Right. My point is giving it a different name (or creating a new SQL auth account with sysadmin) doesn't solve any problem, if all the material things that make it a problem don't also change. It is those material things that need to change, and changing them will fix the issues whether you rename sa or not. If you can't change the sa password right now because some app or process or person relies on it, that's the problem you need to fix, that they're connecting as sysadmin, not explicitly as sa. If they connect to a different sysadmin account, the problem remains. – Aaron Bertrand Feb 21 '19 at 18:30
  • "I feel like my red car draws the attention of the police, so I'm going to trade it in for a blue car, which will draw less attention. But I'm still going to drive 120mph." – Aaron Bertrand Feb 21 '19 at 18:34
  • @AaronBertrand This question is about renaming and disabling, not just renaming. Additionally as the original sa account ALWAYS has the same SID '0x01' it is much easier to write code to leverage on it. – James Jenkins Feb 21 '19 at 18:34
  • /shrug ok, I'll move along, have your fun. In general, I dislike "what could go wrong?" questions anyway. – Aaron Bertrand Feb 21 '19 at 18:35

0 Answers0