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.
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?
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 at 17:28sais 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 insa's place, or share that one in the same way, it's not like finding sysadmin role members is tough for anyone withconnectrights. 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 at 18:21sapassword right now because some app or process or person relies on it, that's the problem you need to fix, that they're connecting assysadmin, not explicitly assa. If they connect to a differentsysadminaccount, the problem remains. – Aaron Bertrand♦ Feb 21 at 18:30