What are the different ways to secure the SA login? Everyone is aware of the SA login and its administrator rights, so it is very risky if some unwanted users try to use the SA account or hack the SA account. It is also not advisable to use the SA account in any application or by users. In this tip we cover a few ways to reduce the risk.
The SA account is created during the installation process and the SA account has full rights in the SQL Server environment. The SA account is well known and often targeted by malicious users, so it is advisable to disable the sa account unless your application requires it.
You can use the following ways to secure the SA login.
Use Windows Authentication Mode
One way of doing this is to use "Window Authentication mode" from the Server Properties dialog which will allow access to only Windows logins and not SQL logins. Microsoft also recommends Windows authentication mode only. One thing to note is that even though you are using Windows authentication, you must use a strong password for the SA account, because anyone can change the authentication mode by updating the registry value and restarting the SQL Services.
To change this setting in SQL Server Management Studio, right-click the server, click Properties and go to Security page as shown below.
Disable the SA Login
Disabling the SA account is a good option to prevent its use. When it is disabled no one can use it in any circumstance until it is enabled. The only disadvantage is that we can't use the SA account in an emergency.
You can use the below T-SQL to disable SA account.
--Query to disable the SA account.
ALTER LOGIN sa DISABLE;
This query will check the status of the SA account. A value of 1 indicates the account is disabled and 0 indicates the account is enabled.
--Query to check account status
SELECT name,is_disabled from sys.server_principals where name='sa'
Rename the SA Login
You can also rename the SA account which will prevent hackers/users to some extent. The one disadvantage is that it does not change the SID for the SA account which by default is 0x01, so someone could find the new name by looking up the SID.
--Query to check account status
ALTER LOGIN sa WITH NAME = [mssqltip];
This query could be used to lookup the name for the SA account based on the SID.
SELECT * FROM sys.syslogins WHERE sid = 0x01
If the SA account is enabled, check that the password policies are enforced for the account
If you're in the happy position of not needing the sa account enabled, my preference for security is to use the undocumented* sproc: sp_SetAutoSAPasswordAndDisable
Which does what it says on the tin, as it were. It changes the sa password to a random GUID and disables the account. The real beauty of it is you can easily slot it into password change process in cases where policies, regulations, or auditors require the sa password to be periodically rotated.
*The usual caveats about undocumented features apply, of course.
Monday, January 17, 2011 - 11:32:39 AM - Greg Robidoux
Note also that modern graphics card setups can crack SQL Server passwords from sys.syslogins at a rate of billions per second; 8 character passwords are discovered in mere days. Set the SA password to something very long (>14 characters) and completely random.