By: Jeremy Kadlec | Comments (3) | Related: > Security
Problem
With the rights that the sa login has by default in SQL Server, it is imperative to change this password on a regular basis whether it is monthly, quarterly or semi-annually. In addition, as DBAs move on to other opportunities, it is wise to change the sa password as well. Changing the sa password should be a relatively easy process requiring little to no impact on the organization. Unfortunately, changing the sa password on a regular basis is not a common practice at most organizations, because the impacts of changing the password are unknown.
Solution
The first step in the process is to find out when the sa password was last changed. If this timeframe is unacceptable to your organization, then steps need to be taken to understand where the sa login is used and how the application can be modified to use another login.
SQL Server 2000 - sa password changes
In SQL Server 2000 a documented process does not exist to determine when the sa password was changed. The best means to determine if the sa password has changed is based on the value from the updatedate column in the master.dbo.syslogins table. This value seems to be the only possible column to determine if any property (default database, default language, etc.) for the sa login has changed. Since the sa properties do not change frequently, the value for this column should be a reasonable, but not an absolute indicator of when the sa password was last changed. Reference the code below to determine the value for the sa login's updatedate column.
| USE Master GO SELECT sid, [name], createdate, updatedate FROM master.dbo.syslogins WHERE [name] = 'sa' GO |
SQL Server 2005 - sa password changes
Unfortunately, SQL Server 2005 suffers from the same self documenting issue as SQL Server 2000 as it pertains to the last time the sa password has changed. The modify_date of the sys.sql_logins catalog view can be used as an indicator of when the last property (default database, default language, etc.) for the login has changed. Just as is the case with SQL Server 2000, this value does not guarantee the date\time stamp of the password change, but rather any property change. Since the properties do not change frequently under normal circumstances this value can serve as a reasonable, but not an absolute indicator of when the sa password was last changed. If other properties have changed, the modify_date is not a true indicator and other research/documentation is needed to determine the last sa password change date.
| USE Master GO SELECT [name], sid, create_date, modify_date FROM sys.sql_logins WHERE [name] = 'sa' GO |
To address the risks of changing the sa password, stay tuned for the upcoming tips in the sa series from MSSQLTips.com.
Next Steps
- If you are scratching your head as to the last time the sa password was changed, then it is worth taking a look at your key SQL Servers
- If the last time the sa password has changed is unacceptable to you, then begin to work with your team on taking the necessary steps to changing the sa password
- In addition, stay tuned for the upcoming sa series tips on how to determine who and what applications are using the sa user name and password
- In order to prevent the sa password from becoming stale in the future, be sure to put processes in place to change the sa password on a regular basis
- For additional information from MSSQLTips.com check out the following:
- The first tip in the sa series - When not to use the sa password
- Stay tuned for the upcoming tips in the sa series:
- Determine how to find out who and what applications are using the sa user name and password
- Password management options for the sa login
- Check out the MSSQLTips.com security related tips
- Check out this tip on SQL Server 2005 DDL Auditing to track password changes for SQL Server 2005
About the author
Jeremy Kadlec is a Co-Founder, Editor and Author at MSSQLTips.com with more than 300 contributions. He is also the CTO @ Edgewood Solutions and a six-time SQL Server MVP. Jeremy brings 20+ years of SQL Server DBA and Developer experience to the community after earning a bachelor's degree from SSU and master's from UMBC.This author pledges the content of this article is based on professional experience and not AI generated.
View all my tips
