sp_check: SQL Server Database Checks

1 - High (Action Required)

Explicit permissions granted to the public role

Issue: One or more explicit permissions have been granted to the public role on your SQL Server instance.

Problem: By default, the public role includes anyone who has a login that allows them to connect to your instance, and it include very few permissions. There is very little reason for the public role to be granted any explicit permissions, since there is virtually no permission that everyone who has a login needs on your SQL Server.

Moreover, there are some permissions like BACKUP DATABASE that can allow anyone to make a copy of your database. Allowing anyone to make database backups is a great way to encourage a data breach.

Straight Path classifies this vulnerability as level 2, "High - review required" in sp_CheckSecurity.

Learn More...

Database owner is different from owner in master

Issue: The owner of the database is different than what is noted in the master database.

Problem: This isn't so much a problem as a mess that should be cleaned up. You want to have the correct database owner for a database since the owner of the database has specific elevated permissions.

Learn More...

Orphaned users

Issue: One or more users in user databases has been found to not have an associated login at the instance level.

Problem: Orphan user permissions are unable to be assigned to a current login. This typically happens when SQL Server logins are used to assign user permissions to a database, and then either the login is dropped from the instance or the database is copied to an instance where the login does not exist.

Learn More...

Database roles within roles

Issue: One or more database roles has been found to have been included in another database roles.

Problem: Nesting database roles can obscure actual permissions for a role, leading to unintended privilege escalation in your databases.

Learn More...

Unusual database permissions

Issue: One or more logins or groups has been included in the db_accessadmin, db_securityadmin, or db_ddladmin database roles in a user database.

Problem: These roles noted have very specific purposes, but we have found that often users have been assigned to these roles while also being assigned to the db_owner role. Since the db_owner role includes all permissions from the db_accessadmin, db_securityadmin, and db_ddladmin roles, these permissions can be redundant.

Learn More...

db_owner role members

Issue: One or more logins or groups has been included in the db_owner database role in a user database.

Problem: Members of the db_owner role can do anything within the scope of a database, including creating, modifying, or deleting any object. Members of db_owner can also change other database permissions and even drop the database.

Learn More...

TRUSTWORTHY database

Issue: One or more user databases has the TRUSTWORTHY setting enabled.

Problem: If the TRUSTWORTHY setting is set to ON, and if the owner of the database is a member of a the sysadmin group, the database owner can then be able to create and run unsafe assemblies that can compromise the instance of the SQL Server. This can be problematic if a database with TRUSTWORTHY set to ON is copied to another server, where the database owner can unintentionally have elevated permissions.

Learn More...

Failed logins

Issue: One or more failed login attempts have recently occurred on your SQL Server instance.

Problem: Although a handful of failed login attempts are typically not something to be concerned about, if you have hundreds or thousands of failed logins.

Learn More...

About sp_checks

This page contains a list of SQL Server configuration checks performed by Straight Path's suite of sp_check tools. For more details about our free tools, select one from the following list: