SQL Server Error 15023

Error number

15023

Severity

16 (user-correctable error)

State

6 for CREATE USER, 8 for CREATE ROLE (reproduced); other states for other statements

Product

Microsoft SQL Server Database Engine

Versions

All supported SQL Server versions (2016 to 2025), Azure SQL Database, Azure SQL Managed Instance

Category

Logins & Permissions

Last reviewed

23 October 2026

What it means

Error 15023 means you tried to create a database user or role with a name that a user, role or group already uses in this database; most often it is an orphaned user left behind by a restore.

Users, database roles, application roles and Windows groups all live in the same name space in a database (sys.database_principals), so a name can be used only once. CREATE USER, CREATE ROLE and the User Mapping page in SQL Server Management Studio raise 15023 at severity 16 when the name is taken. The statement does nothing; the existing principal is untouched.

The classic trigger is a database restored or attached on another server. The database brings its users with it, but each user is linked to a login by SID, and the login on the new server has a different SID (or does not exist yet). The user is now orphaned: it exists, so CREATE USER app_user FOR LOGIN app_user fails with 15023, yet the login cannot use the database. The fix is to remap the existing user, not to create a new one.

Common causes

• A deployment or migration script runs CREATE USER again on a database that already has the user.
• A database restored from another server contains an orphaned user with the same name as the login you are mapping.
• Mapping a login to a database in the SQL Server Management Studio Login Properties, User Mapping page when an unmapped user of that name exists.
• Creating a role with the same name as an existing user, or a user with the name of a role (one name space for both).
• A Windows group or contained database user already uses the name.

Diagnose it

Read-only These queries only read metadata and dynamic management views. They do not change data, permissions or configuration, so they are safe to run first.

SELECT name, type_desc, authentication_type_desc, create_date, sid
FROM sys.database_principals
WHERE name = N'app_user';

SELECT dp.type_desc, dp.sid, dp.name AS user_name
FROM sys.database_principals AS dp
LEFT JOIN sys.server_principals AS sp ON dp.sid = sp.sid
WHERE sp.sid IS NULL
  AND dp.authentication_type_desc = 'INSTANCE';

SELECT dp.name AS user_name, dp.type_desc, sp.name AS login_name
FROM sys.database_principals AS dp
LEFT JOIN sys.server_principals AS sp ON sp.sid = dp.sid
WHERE dp.type IN ('S', 'U', 'G')
ORDER BY dp.name;

How to fix it

Each fix is labelled with what it changes. Try read-only checks and the least invasive fix first, and test changes outside production.

IF NOT EXISTS (SELECT 1 FROM sys.database_principals WHERE name = N'app_user')
    CREATE USER [app_user] FOR LOGIN [app_user];

-- In the restored database
ALTER USER [app_user] WITH LOGIN = [app_user];

-- SID copied from the source server (sys.server_principals.sid)
CREATE LOGIN [app_user]
    WITH PASSWORD = N'Use-a-strong-unique-password-1',
         SID = 0x9A1F0C2B7E5D4C3BA1B2C3D4E5F60718;

CREATE ROLE [reporting_role];

Examples

CREATE USER run twice

CREATE USER app_user WITHOUT LOGIN;

-- later, a deployment script runs again
CREATE USER app_user WITHOUT LOGIN;

Msg 15023, Level 16, State 6, Line 4
User, group, or role 'app_user' already exists in the current database.

A role with the same name as a user

CREATE USER reporting WITHOUT LOGIN;

CREATE ROLE reporting;  -- same name as the user

Msg 15023, Level 16, State 8, Line 3
User, group, or role 'reporting' already exists in the current database.

How to prevent it

Write security scripts that check sys.database_principals before creating anything, and keep users, roles and their memberships in source control with the schema. Name roles distinctly (for example with a _role suffix) so they never collide with user names.

Before restoring a database on another server, create its SQL logins there with the original SIDs, then run the orphaned users query after every restore as part of the checklist. The SQL Server security lesson explains the login and user split.

Common questions

Learn more on CodeWithSQL

• SQL Server security: logins, users and permissions

Official documentation

• Troubleshoot orphaned users (SQL Server)
• ALTER USER (Transact-SQL)
• Transfer logins and passwords between instances (Microsoft Learn)
• Database engine events and errors 15000 to 15999 (Microsoft Learn)

Last technically reviewed 23 October 2026; examples and diagnostics run on SQL Server 2025 (17.0.1145.4). Message text checked against the engine's sys.messages catalogue.