SQL Server Error:
15023

What does this error mean?

SQL Server raises error 15023 when a CREATE USER, sp_adduser, or sp_grantdbaccess statement tries to add a database principal that already exists in sys.database_principals. In a data-pipeline context you typically hit this after restoring a .bak file to a different server: the database carries its own user list, but the server-level logins have different SIDs — creating an orphaned user. ADF, dbt, or Synapse pipelines that run post-deploy provisioning scripts will fail at the exact CREATE USER step, and the pipeline activity shows status Failed with message 'User, group, or role already exists in the current database'. The connection itself works; it is the user-creation DDL inside the pipeline that breaks.

Common causes

• 1Restoring a database backup (.bak) to a new server or Azure SQL — the database user exists in the backup but the server login SID does not match, creating an orphaned user that blocks new CREATE USER calls for the same name
• 2Running a deployment or CI/CD script a second time without idempotent guards — the CREATE USER statement succeeds on first run and fails on every subsequent run
• 3A migration script (Flyway, Liquibase, dbt pre-hook) tries to create a user that was already provisioned manually by a DBA or via the Azure portal
• 4Cloning an Azure SQL database with CREATE DATABASE ... AS COPY OF — the copy inherits all database users, but a subsequent setup script assumes they do not exist yet
• 5Contained database users in Azure SQL — a user with PASSWORD was created in database scope, and a later script attempts to re-create the same principal with FOR LOGIN syntax, hitting the duplicate name check

How to fix it

1. 1Step 1: Identify orphaned users — run: SELECT dp.name AS orphaned_user, dp.sid FROM sys.database_principals dp LEFT JOIN sys.server_principals sp ON dp.sid = sp.sid WHERE dp.type IN ('S','U') AND sp.sid IS NULL AND dp.name NOT IN ('dbo','guest','INFORMATION_SCHEMA','sys'); — any rows returned are orphaned.
2. 2Step 2: Re-map each orphaned user to its server login: ALTER USER [username] WITH LOGIN = [loginname]; — this updates the SID in the database to match the server login.
3. 3Step 3: If no matching server login exists, create one first: CREATE LOGIN [loginname] WITH PASSWORD = 'StrongP@ss1'; then run the ALTER USER from Step 2.
4. 4Step 4: For contained databases on Azure SQL (no server logins), drop and recreate the user: DROP USER [username]; CREATE USER [username] WITH PASSWORD = 'StrongP@ss1'; — verify the app connection string uses the database-scoped credential.
5. 5Step 5: Make deployment scripts idempotent to prevent recurrence: IF NOT EXISTS (SELECT 1 FROM sys.database_principals WHERE name = N'username') CREATE USER [username] FOR LOGIN [loginname]; — add this guard to every CREATE USER in your migration files.
6. 6Step 6: For bulk fixes after a large restore, use Auto_Fix: EXEC sp_change_users_login 'Auto_Fix', 'username', NULL, 'TempP@ss1'; — this creates a matching login if none exists and remaps the user in one call. Repeat per orphaned user from Step 1.
7. 7Step 7: Verify the fix — reconnect from ADF or your pipeline tool using the affected credential and re-run the failed activity. Check sys.database_principals to confirm the SID now matches sys.server_principals.

Example log output

Msg 15023, Level 16, State 1, Line 12
User, group, or role 'etl_service' already exists in the current database.
2026-05-11 08:22:14.003 [ERROR] ADF activity 'Provision_DB_Users' failed: SqlFailedError, Message='User, group, or role 'etl_service' already exists in the current database.' (ErrorCode: 15023, SqlState: S0001)

Frequently asked questions

Other authentication errors