Security Issues with the SQL Server BUILTIN Administrators Group

Problem

The principal of least privileges is a cornerstone to most security implementations.  The premise behind the principal is to only grant users, developers, DBAs, network administrators, etc. the needed rights and nothing more.  If additional rights are required, evaluate the rights and grant the access accordingly.

With SQL Server 2000 and 2005 one area that does not seem to follow this principal is related to the default rights for the BUILTIN\Administrators group.  By default this group has SQL Server System Administrator rights to SQL Server when it is installed.  The same level of default rights are also granted to BUILTIN\Administrators group in SQL Server 2005 during the installation.  What this means is that any account in the Windows Local Administrators group has SQL Server System Administrator rights.

Solution

The BUILTIN\Administrators can easily be removed from SQL Server to prevent this security issue, but heed the warnings below prior to removing the group from SQL Server.

What steps should I take prior to considering removing this group?

  1. Verify that you know the “sa” password by logging into the SQL Server with the “sa” account with either Query Analyzer or Management Studio on the SQL Server you want to modify.
  2. Validate other Windows groups or Windows logins are assigned SQL Server System Administrator rights on this SQL Server.
  3. Review the rights assigned to the BUILTIN\Administrators group.
  4. Research the members of the Windows Local Administrators group.
  5. Figure out if an additional group should be created in Active Directory and assigned rights in SQL Server or if specific logins should be assigned rights to SQL Server.
  6. If necessary, create the additional logins and groups in Active Directory and assign rights in SQL Server to ensure a minimum of 1 login and/or the “sa” login has SQL Server System Administrator rights.
  7. Validate that the members of the BUILTIN\Administrators group do not own any databases, objects, Jobs, etc and that none of the logins are connected to SQL Server.
  8. If any of these steps were not completed, repeat the needed steps.  If all of these steps have been followed and you are confident that removing the BUILTIN\Administrators group will not cause any issues proceed to the next set of directions.

*** NOTE *** – Do not remove the BUILTIN\Administrators group from SQL Server if other logins or groups do not have SQL Server System Administrator rights or if you do not know the “sa” password.

With all of that being said, how do I remove the BUILTIN\Administrators group?



























MethodDirections
SQL Server 2000
T-SQL Commands		USE MASTER
GO
exec sp_revokelogin N’BUILTIN\Administrators’
GO
 

OR

SQL Server 2000
Enterprise Manager

  1. Open Enterprise Manager.
  2. Navigate to the Security folder.
  3. Double click on the Logins icon, which will load the SQL Server logins and groups in the right pane.
  4. Locate the BUILTIN\Administrators group.
  5. Right click on the BUILTIN\Administrators group and select the ‘Delete’ option.
  6. On the subsequent screen, read the message and if you agree press ‘Yes’ to remove the group.
  7. Refresh the pane to verify the group has been dropped.
 
MethodDirections
SQL Server 2005   
T-SQL Commands		DROP LOGIN [BUILTIN\Administrators]

OR

SQL Server 2005
Management Studio

  1. Open Management Studio.
  2. Navigate to the Security folder.
  3. Expand (+) the Logins folder, which will load the SQL Server logins and groups in the right pane.
  4. Locate the BUILTIN\Administrators group.
  5. Right click on the BUILTIN\Administrators group and select the ‘Delete’ option.
  6. On the subsequent screen, review the screen and if you agree press ‘OK’ to remove the login.
  7. Refresh the pane to verify the login has been dropped.

Next Steps

  • Review some of your key SQL Servers to determine if the BUILTIN\Administrators Group has the default System Administrator rights in SQL Server.
  • Talk with your team members about this security change and others to ensure these types of changes make sense in your environment.
  • Work towards building a solidified process to secure your SQL Servers as you deploy them to meet the organizational needs.
  • Stay tuned for more simple steps to secure your SQL Servers…

Related Posts

Leave a Reply

Your email address will not be published. Required fields are marked *