10

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_NAME\SomeDomainAccount', 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 Service\MSSQL$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

Improve this question
4
  • Update, this has happened two more times since the post.
    – crokusek
    Mar 7, 2014 at 22:58
  • Possibly related, we also have an intermittent (weekly) cannot generate SSPI problem on two different servers.
    – crokusek
    Nov 13, 2014 at 18:45
  • I'll just add that I've just randomly got this error from a SQL script that was working yesterday. No changes to the script, exact same machine, no obvious errors in the windows logs. The offending line of SQL was a CREATE ASSEMBLY statement, AUTHORIZATION [dbo], PERMISSION_SET = EXTERNAL_ACCESS;
    – redcalx
    Apr 9, 2015 at 9:34
  • More info. Restarting SQL Server didn't resolve the issue, but rebooting the machine did. Possibly a log-off/on would have done it, as I suspect it's some subtle issue around my domain account. Note that I haven't changed my password recently.
    – redcalx
    Apr 9, 2015 at 9:46

2 Answers 2

Reset to default
4

Not a solution, but you can work around the issue by making the job owner a SQL account.

Each time a job is started, SQL Server verifies the identity of the job owner and checks that it has permission to execute the job. If the owner is a Windows account, the engine needs to query Active Directory. If for any reason that fails, the job will not run. It could be because the AD server is busy, down or cut off from the network, or that the SQL Server service account doesn't have rights.

Since it works immediately after rebooting, that makes me think it might have something to do with cached credentials. Windows will save the credentials it looks up for later use. That cache is cleared on reboot. Perhaps something is corrupting the cache.

Improve this answer
1
  • I believe you are correct it is cached credentials, rebooting forces a login to the active directory server. I get this error on DB Diagrams When I am disconnected from the company network, I connect to it and no error. Disconnect and my permission is lost. I can query , create etc - just can't diagram. 15404 error.
    – StixO
    Feb 15, 2020 at 11:20
0

I had a issue with an instance moved from domain A to domain B And checked permissions everywhere and granted full control everywhere. Changed service account, job ownership, created new job.... Nothing worked. Found same name of service user B\sqlservice and A\sqlservice existing as login on SQL Server After deleting the A\sqlservice login everything started to work fine. This means some windows pointers were wrong

Improve this answer
1
  • To clarify, you were getting this error, and the error reported that B\sqlservice was the account it couldn't obtain information about?
    – RDFozz
    Nov 21, 2017 at 16:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.