Sql ошибка 15404 как исправить

Every so often (e.g. ~months) a SQL Server Agent hourly Job will begin reporting an Error 15404 and continue to do so until intervened with.

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

Sometimes the first failure occurs immediately after a manual restart of the SQL Server Engine and SQL Server Agent services. The problem can be cleared by rebooting the machine.

The Job Owner is the name listed in the error message and is a SQL Server Admin.

The SQL Server Engine Service account looks to be a service account (I believe it is the default install account (one notch better than generic NetworkService to prevent interference between Engine/Agent instances):

   NT ServiceMSSQL$INSTNAME

It would be one thing if the job always failed but since the job succeeds after a reboot it makes me think that a service account like is supposed to be working and that there is some A/D timing issue or possibly a bug. When IT is asked about the A/D configuration, the response is usually “nothing has changed.”

• Restarting the engine and agent services can cause the job to start failing.
• A machine reboot clears the problem.
• An immediate subsequent restart of the engine and agent no longer cause the job to fail.

Link:
How to troubleshoot a SQL Server 8198 error

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.