What’s the issue?
A database user is normally mapped to a server-level login through a matching security identifier, and that mapping is what allows an authenticated principal to reach the database. When no login on the instance matches the user’s SID, the user is orphaned and no one can currently connect as it.
Orphaned users most often appear after a database is restored or attached from another instance, where the source logins do not exist on the destination. The user records inside the database survive intact, including every role membership and permission grant they held.
This check identifies orphaned users that also hold membership in db_owner, db_securityadmin, db_accessadmin, or db_ddladmin, detected by comparing sys.database_principals against sys.server_principals and cross-referencing sys.database_role_members.
Why is this a problem?
The elevated permissions are dormant rather than removed. If a login is later created that matches the orphaned user’s SID, whether deliberately or by coincidence, that login immediately inherits db_owner or the other administrative role without any new permission grant being made or reviewed.
The risk is highest with db_owner, since a member can create objects that execute as the database owner. If that owner is a privileged login, or if the database has TRUSTWORTHY enabled, the inherited access extends well beyond the database itself.
Orphaned administrative users also be troublesome for access review. A database can appear to have several administrators when in fact none of them can currently connect, which makes it harder to determine who actually holds authority and whether the delegation model is still appropriate.
What should you do about this?
Identify the affected users by comparing sys.database_principals to sys.server_principals on SID in each database, then filter to those holding membership in the four administrative roles. Capture the user name, SID, and role memberships for each.
Work with the application owners to determine the correct outcome for each user. Where the access is still needed, map the user to the appropriate current login with ALTER USER [UserName] WITH LOGIN = [LoginName];. Where it is not, drop the user with DROP USER [UserName]; after confirming nothing depends on it.
Update your restore, attach, and refresh procedures to include orphaned user cleanup, since that is where most of these originate.