Disable the sa Login [30 SQL Server Security Checks in 30 Days]

Please disable the sa login

Having the sa login enabled is one of the most frequent issues we see when reviewing SQL Server instances. Nearly every SQL Server instance has an sa login, and has it in the sysadmin role. So what’s the problem?

When hackers have identified a SQL Server instance, they often want to escalate their privileges to obtain access to all databases or take advantage of configuration options to install malware. One of the most basic things they can do is launch a brute force attack on the sa login, trying to guess the password. If the password used for the sa login isn’t complex enough, the bad guys can get access to the most powerful login in your instance and start doing bad things.

Even if you have a very secure password for sa, it’s still a safer choice to disable the sa login. Disabling isn’t as drastic as it sounds, as disabling a login effectively means “disable from being used for connections”. Disabled logins still retain their permissions within SQL Server, so they can own databases, schemas, jobs, etc.

This shouldn’t be a problem…unless you or your colleagues are actively using the sa login. If that’s the case, stop doing that. Take the time to set up logins with only the appropriate permissions and use those instead. Better yet, use domain accounts that can be authenticated, which is something SQL Server logins can’t do. If you need to track the usage before disabling the sa login, you can use a SQL Audit or an Extended Event to find out where the login usage is originating.

I’ve met lots of folks who have tried a different solution: renaming the sa login instead of disabling. It’s true that it would be more difficult to guess the name of that login, but as someone who has inherited hundreds (maybe thousands?) of SQL Server instances, I am never amused to discover this has happened. Obfuscation may confuse the bad guys temporarily, but it also confuses the person who’s going to inherit your databases when you decide to move to greener pastures.

Also, don’t remove the sa login from the sysadmin role. It needs to be there since there are things in your SQL Server instance that require it to be in that role. Changing the permissions is unnecessary and could very likely cause things to stop working as expected.

There are even folks who want to have a login like sa as an account that can be used “just in case”. This isn’t the best of ideas because now you have another SQL Server login that anyone inside or outside your organization could potentially use with anonymity. If you really want to do that, then make sure you have a password of at least 16 characters that only use.

You can see if your sa login is enabled, and if anyone renamed it using the following:

SELECT
    [name]
    , is_disabled
FROM sys.server_principals
WHERE [sid] = 0x01;