Sql error 15023

The SQL Server Error 15023 arises during user mapping when you restore a database to a different server.

Here at Bobcares, we have seen several causes for this error while troubleshooting SQL issues as part of our Server Management Services for web hosts and online service providers.

Today we’ll take a look at the cause for this error and how to fix it.

More about SQL Server Error 15023

In SQL Server, backup and restore are simple tasks. The only problem that arises here is the user mapping don’t work when you restore the database to a different server. If you try to map database to a user by going to

Security >> Logins >> right click some user >> Properties >> User Mapping >> Select DB >> set as db_owner and then ok, the following error is received as shown in image:

What causes SQL Server Error 15023 to occur

Normally, when we backup and restore databases across the SQL servers, we are only restoring a user database and not the master database where logins are kept.

After restoring we expect the restored database to work in the same way as the backup. But the login fails for a user that had permissions in the backed up database. This issue caused due to Security identification numbers (SID) that are mismatched or ‘orphaned’ in the sysusers table.

How we fix SQL Server Error 15023

Recently, one of our customers approached us with the same error message. Now, let’s see how our Support Engineers resolve this error.

1) Initially, we ran the following T-SQL Query in Query Analyzer. This will return all the existing users in database in result pan.

USE YourDB
GO
EXEC sp_change_users_login ‘Report’
GO

To associate login with the username, we ran the following T-SQL Query in Query Analyzer. Here, ‘Auto_Fix’ attribute will create the user in SQL Server instance if it does not exist.

Also, in the query we updated the ‘Username’ with actual customer username and ‘Password’ with actual Password. Auto-Fix links a user entry in the sysusers table in the current database to a login of the same name in sysxlogins.

USE YourDB
GO
EXEC sp_change_users_login ‘Auto_Fix’, ‘Username’, NULL, ‘Password’
GO

To associate login with the username, we ran the following T-SQL Query in Query Analyzer. Here, ‘Update_One’ will link the specified user in the current database to login. Here, login must already exist, user and login must be specified and password must be NULL or not specified.

USE YourDB
GO
EXEC sp_change_users_login ‘update_one’, ‘ColdFusion’, ‘ColdFusion’
GO

2) We ran the following T-SQL in Query Analyzer since the login account had permission to drop other users. This query will drop the user.

USE YourDB
GO
EXEC sp_dropuser ‘ColdFusion’
GO

Then we created the same user again in the database without any error.

[Need any further assistance in fixing SQL errors? – We’re available 24*7]

Conclusion

In short, This SQL error can arise during user mapping when you restore a database to a different server. Today, we saw the resolution to this SQL error.

var google_conversion_label = «owonCMyG5nEQ0aD71QM»;

История вопроса:

01. Был установлен «Microsoft
SQL
Server 2005» со средой «SQL
Server
Management
Studio
Express» 9.00.3042.00 (далее, для краткости, эта среда — SE).

02. Была развёрнута подготовленная и настроенная на другой машине база данных.

03. Есть клиентское приложение (не Майкрософт), работающее только через клиента, которое работало до проблемы, и продолжает успешно работать сейчас, т.е. на нём проблема никак
не сказалась (далее, клиентское приложение — КП).

04. Есть другое приложение (не Майкрософт), которому нужен вход в базу владельцем (далее, это приложение — СП).

05. Всё работало, пока я, по неопытности, не подключился к базе через «MS SQL Native Client»
приложением «Microsoft Office Access 2003» (далее — MSA), а MSA, в свою очередь, изменил параметры базы без
моего разрешения!

06. СП перестал принимать имя ( AFOND ) и пароль, чтобы войти. Пробовал разные варианты, ничего не помогало. СП выдавало ошибку «http://i16.fastpic.ru/big/2011/0127/7d/79db0f2f97c40243f240fa3a54d91e7d.jpg».

07. Пробовал решить проблему изменением параметров на правильные с помощью SE. Всё, кажется, получается, осталось только изменить имя входа владельца базы, а оно, как назло,
не меняется! Серым цветом, и всё.

