3.9 Ensure Windows BUILTIN groups are not SQL Logins

Information

Prior to SQL Server 2008, the BUILTIN\Administrators group was added as a SQL Server login with sysadmin privileges during installation by default. Best practices promote creating an Active Directory level group containing approved DBA staff accounts and using this controlled AD group as the login with sysadmin privileges. The AD group should be specified during SQL Server installation and the BUILTIN\Administrators group would therefore have no need to be a login.

Rationale:

The BUILTIN groups (Administrators, Everyone, Authenticated Users, Guests, etc.) generally contain very broad memberships which would not meet the best practice of ensuring only the necessary users have been granted access to a SQL Server instance. These groups should not be used for any level of access into a SQL Server Database Engine instance.

Impact:

Before dropping the BUILTIN group logins, ensure that alternative AD Groups or Windows logins have been added with equivalent permissions. Otherwise, the SQL Server instance may become totally inaccessible.

Solution

For each BUILTIN login, if needed create a more restrictive AD group containing only the required user accounts.

Add the AD group or individual Windows accounts as a SQL Server login and grant it the permissions required.

Drop the BUILTIN login using the syntax below after replacing <name> in [BUILTIN\<name>].

USE [master]
GO
DROP LOGIN [BUILTIN\<name>]
GO

Default Value:

By default, no BUILTIN groups are added as SQL logins.

Additional Information:

In AWS RDS instances [BUILTIN]\Administrators can't be dropped. Dropping [Builtin]\Administrators is blocked in AWS RDS by the server-level trigger rds_drop_login_trigger.

See Also

https://workbench.cisecurity.org/benchmarks/7202

Item Details

Category: ACCESS CONTROL, MEDIA PROTECTION

References: 800-53|AC-3, 800-53|AC-5, 800-53|AC-6, 800-53|MP-2, CSCv7|14.6

Plugin: MS_SQLDB

Control ID: fc3f7d7b750345dcdc71ca08744415676de77d3a65e9dcd0a75c2c5283c7f021