Код ошибки 0x5 sqlstate 42000 ошибка 15404

Remove From My Forums

Question
I have created a Job which will run the script generated by LiteSpeed for a particular DB Restore. However when i run the job, it is failing with the following error:

The job failed. Unable to determine if the owner (REDMONDv-kamir) of job Restore_Job has server access (reason: Could not obtain information about Windows NT group/user ‘REDMONDv-kamir’, error code 0x5. [SQLSTATE 42000] (Error 15404)).

I ran the script through SSMS and it works fine. Any ideas how to fix this?

Answers

Hello,

Error 0x5 means access denied.

Try to changing the owner of the jobs to the sa account, on the properties of the job.

If the above does no help, please change the service account for the SQL Server agent service to account with proper permissions.

http://technet.microsoft.com/en-us/library/ms345578.aspx

Hope this helps.

Regards,

Alberto Morillo

SQLCoffee.com
- Proposed as answer by
  
  Friday, December 31, 2010 3:20 AM
- Marked as answer by
  Kazim Ali Tabrez Mir
  Friday, December 31, 2010 5:56 PM

I am creating a SQL Server Replication using a script. When I try to execute

The job failed. Unable to determine if the owner (STARmoorer7) of job L3BPT2M-Atlas-14 has server access (reason: Could not obtain information about Windows NT group/user 'STARmoorer7', error code 0x5. [SQLSTATE 42000] (Error 15404)).

This is a job created by a script that defines replication.

How do I debug this?

asked Aug 5, 2009 at 17:13

Raj MoreRaj More

46.5k33 gold badges128 silver badges194 bronze badges

Active Directory is refusing access to your SQL Agent. The Agent should be running under an account that is recognized by STAR domain controller.

magnattic

12.4k13 gold badges63 silver badges114 bronze badges

answered Aug 5, 2009 at 17:30

Remus RusanuRemus Rusanu

285k40 gold badges429 silver badges564 bronze badges

For me, the jobs were running under DOMAINAdministrator and failing with the error message "The job failed. Unable to determine if the owner (DOMAINadministrator) of job Agent history clean up: distribution has server access (reason: Could not obtain information about Windows NT group/user 'DOMAINadministrator', error code 0x5. [SQLSTATE 42000] (Error 15404)). To fix this, I changed the owner of each failing job to sa. Worked flawlessly after that. The jobs were related to replication cleanup, but I’m unsure if they were manually added or were added as a part of the replication set-up — I wasn’t involved with it, so I am not sure.

answered Sep 19, 2016 at 15:00

Derreck DeanDerreck Dean

3,6581 gold badge25 silver badges45 bronze badges

We encountered similar errors in a testing environment on a virtual machine. If the machine name changes due to VM cloning from a template, you can get this error.

If the computer name changed from OLD to NEW.

A job uses this stored procedure:

msdb.dbo.sp_sqlagent_has_server_access @login_name = 'OLDAdministrator'

Which uses this one:

EXECUTE master.dbo.xp_logininfo 'OLDAdministrator'

Which gives this SQL error 15404

select text from sys.messages where message_id = 15404;
Could not obtain information about Windows NT group/user '%ls', error code %#lx.

Which I guess is correct, under the circumstances. We added a script to the VM cloning/deployment process that re-creates the SQL login.

answered Feb 16, 2012 at 21:43

Craig CelesteCraig Celeste

11.9k9 gold badges41 silver badges48 bronze badges

In my case I was getting this error trying to use the IS_ROLEMEMBER() function on SQL Server 2008 R2. This function isn’t valid prior to SQL Server 2012.

Instead of this function I ended up using

select 1 
from sys.database_principals u 
inner join sys.database_role_members ur 
    on u.principal_id = ur.member_principal_id 
inner join sys.database_principals r 
    on ur.role_principal_id = r.principal_id 
where r.name = @role_name 
and u.name = @username

Significantly more verbose, but it gets the job done.

Raj More

46.5k33 gold badges128 silver badges194 bronze badges

answered Jan 3, 2013 at 18:44

Bacon BitsBacon Bits

30k5 gold badges55 silver badges63 bronze badges

Just solved this problem. In my case it was domain controller is not accessible, because both dns servers was google dns.

I just add to checklist for this problem:

check domain controller is accessible

answered Aug 4, 2014 at 11:26

RailRail

7008 silver badges12 bronze badges

I was having the same issue, which turned out to be caused by the Domain login that runs the SQL service being locked out in AD. The lockout was caused by an unrelated usage of the service account for another purpose with the wrong password.

The errors received from SQL Agent logs did not mention the service account’s name, just the name of the user (job owner) that couldn’t be authenticated (since it uses the service account to check with AD).

answered Mar 4, 2015 at 0:51

I had to connect to VPN for the publish script to successfully deploy to the DB.

answered Apr 25, 2015 at 17:42

PetePete

1492 silver badges14 bronze badges

In our case, the Windows service account that SQL Server and SQL Agent were running under were locked out in Active Directory.

answered Jul 12, 2019 at 12:57

I just got this error and it turns out my AD administrator deleted the service account used by EVERY SQL Server instance in the entire company. Thank goodness AD has its own recycle bin.

See if you can run the Active Directory Users and Computers utility (%SystemRoot%system32dsa.msc), and check to make sure the account you are relying on still exists.

answered May 26, 2020 at 22:03

Источник

So I’m getting the error below, I’ve looked through several posts but they don’t seem relevant since all accounts are on the domain. In the error log I see (ConnIsLoginSysAdmin) at the end of the error

It’s on W2k12 R2 SQL 2012

The accounts that run SQL Agent & Engine are both domain members. The user running the jobs has dbo role on the databases.

Originally the jobs ran under one user then I changed them to a generic domain account and started having problems. I reviewed the permissions and the job ran fine for a day in a half. Then started getting this error again. Other jobs run fine
under other accounts.

I’m wondering if I should be assigning one of these roles to the user that runs the job or to the SQLAgent account.

SQLAgentUserRole
SQLAgentReaderRole
SQLAgentOperatorRole

Also I’m running both IPv6 & 4 and I’ wondering if this could be an issue.

Source:        SQLSERVERAGENT
Date:          4/27/2018 5:30:00 AM
Event ID:      208
Task Category: Job Engine

SQL Server Scheduled Job ‘XYZ’ — Status: Failed — Invoked on: 2018-04-27 05:30:00 — Message: The job failed. Unable to determine if the owner (domainsqlusr) of job XYZ has server access (reason: Could not obtain information about Windows NT group/user
‘domainsqlusr’, error code 0x5. [SQLSTATE 42000] (Error 15404)).

Источник

It’s on W2k12 R2 SQL 2012

The accounts that run SQL Agent & Engine are both domain members. The user running the jobs has dbo role on the databases.

I’m wondering if I should be assigning one of these roles to the user that runs the job or to the SQLAgent account.

SQLAgentUserRole
SQLAgentReaderRole
SQLAgentOperatorRole

Also I’m running both IPv6 & 4 and I’ wondering if this could be an issue.

Source:        SQLSERVERAGENT
Date:          4/27/2018 5:30:00 AM
Event ID:      208
Task Category: Job Engine

Источник

Добрый день, коллеги! Помогите с проблемой — не получается выполнить план обслуживания SQL server 2019. Ошибка внутри Агента

Сообщение
[298] Ошибка SQLServer: 15404, Не удалось получить сведения о пользователе или группе Windows NT «DOMENJulia», код ошибки: 0x5. [SQLSTATE 42000] (ConnIsLoginSysAdmin)

Подскажите что не так…

Последнее редактирование: 20.09.2021

Еще вижу пару ошибок, не ясно относится это к делу или нет

Дата 20.09.2021 11:35:22
Журнал Агент SQL Server (Текущий — 20.09.2021 11:35:00)
Сообщение
[408] SQL Server MSSQLSERVER является кластеризованным сервером — возможность автозапуска (AutoRestart) отключена

Дата 20.09.2021 11:35:22
Журнал Агент SQL Server (Текущий — 20.09.2021 11:35:00)

Сообщение
[396] Не определено условие простоя процессора — расписания заданий типа OnIdle использоваться не будут

Попробуйте использовать SA а не «DOMENJulia

Можно попробовать пересоздать план обслуживания

Попробуйте использовать SA а не «DOMENJulia

А где это делать ??

Создала план обслуживания заново, заработало)

Как я понял, это происходит из-за изменения названия домена или имени ПК (при этом изменяется имя сервера). А у пользователя остаётся предыдущее имя. Например, у вас было имя «DOMENJulia», соответственно имя сервера «DOMEN». Вы меняете имя компьютера на другое, имя сервера тоже меняется на «дргуое», а ваше имя остаётся «DOMENJulia», вместо «другоеJulia». Точнее, оно меняется, но при создании объектов в поле «владелец» записывается старое имя, которое уже не проходит проверку безопасности.

Вот что у меня сейчас и вот что показывает, когда создаю новую БД:

БД.png

Помогло изменение владельца на sa.

Источник

SQLServer Error 15404 can be resolved with Bobcares by your side.

At Bobcares, we offer solutions for every query, big and small, as a part of our SQL Server Support.

Let’s take a look at how our Support Team is ready to help customers resolve SQLServer Error 15404.

How to resolve SQLServer Error 15404

SQL server error 15404 occurs due to the specification of an invalid principal. Furthermore, the error may also pop up when the impersonation of a Windows account fails due to no full trust relationship between the domain of the Windows account and the SQL Server service account.

For instance, suppose we run a few high privilege T-SQL statements like sp_addsrvrolemember or Create Login, we may find ourselves facing Error 15404.

In this scenario, we will see notice messages in PALLOG. In case the PALLOG is disabled, we have to enable it manually by creating /var/opt/mssql/logger.ini with the following content:

How to fix SQLServer Error 15404

[Output:sql]
type=File
filename=/var/opt/mssql/log/pallog.txt

[Logger:security]
level=debug
outputs=sql

Let’s take a look at the messages in PALLOG:

03/12/2022 12:36:56.448761588 Debug [security.kerberos] <0000040947/0x00000200> Processing SSPI operation 0x0000000F

03/12/2022 12:36:56.439366379 Error [security.ldap] <0000040947/0x00000200> Initializing credentials for use in new cache failed: Keytab contains no suitable keys for red4$@SQLREPRO.EDU

03/12/2022 12:36:56.439613575 Debug [security.kerberos] <0000040947/0x00000200> Import name [ADMINISTRATOR@SQLREPRO.EDU] returned [ADMINISTRATOR@SQLREPRO.EDU]

03/12/2022 12:36:56.439633375 Debug [security.kerberos] <0000040947/0x00000200> Import name [red4$] returned [red4$]

03/12/2022 12:36:56.439753473 Debug [security.kerberos] <0000040947/0x00000200> Import name [RED4$] returned [RED4$]

03/12/2022 12:36:56.439905471 Debug [security.kerberos] <0000040947/0x00000200> Import name [red4$] returned [red4$]

03/12/2022 12:36:56.440014469 Error [security.kerberos] <0000040947/0x00000200> GSS MAJOR: 851968 GSS MINOR: 39756033 Error acquiring credentials in AcquireCredCaseInsensitive

03/12/2022 12:36:56.440029069 Error [security.kerberos] <0000040947/0x00000200> Unspecified GSS failure. Minor code may provide more information

03/12/2022 12:36:56.440039869 Error [security.kerberos] <0000040947/0x00000200> No key table entry found for red4$@SQLREPRO.EDU

03/12/2022 12:36:56.440053069 Debug [security.kerberos] <0000040947/0x00000200> SSPI operation 0x0000000F returned status: KerberosStream.cpp:2021 Operation unsuccessful

03/12/2022 12:36:56.440119868 Debug [security.kerberos.libos] <0000040961/0x0000020c> GetSecContextByUserABI() return value: 0x80090304

03/12/2022 12:36:56.468617991 Debug [security.kerberos.libos] <0000040961/0x0000020c> QueryContextAttributes() return value: 0x00000000

03/12/2022 12:36:56.468748289 Debug [security.kerberos.libos] <0000040961/0x0000020c> QueryContextAttributes() return value: 0x00000000

03/12/2022 13:56:26.489370580 Debug [security.kerberos.libos] <0000040961/0x0000020c> LookupAccountSid() return value: 0x00000001

As seen above, queries like Create login require checking permissions. The first time this is done, current permission is invalidated. When we repeat it, the permission check is rechecked. Furthermore, during the permission check, the SQL Server will go through the myssql.keytab to find the machine entry key or MSA key

In case the SQL Server cannot find the entries or finds invalid entries, it results in an error.

If we find ourselves facing this particular error, our Support Engineers suggest ensuring the Windows principal exists in addition to not being misspelled. Here are a few more troubleshooting tips courtesy of our Support Team to resolve this issue:

Ensure we use an account from the same Windows user domain for the SQL Server service.
If SQL Server uses a machine account like Local System or Network System, the machine has to be trusted by the Windows User domain.
Use a SQL Server account

[Looking for a solution to another query? We are just a click away.]

Conclusion

To sum up, our skilled Support Engineers at Bobcares demonstrated how to fix SQLServer Error 15404.

PREVENT YOUR SERVER FROM CRASHING!

Never again lose customers to poor server speed! Let us help you.

Our server experts will monitor & maintain your server 24/7 so that it remains lightning fast and secure.

GET STARTED

Источник

Код ошибки 0x5 sqlstate 42000 ошибка 15404

Question

Answers

How to resolve SQLServer Error 15404

Conclusion

PREVENT YOUR SERVER FROM CRASHING!

А вот еще интересные материалы: