What’s the issue?
SQL Server provides several fixed database roles that grant specific subsets of administrative permissions within a database. The db_accessadmin role grants the ability to add and remove users and Windows logins for the database, db_securityadmin grants the ability to manage role memberships and permissions, and db_ddladmin grants the ability to run any data definition language command in the database.These roles are designed to support delegated administration, where specific responsibilities can be assigned to different principals without granting full db_owner access. They are useful when their scopes are applied carefully, but their effective benefit depends on whether the assigned principals also hold broader roles that already include the same permissions.
This finding identifies user databases where logins or groups have been added to one or more of these roles, where often a principal is also a member of db_owner or holds equivalent broader permissions.
Why is this a problem?
The db_owner role includes all of the permissions granted by db_accessadmin, db_securityadmin, and db_ddladmin, plus much more. When a principal is a member of db_owner and also of one or more of these specific roles, the additional memberships add no new permissions and only complicate the security model.Redundant memberships make security review harder. When a user appears in multiple roles, reviewers must work through each role’s permissions to understand the effective access, which is more error-prone than reviewing a single role. The redundancy also obscures the actual delegation model, since the team cannot tell whether the additional roles were added for a specific reason or simply accumulated through ad hoc grants.
The condition also indicates that the database security model may not be following least privilege. The fixed database roles db_accessadmin, db_securityadmin, and db_ddladmin exist precisely so that delegated administration can be granted without db_owner, and using them in addition to db_owner defeats the purpose. Reviewing the assignments often reveals opportunities to remove db_owner from principals who only need the more limited delegated authority.
What should you do about this?
Review the memberships in db_accessadmin, db_securityadmin, and db_ddladmin for each user database by querying sys.database_role_members joined to sys.database_principals. Consider the principals in each role and cross reference against db_owner membership in the same database to identify redundancy.For each principal that holds both db_owner and one or more of the delegated roles, decide which membership reflects the actual intent. If the principal needs full database control, retain db_owner and remove the redundant role memberships. If the principal only needs the more limited delegated authority, remove db_owner and retain the appropriate specific role.