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.