Different ways to secure the SQL Server SA Login

By:   |   Updated: 2011-01-17   |   Comments (5)   |   Related: > Security


Problem

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.

Solution

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 check your current setting you can use these techniques outlined in this tip.

To change this setting in SQL Server Management Studio, right-click the server, click Properties and go to Security page as shown below.

ways to secure the SA login in ssms


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


Next Steps


sql server categories

sql server webinars

subscribe to mssqltips

sql server tutorials

sql server white papers

next tip



About the author
MSSQLTips author Jugal Shah Jugal Shah has 8+ years of extensive SQL Server experience and has worked on SQL Server 2000, 2005, 2008 and 2008 R2.

This author pledges the content of this article is based on professional experience and not AI generated.

View all my tips


Article Last Updated: 2011-01-17

Comments For This Article




Tuesday, July 10, 2012 - 2:55:51 AM - Vahid Back To Top (18411)

Hello

I have a database server that users are connected through to it but i dont know  a user is that drop database on server

i write a trigger  and log history but again user can delete my database on server and trigger cant prevent that it

 

 

CREATE

 

Trigger [LogDB] onall

server

For

 

 

DROP_database,ALTER_database,ALTER_TABLE,DROP_TABLE,CREATE_DATABASE,Drop_Trigger

 

as

 

set

 

nocount

on

PRINT

 

 

 

'You must contact a DBA before dropping or altering tables!'

 

 

rollback

 

Declare

 

@CommandText

nvarchar(2000),

@ComputerName

nvarchar(100),

@ApplicationName

nvarchar(100),

@LogiName

nvarchar(100),

@LogDate

DateTime

SELECT

 

@CommandText =EVENTDATA().value

 

(

 

'(/EVENT_INSTANCE/TSQLCommand/CommandText)[1]','nvarchar(max)'

)

 

 

select

 

@ComputerName

=HostName,

@ApplicationName

=Program_name,

@LogiName

=suser_sname(),

@LogDate

=GetDate()

from

 

sys.sysprocesseswhere spid=

@@Spid

 

 

Insert

 

LogError.dbo.LogEvents

 

(

 

CommandText

,

ComputerName

,

ApplicationName

,

LogiName

,

LogDate

 

)

 

values

 

(

 

@CommandText

,

@ComputerName

,

@ApplicationName

,

@LogiName

,

@LogDate

 

)

 


Thursday, July 7, 2011 - 10:24:38 AM - Very long passwords Back To Top (14143)

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.


Tuesday, January 18, 2011 - 5:10:10 AM - JoeK Back To Top (12623)

Really useful article. Thanks. JK


Monday, January 17, 2011 - 11:32:39 AM - Greg Robidoux Back To Top (12620)

You can refer to this tip: http://www.mssqltips.com/tip.asp?tip=2006

This explains the sproc: sp_SetAutoSAPasswordAndDisable


Monday, January 17, 2011 - 10:43:42 AM - Matt Cherwin Back To Top (12617)

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.















get free sql tips
agree to terms