08. При этой ситуации СП принимает имя и пароль, но из-за ошибки программистов самого СП оно даёт сбой. Видимо, потому что имя входа владельца базы зашито в самом СП.

09. Есть ещё одно место в SE, где можно сопоставить имя входа и пользователя. Это имена входа
SQL Server. При попытке задания в нужном конкретном имени входа ( AFOND ) связи для нужной конкретной базы ( AFOND_DB )
с нужным конкретными пользователем ( dbo ) и схемой по умолчанию ( dbo ) SE выдаёт ошибку «http://i16.fastpic.ru/big/2011/0127/02/b6f510ed41f0df2b8697b9c174ace302.jpg».

10. Я нашёл в Сети описание решения, см. «http://blog.sqlauthority.com/2007/02/15/sql—server—fix—error-15023-user—already—exists—in—current—database/»,
но при применении первого описанного там способа получается следующее:

10.а. на первый запрос выводит пустой список со столбцами «UserName UserSID» и сообщением «Выполнение команд успешно завершено.»

10.б. на второй запрос выводит сообщение:

     
Сообщение 15287, уровень 16, состояние 1, процедура sp_change_users_login, строка 35

     
Завершение процедуры. Значение «dbo» запрещено использовать в качестве параметра имени входа в этой процедуре.

10.в. на третий запрос выводит абсолютно такое же сообщение, как в 10.б

11. При применении второго способа выводит сообщение:

     
Сообщение 15150, уровень 16, состояние 1, процедура sp_revokedbaccess, строка 51

     
Невозможно удалить пользователь «dbo».

12. Остальное не пробовал, но я ищу решение. На форуме не нашёл проблемы с такой спецификой. Я хочу всесторонне исследовать проблему. Рассмотрю любые возможности, а когда
буду уверен в безопасности изменений, надеюсь возвратить параметры базы в исходное состояние.

Microsoft sql server error 15023

This forum has migrated to Microsoft Q&A. Visit Microsoft Q&A to post new questions.

Answered by:

Question

Any idea how to solve this?

I tried to rename User Mapping from ‘sa’ to ‘dbo’ but failed with above error.

Answers

As stated above — the sa login already has db_owner privileges on all databases.

If you try to create a user sa in a database this is the T-SQL that is executed in the background:

GO
CREATE USER [sa] FOR LOGIN [sa] WITH DEFAULT_SCHEMA=[dbo]
GO

This statement will fail.

If the sa account has already been mapped to a database as the dbo user (the default database owner) the an attempt to change that to sa will result in this code behind the scenes:

USE [database]
GO
ALTER USER [dbo] WITH NAME=[sa]
GO

This statement will also fail.

If you want to map the sa account into explicit databases then use the dbo user.

Regards, Matt Bowler MCITP, My blog | SQL Services

I’ll marking detailed explanation as indirect answer, issue actually related to the application installer did not recognize SQL server hostname.

We used server IP instead.

Regards, Matt Bowler MCITP, My blog | SQL Services

it’s related to one application that’s using MQ SQL db. it got some error when we wanted to upgrade it.. it was not accepting the sa password given.

so i compare the ‘sa’ user properties in MS SQL. the 2 others SQL which was successfully upgraded has ‘dbo’ in it’s User Mapping properties. the 1 which is failed is using ‘sa’

I wanted to change ‘sa’ User Mapping from ‘sa’ to ‘dbo’

>>>>it got some error when we wanted to upgrade it.. it was not accepting the sa password given

Do you want to upgrade SQL Server or Application?

‘sa’ is a login which is a member of sysadmin server role (usually we disable that login)

Best Regards,Uri Dimant SQL Server MVP, http://sqlblog.com/blogs/uri_dimant/

As stated . an application.

Understood but ‘sa’ login is required one time during the upgrade.

Could anyone explain in layman term what ‘User’ column in User Mapping means?

The user mapping is where sql server logins are mapped to users within a database — and assigned to role membership.

The sa is a built in account that is usually assigned to sysadmin privileges server wide — so does not need to be mapped to any databases explicitly. As Uri pointed out it is often recommended to disable this account as it is a well known SQL Server account and hence a security attack point.

I imagine that there is some sort of renaming being attempted behind the scenes when you are attempting to remap the login. But, I don’t beleive that you would need to map the sa login to any databases at all.

Regards, Matt Bowler MCITP, My blog | SQL Services

The user mapping is where sql server logins are mapped to users within a database — and assigned to role membership.

The sa is a built in account that is usually assigned to sysadmin privileges server wide — so does not need to be mapped to any databases explicitly. As Uri pointed out it is often recommended to disable this account as it is a well known SQL Server account and hence a security attack point.

I imagine that there is some sort of renaming being attempted behind the scenes when you are attempting to remap the login. But, I don’t beleive that you would need to map the sa login to any databases at all.

hmm thanks for the explanation

refer same image below. what is the different if ‘sa’ is put at User column. and then what happen if we put ‘dbo’?

(i can see Default Schema is already using ‘dbo’. so we not changing this. )

Источник

Microsoft sql server error 15023

This forum has migrated to Microsoft Q&A. Visit Microsoft Q&A to post new questions.

Answered by:

Question

Answers

You are receiving 15023 error as you are restoring a MS SQL database from a backup. Keep in mind that when you perform backup and restore across the sql servers you are only restoring a user database and not the master database where logins are kept.

You expect a restored database to be in exactly the same state as the backup, but the login fails for a user that had permissions in the backed up database. This is caused by Security identification numbers (SID) that are mismatched or ‘orphaned’ in the sysusers table.

this will report all the orphaned login
EXEC sp_change_users_login @action=’Report’;

this should fix a orphaned user
Exec sp_change_users_login @action=’Update_One’, @UserNamePattern= [orphaneduserDBUserName] , @LoginName=[orphaneduserloginname]

b) or you can search for a script that can do this for all the orphaned users

Explain the below mention points to understand the issue.

PROD-
MSSQL Server version
MSSQL Server SP

Dev—
MSSQL Server version
MSSQL Server SP

Login Property

Windows Login
SQL login.

Microsoft reported as BUG for sql 2000 behaviour, Try it..
http://support.microsoft.com/kb/819261
User logons and permissions on a database may be incorrect after the database is restored
http://support.microsoft.com/kb/168001

-Mark as ANSWER if helps-

You are receiving 15023 error as you are restoring a MS SQL database from a backup. Keep in mind that when you perform backup and restore across the sql servers you are only restoring a user database and not the master database where logins are kept.

You expect a restored database to be in exactly the same state as the backup, but the login fails for a user that had permissions in the backed up database. This is caused by Security identification numbers (SID) that are mismatched or ‘orphaned’ in the sysusers table.

this will report all the orphaned login
EXEC sp_change_users_login @action=’Report’;

this should fix a orphaned user
Exec sp_change_users_login @action=’Update_One’, @UserNamePattern= [orphaneduserDBUserName] , @LoginName=[orphaneduserloginname]

b) or you can search for a script that can do this for all the orphaned users

Explain the below mention points to understand the issue.

PROD-
MSSQL Server version
MSSQL Server SP

Dev—
MSSQL Server version
MSSQL Server SP

Login Property

Windows Login
SQL login.

Microsoft reported as BUG for sql 2000 behaviour, Try it..
http://support.microsoft.com/kb/819261
User logons and permissions on a database may be incorrect after the database is restored
http://support.microsoft.com/kb/168001

-Mark as ANSWER if helps-

Explain the below mention points to understand the issue.

PROD-
MSSQL Server version
MSSQL Server SP

Dev—
MSSQL Server version
MSSQL Server SP

Login Property

Windows Login
SQL login.

Microsoft reported as BUG for sql 2000 behaviour, Try it..
http://support.microsoft.com/kb/819261
User logons and permissions on a database may be incorrect after the database is restored
http://support.microsoft.com/kb/168001

-Mark as ANSWER if helps-

You are receiving 15023 error as you are restoring a MS SQL database from a backup. Keep in mind that when you perform backup and restore across the sql servers you are only restoring a user database and not the master database where logins are kept.

You expect a restored database to be in exactly the same state as the backup, but the login fails for a user that had permissions in the backed up database. This is caused by Security identification numbers (SID) that are mismatched or ‘orphaned’ in the sysusers table.

Use [YourDatabase]
Go

this will report all the orphaned login
EXEC sp_change_users_login @action=’Report’;

this should fix a orphaned user
Exec sp_change_users_login @action=’Update_One’, @UserNamePattern= [orphaneduserDBUserName] , @LoginName=[orphaneduserloginname]

b) or you can search for a script that can do this for all the orphaned users

thank you Chirag_Shah for your help. you saved the day.

Источник

Как исправить. MS SQL Server: User, group, or role ‘*’ already exists in the current database. (Microsoft SQL Server, Error: 15023).

Предыстория: Как-то ко мне обратились со следующим вопросом: Программа использующая в качестве СУБД MS SQL Server не видит одну из баз, причем в Management Studio база видна и данные в ней есть.

Попытка просто расставить необходимые права к ожидаемому результату не привела — при попытке установить права возникла ошибка:

Create failed for User ‘*’. (Microsoft.SqlServer.Smo)
User, group, or role ‘*’ already exists in the current database. (Microsoft SQL Server, Error: 15023)

Копание в интернет привело к следующим рекомендациям:

Чтобы исправить данную ошибку, есть два различных способа в зависимости от версии SQL Server, который вы используете. Обе эти команды производят ремап (пере-ассоциацию) пользовательского идентификатора безопасности (SID), чтобы привести его в соответствие с SID в логине SQL Server’а.

Для SQL Server 2008 / SQL Server 2008 R2 / SQL Server 2012

ALTER USER user WITH LOGIN = serverlogin

где имя проблемного serverlogin пользователя, а имя user пользователя в самой базе (подробнее по ссылке https://msdn.microsoft.com/ru-ru/library/ms176060.aspx)

Для более старых SQL Server 2005 / SQL Server 2000

EXEC sp_change_users_login ‘Auto_Fix’, ‘user’

Но, как это и бывает в основной массе случаев, данный рецепт мне не помог.

Решение оказалось достаточно банальным:

1. Открываем интересующую нас базу в Microsoft SQL Server Management Studio
2. Идем в раздел Security -> Users. Там открываем интересующего нас пользователя
3. Открываем вкладку General
4. В разделе Database role membership выбираем необходимые нам права (мне хватило бы db_datawriter и db_datareader)

На этом все! База подключается, данные пишутся-читаются.

Разбор полетов: Было очень важно узнать как же данный инцидент мог произойти дабы исключить его в дальнейшем. Расследование показало достаточно обидный промах — база была восстановлена из резервной копии пользователем sa, что в конечном итоге привело к смене db_owner, а права на чтение и запись у нашего пострадавшего пользователя не были установлены (до переноса базы он успешно работал с ней как владелец).

Выводы (не претендующие на объективность):

1. Всегда необходимо проверять не только возможность авторизации пользователя, но и наборы его прав на интересующую нас базу.
2. Восстановление (перенос на новый сервер) лучше осуществлять под тем пользователем, который будет с данной базой работать в дальнейшем.
3. В случае ошибки подключения пользователя с базе или сообщения, что базы не существует — можно выдать данному пользователю права System Administrator для проверки возможности подключения и уверования в неправильно выставленные права. Работать из-вне с правами System Administrator крайне не желательно.

Источник

We use cookies on our website to give you the most relevant experience by remembering your preferences and repeat visits. By clicking “Accept All”, you consent to the use of ALL the cookies. However, you may visit «Cookie Settings» to provide a controlled consent.