Cannot Execute As the Database Principal (Error 15517)

This error has a talent for appearing far from the thing that caused it. A procedure that ran for years starts failing after a restore. Service Broker queues go quiet. A nightly job dies on a step nobody changed. The common thread is EXECUTE AS: something asked SQL Server to run as a database principal, and SQL Server could not make that identity work.

Every scenario and fix below was reproduced on a real SQL Server 2025 instance while writing this, including the restore that manufactures the problem and the one statement that ends it.

The Message Names Three Causes. Here Is How to Tell Which One You Have

That third row is the trap. The wording sends you hunting for a missing principal that is not missing. If the principal obviously exists, stop reading the message as an existence claim and start reading it as a permission denial.

The Restored-Database Case, Reproduced

This is the sequence that manufactures the error from nothing, run start to finish on a real instance. A database owned by a login, carrying one procedure marked WITH EXECUTE AS OWNER. Back it up, drop it, drop the owner login, restore it. The restored copy still records the vanished login’s SID as its owner:

-- After the restore, the proc that always worked now fails:
EXEC dbo.p_ctx;
-- Msg 15517: Cannot execute as the database principal because the
-- principal "dbo" does not exist, this type of principal cannot be
-- impersonated, or you do not have permission.

Nothing inside the database changed. What changed is that EXECUTE AS OWNER now points at an owner SID this instance has never heard of. Confirm it in one query; a NULL owner name is the tell:

SELECT d.name, d.owner_sid, SUSER_SNAME(d.owner_sid) AS owner_login
FROM   sys.databases AS d
WHERE  SUSER_SNAME(d.owner_sid) IS NULL;

And the fix is one line. Repointing the owner to a real login made the failing procedure run again immediately, no restart, no rebuild:

ALTER AUTHORIZATION ON DATABASE::YourDb TO sa;

Whether sa or a service account is the right owner is a policy question for your estate; what matters here is that the owner maps to a login that exists on this instance. The owner login can even be disabled and the fix still holds: EXECUTE AS OWNER resolves the identity, it does not sign in, so a disabled sa owns the database and the impersonation works. Verified on SQL Server 2025.

Why You Cannot Make This Happen Deliberately, and Restores Can

Trying to reproduce this by simply dropping the owning login gets refused: Msg 15174, Login owns one or more database(s). The engine defends the front door. A restore or attach walks in through the side: ownership arrives as a SID stamped in the backup, no login check is performed, and the orphan is created silently. That is why this error clusters around migrations, DR tests and environment refreshes, and why it deserves a place on any post-restore checklist next to orphaned users.

What Not To Do

• Do not grant your way past it with CONTROL SERVER or sysadmin. If the principal is orphaned, no grant to the caller fixes the owner mapping; you will have widened permissions and kept the error.
• Do not recreate the procedure without EXECUTE AS to make it stop. The impersonation was presumably there for a reason, usually so callers do not need direct table rights. Removing it trades a clear error for a quieter permission problem.
• Do not confuse this with orphaned users. Same family, different member: an orphaned user is a database user whose login is gone and has its own error and fix. Both come from the same restore, so check for both while you are there.

Common Questions

Related Scripts

• Get Orphaned Users, the same restore leaves both kinds of orphan; this finds the user kind
• Fix Orphaned Users, and this repairs them
• Get Permissions and Role Membership, for the IMPERSONATE-shaped case