What’s the issue?
This check, run by sp_CheckSecurity using the @PrefferredDBOwner parameter, identifies databases whose owner does not match the preferred owner specified for the environment. When no preferred owner is provided to the procedure, sa is treated as the default preferred owner, although using sa for this purpose is not a recommended security practice.
Database ownership is recorded at the server level in sys.databases and is updated through ALTER AUTHORIZATION ON DATABASE. The owner determines the security context of the dbo user inside the database and is the trust anchor for ownership-chained operations that cross out of the database.
This finding flags any database whose current owner does not match the preferred value, indicating that ownership has drifted from the standard or was never set correctly during database creation, restore, or attach.
Why is this a problem?
Members of the db_owner fixed database role can create objects in the database that execute under the security context of the database owner. If the database owner is a member of a role with elevated server-level permissions, such as sysadmin, this becomes a direct privilege escalation path: anyone in db_owner can create code that runs with the owner’s elevated privileges, effectively inheriting access far beyond the database itself.
The escalation path is particularly dangerous because it does not require any change to server-level role membership. The db_owner member writes code, the code executes as the database owner, and the database owner’s elevated permissions apply. This pattern is commonly cited in SQL Server security guidance and is one of the main reasons that database ownership deserves the same scrutiny as server-level role membership.
Inconsistent ownership across databases also complicates audit and review. When ownership is set ad hoc, often to whoever happened to create or restore the database, the security model becomes unpredictable and difficult to reason about. Reviews must then evaluate the privilege level of each owner separately, multiplying the audit work.
The condition often persists silently because database ownership rarely surfaces in normal monitoring, and the escalation paths it enables are only exploited in scenarios that involve a privileged owner combined with broad db_owner membership. Without specific checks, ownership drifts further from the standard over time as databases are moved, restored, and refreshed.
What should you do about this?
We recommend creating at least one dedicated, low-permission SQL login specifically for use as the owner of user databases. This login should hold no server-level role memberships beyond public, should be disabled with ALTER LOGIN [LoginName] DISABLE;, and should be denied connect permission with DENY CONNECT SQL TO [LoginName];. The login exists only as a stable, low-privilege ownership anchor and never authenticates to the instance.
Reassign affected databases to the preferred owner using ALTER AUTHORIZATION ON DATABASE::[DatabaseName] TO [PreferredOwnerLogin];. The change updates both the server-level ownership record and the internal dbo mapping in a single operation, bringing the database into alignment with the standard.
Avoid using sa as the database owner even though it is the default preferred owner when none is specified. Although sa is a stable principal, it is also a member of sysadmin, which means any db_owner in any sa-owned database can create objects that execute with full server-level privileges. The dedicated low-permission login closes this escalation path without sacrificing operational simplicity.
Add the preferred owner step to your standard database creation, restore, and attach procedures so new databases are owned correctly from the start. Run sp_CheckSecurity with the @PrefferredDBOwner parameter regularly as part of your health check process so any drift from the standard is detected promptly. Document the preferred owner login, the disabled and denied state, and the rationale, so the configuration remains intentional and defensible during audits.
Read more…
SQL Server Database Ownership: survey results & recommendations (Andreas Wolters)