November 27, 2018 at 5:33 am
We used a password vault system to change and push the passwords for MSSQLSERVER and SQLAgent accounts on this specific SQL Server. We do this on a regular basis without any issues without restarting the SQL Server services. However, once in a great while jobs owned by a different domain account will not be able to access or run jobs within SQL Server and we then have to restart the SQL Server services in order to fix this. Or some domain accounts cannot log into SQL Server but those passwords were not changed, only the service ID passwords.
Jobs owned by and run within this specific SQL Server get this error below. I have tried researching this but cannot find an issue like mine where the service passwords were changed.
Unable to determine if the owner (domaina\personID) of job (reason: Could not obtain informationabout Windows NT group/user 'domaina\personID', error code 0x5. [SQLSTATE 42000](Error 15404)).
This specific server is running Windows 2012 and SQL 2014 SP2 CU10
Any ideas on this? Like I said, 99.9% of the time when we change the passwords for the service ID passwords we don't have any issues.
November 27, 2018 at 5:46 am
Summer90 - Tuesday, November 27, 2018 5:33 AMWe used a password vault system to change and push the passwords for MSSQLSERVER and SQLAgent accounts on this specific SQL Server. We do this on a regular basis without any issues without restarting the SQL Server services. However, once in a great while jobs owned by a different domain account will not be able to access or run jobs within SQL Server and we then have to restart the SQL Server services in order to fix this. Or some domain accounts cannot log into SQL Server but those passwords were not changed, only the service ID passwords.Jobs owned by and run within this specific SQL Server get this error below. I have tried researching this but cannot find an issue like mine where the service passwords were changed.
Unable to determine if the owner (domaina\personID) of job (reason: Could not obtain informationabout Windows NT group/user 'domaina\personID', error code 0x5. [SQLSTATE 42000](Error 15404)).
This specific server is running Windows 2012 and SQL 2014 SP2 CU10
Any ideas on this? Like I said, 99.9% of the time when we change the passwords for the service ID passwords we don't have any issues.
As far as I know, password changes on service accounts do not take effect (for currently running services using these credentials) until the service is restarted ... though I am not sure whether that has any relevance here.
What is peculiar, though, is the grammar used in the error message. It appears to be devoid of an object:
"Unable to determine if the owner (...) of job" ... is what, exactly? Stevie Wonder? Out to lunch? Legally entitled to run jobs on this server?
The absence of evidence is not evidence of absence
- Martin Rees
The absence of consumable DDL, sample data and desired results is, however, evidence of the absence of my response
- Phil Parkin
November 27, 2018 at 5:58 am
The ID that owns and runs these jobs that have run for years successfully are now failing after the service ID password change. If I restart the SQL Server services the jobs will resume running successfully. I am attempting to figure out why a user within SQL Server cannot access SQL Server after a different ID password that runs the SQL Server service password changes. Like I have stated, we do this on a regular basis without bouncing the server or the services and it carries on just fine. This one specific time it did not.
November 27, 2018 at 7:23 am
Does the user ID named as being the job owner still exist in the domain?
Thomas Rushton
blog: https://thelonedba.wordpress.com
November 27, 2018 at 7:28 am
ThomasRushton - Tuesday, November 27, 2018 7:23 AMDoes the user ID named as being the job owner still exist in the domain?
Yes it does.
November 27, 2018 at 9:11 am
Summer90 - Tuesday, November 27, 2018 7:28 AMThomasRushton - Tuesday, November 27, 2018 7:23 AMDoes the user ID named as being the job owner still exist in the domain?Yes it does.
Those errors generally indicate a problem with accessing the domain controller to validate credentials. Sounds like the password is changed in SQL - but not yet changed on the DC so jobs trying to run in the context of the service ID cannot authenticate on that DC. Restarting SQL Server connects to a different DC or resets the connection to the DC and then allows authentication.
Jeffrey Williams
“We are all faced with a series of great opportunities brilliantly disguised as impossible situations.”
― Charles R. Swindoll
How to post questions to get better answers faster
Managing Transaction Logs
November 27, 2018 at 9:22 am
Jeffrey Williams 3188 - Tuesday, November 27, 2018 9:11 AMSummer90 - Tuesday, November 27, 2018 7:28 AMThomasRushton - Tuesday, November 27, 2018 7:23 AMDoes the user ID named as being the job owner still exist in the domain?Yes it does.
Those errors generally indicate a problem with accessing the domain controller to validate credentials. Sounds like the password is changed in SQL - but not yet changed on the DC so jobs trying to run in the context of the service ID cannot authenticate on that DC. Restarting SQL Server connects to a different DC or resets the connection to the DC and then allows authentication.
Interesting thought.
So, for this SQL Server and one other one we changed the service ID passwords on the 16th.. jobs ran fine from the 16th through the 22nd and then started getting these errors, BOTH SQL Servers not just one of these both had jobs failing for this same reason on the 22nd. It is like they changed DCs or some type of cache of something expired. I must say I an not an expert on domains and domain controllers though.
November 27, 2018 at 9:56 am
I've seen this type of thing before. Often this is some cached credential being used, either from the service or the DC, and depending on when updates invalidate the cache, this can be maddening. Changing a service account password should have a restart of all services, since this should require a new domain login, but there are times this fails, often because DCs aren't replicating properly and the registration of the service isn't taking.
There are a few articles on SPN errors, but that's not quite what you have here. It's similar, however. The domain credential thing is a mystery for me as well. It will work great 88 times and then fail once, which is maddening.
November 27, 2018 at 10:02 am
Steve Jones - SSC Editor - Tuesday, November 27, 2018 9:56 AMI've seen this type of thing before. Often this is some cached credential being used, either from the service or the DC, and depending on when updates invalidate the cache, this can be maddening. Changing a service account password should have a restart of all services, since this should require a new domain login, but there are times this fails, often because DCs aren't replicating properly and the registration of the service isn't taking.There are a few articles on SPN errors, but that's not quite what you have here. It's similar, however. The domain credential thing is a mystery for me as well. It will work great 88 times and then fail once, which is maddening.
Thanks everyone for your input. I am working with our Security/Network team on this now.
Like you said Steve.... We have probably done this hundreds of times and this is now only the third failure. Most very critical ones we change the password right before server restarts for Windows patching. We may have to change this to changing the passwords for all servers right before patching.
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply