What’s the issue?
Ownership chaining is a SQL Server security mechanism that allows a user to access objects through a stored procedure or view without needing direct permissions on the underlying objects, as long as the calling object and the underlying objects share the same owner. Within a single database, ownership chaining is enabled by default and is the basis for the common pattern of granting users execute permission on a stored procedure while denying direct access to the tables it reads or writes.
Cross database ownership chaining extends this mechanism across database boundaries. When enabled, ownership chains can span databases as long as the relevant objects are owned by the same login at the server level. The behavior is controlled by two settings: the server level cross db ownership chaining configuration option, which enables the feature globally, and the database level DB_CHAINING option, which enables it on a per database basis.
This finding identifies instances where cross database ownership chaining is enabled, either at the server level or for one or more individual databases.
Why is this a problem?
Cross database ownership chaining bypasses the permission checks that normally occur when a query crosses database boundaries. A user with execute permission on a stored procedure in one database can read or write objects in another database with no direct permissions there, as long as the ownership chain is unbroken.
This expands effective access in ways that are not obvious to administrators, since the chained access does not appear in any user’s direct permission grants. Tracing the full set of accessible objects becomes difficult when chained procedures call other chained procedures across multiple databases.
The feature also creates privilege escalation paths that are hard to anticipate. A user with db_owner rights in one database can create dbo owned objects that reach into other databases owned by the same login at the server level, which is often a privileged account such as sa.
Microsoft recommends keeping cross database ownership chaining disabled at the server level and enabling it only on specific databases where it is genuinely required, with documentation of the reason and the access paths involved.
What should you do about this?
Check the current state with EXEC sp_configure ‘cross db ownership chaining’; for the server level setting and by querying sys.databases for the is_db_chaining_on column at the database level. Review with application owners which databases actually require the feature and which had it enabled inadvertently or as a legacy workaround.
For databases that depend on it, evaluate whether the same access can be achieved through explicit permissions, module signing, or controlled use of synonyms and views. These alternatives produce the same effective access without the broad implicit trust that ownership chaining creates.
Disable the feature where it is not required, using ALTER DATABASE [DatabaseName] SET DB_CHAINING OFF; at the database level and EXEC sp_configure ‘cross db ownership chaining’, 0; RECONFIGURE; at the server level. Test in a non production environment first, since changing from implicit chaining to explicit permissions can surface dependencies that were not previously visible.
Read more…
cross db ownership chaining (server configuration option) – SQL Server | Microsoft Learn