Does SA account need to be called “SA” or can I rename it safely?

Question

We have some applications on our network (from before my time) that use SA account in their SQL Server connection string. It's hard-coded in the source code, and for whatever reason, we can't change it - my question isn't about why we should change it, but about working around it.

I'm considering renaming the SA account to something else (like "SysAccount" or something like that, and giving it a new password) and then creating a new account called "SA" with the old password and granting it rights appropriate for the application (obviously not membership in the sysadmin role). Are there any pitfalls to doing this? Are there known problems SQL Server will have if the account called SA isn't actually a sysadmin?

I assume that since I'm just renaming the account, I'm safe - it will still have a uid of 0x01, and I've tested this and it's physically possible and appears to work properly in testing, but I want to make sure I'm not overlooking anything that will clearly break as a result. If it breaks things, I can always delete the new SA and rename the old one back to undo the damage, but hoping to avoid trying and failing.

I'm using SQL Server 2012, though I suspect the same answer will apply to any modern version. I've seen the bug where the upgrade from 2005 to 2008 can break if you've done this, but I imagine that's long since resolved.

Answer 1

It can be renamed. It's often considered a Best Practice for security, but there can be SQL Agent fallout if you don't bounce the Agent service or change job owners, and I can find reports of it borking Server 2008 upgrades, too.

That's enough to make me not want to bother renaming it. I say assigning a complex password and disabling the login is enough, and it's generally a better option since it actually closes the vulnerability instead of merely obfuscating it. Obfuscation gains you very little security. In the future, if you truly need an SQL authorization sysadmin, create a new account for it. That's not particularly difficult. You have the same attack surface as renaming without having to remember that SID 0x01 isn't sa anymore (even though it still is sa). And, of course, since the SID never really changes, it's not difficult to find which account is SID 0x01 (or a member of the sysadmin role, for that matter). Of course, if possible, don't even use mixed mode. Best practice is to use Windows authentication only mode, AFAIK.

Answer 2

Yes, the 2005 to 2008 problem is fixed. Now you can disable the SA account, you can rename it to SomethingElse, you can give it Chinese password, or you can mix and match.

See: http://www.mssqltips.com/sqlservertip/2221/different-ways-to-secure-the-sql-server-sa-login/

Notice that since the SID of SA (whatever you rename it) still remains, the new name can be discovered by:

SELECT * FROM sys.syslogins WHERE sid = 0x01

You rightly cannot get rid of the built-in administrator login, of course. So you just need to decide whether the minor side-effects are a problem for you.

I never use "SA" for my work, but use my own special domain account with sysadmin permissions.

Answer 3

I can think of one thing that may cause problems - does the application call IS_SRVROLEMEMBER('sysadmin') to check the account is a member of the 'sysadmin' fixed server role? If so this won't work if 'sa' becomes a different account.