Search code, repositories, users, issues, pull requests…
Provide feedback
Saved searches
Use saved searches to filter your results more quickly
Sign up
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:
[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
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 (ADS\me) of job eFASRtest has server access (reason: Could not obtain information about Windows NT group/user ‘ADS\me’, 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 ‘ADS\me, error code 0x5. [SQLSTATE 42000] (ConnIsLoginSysAdmin)
==
I have done a *lot* of searching and cannot find the solution. I believe the 0x5 code is access denied.
The same job runs if I change the owner to a SQL login that’s not an ADS account.
I’m not certain how to confirm that the SQL Agent account is the account actually querying ADS, also.
Any help would be greatly appreciated!
Thanks,
-Tony
I have a Windows 2012 Server running SharePoint 2010 using an SQL Server Express locally installed. Unfortunately my logs are currently flooding with message «An exception occurred while enqueueing a message in the target queue. Error: 15404, State: 19. Could not obtain information about Windows NT group/user ‘DOMAIN\user’, error code 0x5.» It can be 20 such messages every second!
(…and the ‘DOMAIN\user’ happens to be my personal account.)
Are there a job running that has missing rights? «Qoute from https://serverfault.com/questions/277551/mssqlserver-exception-occurred-while-enqueueing-a-message-in-the-target-queue-e «Try to changing the owner of the jobs to the sa account, on the properties of the job.» If I’m correct the express version of SQL server cannot run jobs? Or is there someone/something that wants access to our AD? Why do that account wants to obtain information about my account 20 times every second?
I do find lot’s of blogs and hints about this task, but I just dont understand the solutions. One says «To repair this, login as one of the SA accounts and grant SA access for the account that needs it.» But what account needs sa access?
asked Sep 15, 2014 at 10:22
1
Change the owner to sa. Here are the steps I took to solve this issue:
-
Right-Click on the database and select properties
-
Click on Files under the
Select a page -
Under the
Owner, but just below the Database Name on the right-hand pane, selectsaas the owner.
ΩmegaMan
29.6k12 gold badges100 silver badges122 bronze badges
answered Aug 21, 2017 at 10:09
olasammyolasammy
6,7064 gold badges26 silver badges32 bronze badges
6
In my case, sa was not the owner of the DB, I was. When I tried to execute CLR configuration that required sa privileges, I got the error too.
The solution:
USE MyDB
GO
ALTER DATABASE MyDB set TRUSTWORTHY ON;
GO
EXEC dbo.sp_changedbowner @loginame = N'sa', @map = false
GO
sp_configure 'show advanced options', 1;
GO
RECONFIGURE;
GO
sp_configure 'clr enabled', 1;
GO
RECONFIGURE;
GO
I used help from the db team at work and this post to find the answer.
starball
21.1k7 gold badges47 silver badges255 bronze badges
answered Nov 17, 2014 at 21:46
Chaim EliyahChaim Eliyah
2,7534 gold badges24 silver badges37 bronze badges
7
In my case the owner of the database was a domain account Domain\Me.
The error message was
Error: 15404, State: 19. Could not obtain information about Windows NT
group/user ‘Domain\MyAccount’
The problem was that the database didn’t know what to do with the domain account — so the logical thing to do was to use a local account instead.
I tried changing the owner of the database, but things still wouldn’t work correctly.
In the end I dropped and recreated the entire database MAKING SURE THAT THE OWNER WAS SA
I also set the Broker to Enabled in the settings
Thing started magically working after this
answered May 6, 2015 at 11:38
2
No Domain Authentication
Failure was ultimately due to the fact that it was not able to authenticate when I was not vpn-ed into the corporate network.
For I was connecting to a local db on my work laptop, however the User ‘DOMAIN\user’ needed to be authenticated by AD on the corporate network.
Error was resolved as soon as I reconnected and refreshed; the error disappeared.
ΩmegaMan
29.6k12 gold badges100 silver badges122 bronze badges
answered Jun 26, 2020 at 7:59
Ameet BhatAmeet Bhat
911 silver badge1 bronze badge
1
to do a bulk update for all databases, run this script and then execute its output:
SELECT 'ALTER AUTHORIZATION ON DATABASE::' + QUOTENAME(name) + ' TO [sa];'
from sys.databases
where name not in ('master', 'model', 'tempdb')
answered Mar 26, 2018 at 17:05
avs099avs099
10.9k6 gold badges60 silver badges110 bronze badges
I had this error from a scheduled job in sql Server Agent, in my case, just after I changed the hostname of the Windows Server. I had also ran sp_dropserver and sp_addserver. My database was owned by «sa», not a Windows user.
I could login into SQL as the Windows user NEWHOSTNAME\username (I guess after a hostname change, the SID doesn’t change, that’s why it worked automatically?).
However, in SQL, in Security/Logins node, I had SQL logins defined as OLDHOSTNAME\username. I connected to SQL using «sa» instead of Windows Integrated, dropped the old logins, and create new ones with NEWHOSTNAME\username.
The error disappeared.
answered Jan 11, 2016 at 14:26
Thierry_SThierry_S
1,53616 silver badges25 bronze badges
I was having the same problem. In my case it was due to the fact that my machine was part of a domain, but I was not connected to the company VPN. The problem was solved after connecting to the VPN (so the domain user could be resolved by the SQLAgent).
answered Mar 1, 2021 at 13:41
erionpcerionpc
3783 silver badges16 bronze badges
I had the same issue where my domain login was not being recognized. All I did was go into the SQL Server configuration manager and start the services as Network Services instead of a local service. The sql server / agent was then able to recognize the AD logins for the jobs.
answered Jun 14, 2019 at 12:42
HaliHali
413 bronze badges
In my case, it was VPN issue. When I turned on the VPN to connect with my office network & then tried to start the snapshot agent again, it started successfully.
answered Oct 29, 2019 at 18:37
Ankush JainAnkush Jain
5,6844 gold badges32 silver badges57 bronze badges
2
I was facing the same issue.
Fix for me was changing the log-on from NT User to global user in Sql Server Configuration Manager => Sql Server Service => Sql Server Agent => Properties => Account name.
answered Apr 4, 2020 at 9:10
Jitan GuptaJitan Gupta
4646 silver badges18 bronze badges
You should be connected with your domain. (VPN)
answered Feb 8, 2022 at 8:53
WouterWouter
2,56019 silver badges31 bronze badges
- Remove From My Forums
-
Question
-
I am trying to learn replication and using Agent jobs while attached to my corporate domain. Trying to use my personal domain account to run jobs or replication, I keep getting:
SQL Server Error 15404, Could not obtain information about Windows NT group\user ‘MyName\MyDomain’, error code 0x5 [SQLSTATE 42000] (ConnIsLoginSysAdmin)
What might be preventing SQL Server from getting my account information from the domain? Group ploicy?
Thanks in advance,
Richard
Answers
-
Changing the SQL Server Agent services (on both the publisher and subscriber) to run under my personal domain account has things working properly. I will have to experiment with other settings and the Local System account to see what exactly went wrong.
Thanks you all for your advice (pre-holiday activities delayed getting this fixed — thanks for your patience and have a great holiday yourselves!)
Richard