September 14, 2017 at 8:26 am
We are running SQL Server 2012 SP3 with Windows Server 2008 R2 Enterprise SP1. We have jobs that have been set up with a windows login (non-expiring). These jobs have been running for over 3 years. On yesterday (9/13/17), these jobs failed with the following error:
"MESSAGES: The job failed. Unable to determine if the owner (Domain\LoginName) of job JobName has server access (reason: Could not obtain information about Windows NT group/user 'Domain\LoginName', error code 0x5. [SQLSTATE 42000] (Error 15404))."
The best practice is to define jobs with 'sa' as the owner. So, I made the change and the jobs run fine. My question is, what changed on yesterday that cause the jobs to fail all of a sudden? Could Microsoft Updates have caused these jobs to stop working?
Thanks in advance for any input.
September 14, 2017 at 8:30 am
Sounds like the Server could not authenticate the Login. Most likely the SQL Server couldn't reach the Domain Controller to authenticate, thus "didn't know" if the user had permissions.
Thom~
Excuse my typos and sometimes awful grammar. My fingers work faster than my brain does.
Larnu.uk
September 14, 2017 at 8:35 am
Have you done any login cleanup recently?
Removing a principal from the server can also cause the above error.
September 14, 2017 at 9:15 am
HookSqlDba7 - Thursday, September 14, 2017 8:26 AMWe are running SQL Server 2012 SP3 with Windows Server 2008 R2 Enterprise SP1. We have jobs that have been set up with a windows login (non-expiring). These jobs have been running for over 3 years. On yesterday (9/13/17), these jobs failed with the following error:"MESSAGES: The job failed. Unable to determine if the owner (Domain\LoginName) of job JobName has server access (reason: Could not obtain information about Windows NT group/user 'Domain\LoginName', error code 0x5. [SQLSTATE 42000] (Error 15404))."
The best practice is to define jobs with 'sa' as the owner. So, I made the change and the jobs run fine. My question is, what changed on yesterday that cause the jobs to fail all of a sudden? Could Microsoft Updates have caused these jobs to stop working?
Thanks in advance for any input.
Error 0x5 is access denied. The change could also be due to some permissions changes for the accounts to read AD. I believe verifying the logins goes through xp_logininfo to determine those. You can try executing the same extended stored procedure, play around with that and see if you get access denied errors. (0x5).
I'd also ask the windows group or whoever, if they rolled out any new policy changes.
Are the service accounts members of the Windows Authorization Access group? Check this link and you'll see why I asked:
Some applications and APIs require access to authorization information on account objects
Sue
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply