Меню

Microsoft sql server ошибка 15404

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

  • Remove From My Forums
  • Question

  • Running SQL Server 2016 Developer version at home on Windows 10 Pro x64. I’ve added AdventureWorksDW2014, altered the DB Owner to my login name and tried to add a database diagram.

    I get the error «Could not obtain informaton about Windows NT group/user ‘my machinemy name’, error code 0x534. (Microsoft SQL Server, Error:15404)»

    References I’ve found on-line seem to refer to this problem in relation to SQL Server Agent and the account that is running under. When I installed SQL Server, I just accepted the defaults with regards accounts the various services run
    under.

    Under security, I have my login listed as sysadmin so I think I should have permissions to create the DB diagram.


    Nick Ryan MIS Programmer Analyst, ANZ Bank

Answers

    • Edited by

      Tuesday, February 7, 2017 5:43 AM

    • Proposed as answer by
      Sunil Gure
      Tuesday, February 7, 2017 7:41 AM
    • Marked as answer by
      Nick Ryan
      Wednesday, February 8, 2017 8:22 PM

Permalink

Cannot retrieve contributors at this time

description title ms.custom ms.date ms.service ms.reviewer ms.subservice ms.topic helpviewer_keywords ms.assetid author ms.author

MSSQLSERVER_15404

MSSQLSERVER_15404 | Microsoft Docs

04/04/2017

sql

supportability

reference

15404 (Database Engine error)

69677f02-bc81-4e4a-99b8-5c1bd1de36df

MashaMSFT

mathoma

MSSQLSERVER_15404

[!INCLUDE SQL Server]

Details

Attribute Value
Product Name SQL Server
Event ID 15404
Event Source MSSQLSERVER
Component SQLEngine
Symbolic Name SEC_NTGRP_ERROR
Message Text Could not obtain information about Windows NT group/user ‘user‘, error code code.

Explanation

15404 is used in authentication when an invalid principal is specified. Or, impersonation of a Windows account fails because there is no full trust relationship between the [!INCLUDEssNoVersion] service account and the domain of the Windows account.

User Action

Check that the Windows principal exists and is not misspelled.

If this error is the result of a lack of a full trust relationship between the [!INCLUDEssNoVersion] service account and the domain of the Windows account, one of the following actions can resolve the error:

  • Use an account from the same domain as the Windows user for the [!INCLUDEssNoVersion] service.

  • If [!INCLUDEssNoVersion] is using a machine account such as Network Service or Local System, the machine must be trusted by the domain containing the Windows User.

  • Use a [!INCLUDEssNoVersion] account.

  • Remove From My Forums
  • Question

  • Hello,

    I’m having trouble running jobs with my active directory (ADS) account. I’ve setup my SQL services to run under an ADS account, but jobs cannot seem to query ADS for user information. We’re running Windows Server 2003 and SQL Server 2005 SP2.

     Here is the error message:

    ==

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

    ==

    also this message in log:

    ==

    [298] SQLServer Error: 15404, Could not obtain information about Windows NT group/user ‘ADSme, error code 0x5. [SQLSTATE 42000] (ConnIsLoginSysAdmin)

    ==

    I already tested the suggested:

    execute as login=’adsme’ and I get the same error on both (my local installations and production)

    appreciate your help

Answers

  •   Most likely the machine account doesn’t have permission to query the AD.

      I would recommend requesting access to the AD administrator or change SQL Server and run the service as a low-privileged domain account that has proper permissions on the AD.

    -Raul Garcia

      SDE/T

      SQL Server Engine

SQL Server Reporting Services, in SSRS it seems like Schedules never fire, however a look at the SQL Agent reveals a permission issue related to not being able to resolve a user account.

Seems SQL Agent does not rely on caching or whatever voodoo Windows magically works.

link text
Fix is listed here…
edit —

Above is the fix I used to workaround this issue, has any one found any other work arounds or resolutions to this issue?

It seems that by default the SSRS Generated Schedules are run as this phantom user account. How do I change this default? Is SSRS creating the jobs as the user the service runs as?

Thanks Remus

Community's user avatar

asked Dec 15, 2009 at 4:28

john.da.costa's user avatar

john.da.costajohn.da.costa

4,6324 gold badges28 silver badges30 bronze badges

1

I was running into the same issue. Here is how I fixed it.

Problem description
When setting an SSRS report subscription to run at a given time, I would wait for the time to pass and then find that the «Last Run» timestamp did not change. My subscription appears not to have run.

Relevant troubleshooting info

  1. SSRS report subscriptions are executed as SQL Jobs that the Report Server web UI creates for you behind the scenes.

  2. When looking at the job that was created for my report subscription, I saw that it always failed with the error:

    The job failed. Unable to determine if the owner (domainuserName) of job 0814588B-D590-4C45-A304-6086D5C1F559 has server access (reason: Could not obtain information about Windows NT group/user ‘domainuserName’, error code 0x5. [SQLSTATE 42000] (Error 15404)).

  3. In the Sql Server Configuration Manager I could see that the «SQL Server Reporting Services» service was configured to run using an AD user account.

  4. In the Sql Server Configuration Manager I could see that the «SQL Server» service was configured to run using a local Windows account.

  5. As @Remus Resanu pointed out, the SQL error 15404 refers to an exception when EXECUTE AS context cannot be impersonated.

Solution
Bingo! #4 and #5 are the key to the problem. The SQL Server service (a local Windows user account) was trying to authenticate the user «domainuserName» in AD, which it could not do because it does not have the right/permission to access AD resources.

I changed the SQL Server service to us an AD user account, restarted the SQL Server and SQL Server Agent services, re-ran the SQL job and, blamo, success!

answered Jul 30, 2013 at 19:04

Vince Horst's user avatar

15404 is the exception when EXECUTE AS context cannot be impersonated. Reasons for these error are plenty. The most common reasons are:

  • when the SQL Server instance does not have access to the AD server because is running as a local user or as ‘local service’ (this would have an error code 0x5, ACCESS_DENIED)
  • when the SQL Server is asked to impersonate an unknown user, like an user from a domain the SQL Server has not idea about (this would have the error code 0x54b, ERROR_NO_SUCH_DOMAIN)

The proper solution is always dependent on the error code, which is the OS error when trying to obtain the impersonated user identity token: one searches first for the error code in the System Error Codes table (or fires up windbg, does a loopback non-invasive kernel debug connection and goes !error, which is what I prefer cause is faster…).

So, John… do you actually have a question, or just posted a random piece of partial information?

answered Dec 15, 2009 at 5:13

Remus Rusanu's user avatar

Remus RusanuRemus Rusanu

285k40 gold badges429 silver badges564 bronze badges

I did 2 things and it’s now working.

1) Go to «SQL Server Configuration», change the «SQL Server Agent» — «Log On As» to match the «SQL Server» above.

enter image description here

2) Secondly, open «Microsoft SQL Management Studio», at the «SQL Server Agent», expand the «Jobs» and you should be able to see your created job. Right click on it and go to «Properties».
enter image description here

3) Change the owner to also match the «SQL Server Agent» above.
enter image description here

After, I’m able to execute the Maintenance Plan without any issue.

answered Dec 4, 2018 at 4:38

TPG's user avatar

TPGTPG

2,4911 gold badge29 silver badges49 bronze badges

Just follow this steps in images

Just follow this steps in images

answered Mar 8, 2019 at 7:32

TuanDPH's user avatar

TuanDPHTuanDPH

4614 silver badges13 bronze badges

SQL Server Agent 15404 Error

If you encounter in the Sql Server Agent Log «SQLServer Error: 15404, Could not obtain information about Windows NT group/user ‘ISTMRKSQLHOSTAdministrator’, error code 0x534. [SQLSTATE 42000] (ConnIsLoginSysAdmin)» this is related with Sql Server Agent job security.

Open Sql Server Management Studio, go to Object Explorer select Jobs under SQL Server Agent. Find your Maintenance Plan and right click on it, select Properties. On the General Page change Owner to ‘sa‘. Then execute the maintenance plan again.

Popular posts from this blog

On HP 3PAR Storage, disks are grouped inside magazines. So when it comes to replacing a failed disk, magazine that holds the disk has to be brought offline using a servicemag start command.

In this post, I am going to explain configuring multiple VLANs on a bond interface. First and foremost, I would like to describe the environment and give details of the infrastructure. The server has 4 Ethernet links to a layer 3 switch with names: enp3s0f0, enp3s0f1, enp4s0f0, enp4s0f1 There are two bond interfaces both configured as active-backup bond0, bond1 enp4s0f0 and enp4s0f1 interfaces are bonded as bond0. Bond0 is for making ssh connections and management only so corresponding switch ports are not configured in trunk mode. enp3s0f0 and enp3s0f1 interfaces are bonded as bond1. Bond1 is for data and corresponding switch ports are configured in trunk mode. Bond0 is the default gateway for the server and has IP address 10.1.10.11 Bond1 has three subinterfaces with VLAN 4, 36, 41. IP addresses are 10.1.3.11, 10.1.35.11, 10.1.40.11 respectively. Proper communication with other servers on the network we should use routing tables. There are three

Recently I have to export the user list for a particular domain. Luckily Zimbra has Admin GUI with a search feature. When you search accounts, you can download search results as a comma-separated csv file. So I did a search and download the result file, but the result did not have all the columns I need and also there is no option for customizing columns for search results. So I had to write a bash script to get the desired list. Here is the bash script ( It can be customized by adding or removing field names. Run it under zimbra user like ./zimbra_account_list.sh <domain_name_here> ):

  • Remove From My Forums
  • Question

  • Hello,

    Thank you all in advance for a reply (and hopefully a solution!).

    Intermittently, we receive the following error when a SQL Agent Job is started:

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

    Again, the key word is intermittently. Our processes work most nights, but sometimes the above error pops up. This happens for various jobs at various times.

    Additionally, this error has been seen with DTS packages in SQL Server 2000.

    I do not believe this is a permissions issue with the service account, because as I said, most of the time it works. However when it doesn’t, our on call gets paged in the middle of the night to simply restart the process. That is no fun at all!

    Any ideas??

  • Remove From My Forums
  • Question

  • Hello,

    Thank you all in advance for a reply (and hopefully a solution!).

    Intermittently, we receive the following error when a SQL Agent Job is started:

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

    Again, the key word is intermittently. Our processes work most nights, but sometimes the above error pops up. This happens for various jobs at various times.

    Additionally, this error has been seen with DTS packages in SQL Server 2000.

    I do not believe this is a permissions issue with the service account, because as I said, most of the time it works. However when it doesn’t, our on call gets paged in the middle of the night to simply restart the process. That is no fun at all!

    Any ideas??

0 0 голоса
Рейтинг статьи
Подписаться
Уведомить о
guest

0 комментариев
Старые
Новые Популярные
Межтекстовые Отзывы
Посмотреть все комментарии

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

  • Яшка сломя голову остановился исправьте ошибки
  • Ясность цели позволяет целеустремленно добиваться намеченного исправьте ошибки
  • Ясность цели позволяет целеустремленно добиваться намеченного где ошибка
  • Microsoft sql server ошибка 15025
  • Microsoft sql server ошибка 1418