Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 12»»

SQL Agent Job Sudden Failure, Login failed for user NT AUTHORITY\SYSTEM. Expand / Collapse
Author
Message
Posted Friday, February 01, 2013 8:52 AM


SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Yesterday @ 6:09 AM
Points: 179, Visits: 1,091
I have a scheduled job (runs every Friday at 5am) that has been running since 9/2011. Suddenly, the job failed this morning with a "Login failed for user 'NT AUTHORITY\SYSTEM'... " error message.

1) There are other jobs that run using the same account. Just to test, I re-started a different job this morning and it ran fine.
2) I took all of the code from the original job (that is now failing), created a new job that is identical (except for the names) and it runs fine.

Without getting into the pro(s) and con(s) of running services under NETWORK SERVICE or the BUILTIN\Administrator (PLEASE!), has anyone seen this before? Is this just some incident of a job becoming corrupt?



Argue your limitations and sure enough they will be yours (Richard Bach, Illusions)
Post #1414716
Posted Monday, February 04, 2013 1:10 PM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 1:24 PM
Points: 6,826, Visits: 11,950
When you say "run using the same account" do you mean the jobs have the same owner?

Are there any job steps that use proxies?



__________________________________________________________________________________________________
There are no special teachers of virtue, because virtue is taught by the whole community. --Plato

Believe you can and you're halfway there. --Theodore Roosevelt

Everything Should Be Made as Simple as Possible, But Not Simpler --Albert Einstein

The significant problems we face cannot be solved at the same level of thinking we were at when we created them. --Albert Einstein

1 apple is not exactly 1/8 of 8 apples. Because there are no absolutely identical apples. --Giordy
Post #1415472
Posted Tuesday, February 05, 2013 5:03 AM


SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Yesterday @ 9:10 PM
Points: 2,693, Visits: 1,080
DB_Newbie2007 (2/1/2013)
"Login failed for user 'NT AUTHORITY\SYSTEM'... "


Is that message coming from the SQL Agent Job, or the code that the job is running?

Are there any other errors or warnings in the Windows Event Viewer?



Hope this helps
Phill Carter
--------------------
Colt 45 - the original point and click interface

Australian SQL Server User Groups - My profile
Phills Philosophies
Murrumbeena Cricket Club
Post #1415750
Posted Monday, February 11, 2013 7:32 AM


SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Yesterday @ 6:09 AM
Points: 179, Visits: 1,091
Sorry for taking so long to response back on this... I know I personally do not like it when a thread suddenly "quits" without any resolution, especially when I am trying to research a problem.

- There were no errors in the Events log.
- The error was from SQL Agent (the code, run manually, executed fine).
- Yes, all of the jobs have the same "owner".

As mentioned in the original post, "I took all of the code from the original job (that is now failing), created a new job that is identical (except for the names) and it runs fine.", so the problem was resolved. However, I am still curious if anyone else ever experienced this kind of a problem or might have some insight as to the cause?

Thanks!




Argue your limitations and sure enough they will be yours (Richard Bach, Illusions)
Post #1418421
Posted Monday, February 11, 2013 7:36 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 1:24 PM
Points: 6,826, Visits: 11,950
Any proxies in play?

__________________________________________________________________________________________________
There are no special teachers of virtue, because virtue is taught by the whole community. --Plato

Believe you can and you're halfway there. --Theodore Roosevelt

Everything Should Be Made as Simple as Possible, But Not Simpler --Albert Einstein

The significant problems we face cannot be solved at the same level of thinking we were at when we created them. --Albert Einstein

1 apple is not exactly 1/8 of 8 apples. Because there are no absolutely identical apples. --Giordy
Post #1418427
Posted Monday, February 11, 2013 7:54 AM


SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Yesterday @ 6:09 AM
Points: 179, Visits: 1,091
Nope. No proxies.

The job is actually run with a custom higher level account with full permissions in every database. Yes, it has full SA permissions... again, please no discussions on the use of an "SA" level account to run the job... focus on the particular issue at hand, thanks!



Argue your limitations and sure enough they will be yours (Richard Bach, Illusions)
Post #1418447
Posted Monday, February 11, 2013 11:00 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 1:24 PM
Points: 6,826, Visits: 11,950
DB_Newbie2007 (2/11/2013)
Nope. No proxies.

The job is actually run with a custom higher level account with full permissions in every database. Yes, it has full SA permissions... again, please no discussions on the use of an "SA" level account to run the job... focus on the particular issue at hand, thanks!

What do you mean by that? The Login running the job has nothing to do with the security context the job runs under.

I am thinking the job owner of the original job left the company and their Active Directory account was deleted. Or if it was a SQL Login the login was deleted or they were removed from the sysadmin Role and that is why the job started failing.

When you recreated the job the owner is now you, or maybe you made it sa or some other valid login so now it works.


__________________________________________________________________________________________________
There are no special teachers of virtue, because virtue is taught by the whole community. --Plato

Believe you can and you're halfway there. --Theodore Roosevelt

Everything Should Be Made as Simple as Possible, But Not Simpler --Albert Einstein

The significant problems we face cannot be solved at the same level of thinking we were at when we created them. --Albert Einstein

1 apple is not exactly 1/8 of 8 apples. Because there are no absolutely identical apples. --Giordy
Post #1418571
Posted Monday, February 11, 2013 11:59 AM


SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Yesterday @ 6:09 AM
Points: 179, Visits: 1,091
Sorry for any confusion... I believe there are a few levels of "ownership" (http://www.sqlservercentral.com/articles/SQL+Jobs/68764/) per my understanding?

1) The account that is configured to run SQL Server Agent service.
2) The account that has "ownership" of the job (which is what I was referring to previously):
SELECT j.[name] AS 'JobName',
Enabled = CASE WHEN j.Enabled = 0 THEN 'No'
ELSE 'Yes'
END,
l.[name] AS 'OwnerName'
FROM MSDB.dbo.sysjobs j
INNER JOIN Master.dbo.syslogins l
ON j.owner_sid = l.sid
ORDER BY j.[name]
GO
3) The Step "run as" (i.e., proxy account).

The "job owner" (listed from the query above) is an account that is in the sysadmin fixed server role, so I believe the step should be executed under the account used by the SQL Server Agent service (NT AUTHORITY\SYSTEM in our case), as are all of the jobs on this server. We use a specific account for all of the "job owners".... we try to not do anything using the "sa" account (I could not tell you what the sa pwd is... it is locked away in a drawer).

The job step has the "run as" left blank (i.e., the "Proxy account").

Thanks!



Argue your limitations and sure enough they will be yours (Richard Bach, Illusions)
Post #1418591
Posted Monday, February 11, 2013 12:31 PM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 1:24 PM
Points: 6,826, Visits: 11,950
DB_Newbie2007 (2/11/2013)
Sorry for any confusion... I believe there are a few levels of "ownership" (http://www.sqlservercentral.com/articles/SQL+Jobs/68764/) per my understanding?

1) The account that is configured to run SQL Server Agent service.
2) The account that has "ownership" of the job (which is what I was referring to previously):
SELECT j.[name] AS 'JobName',
Enabled = CASE WHEN j.Enabled = 0 THEN 'No'
ELSE 'Yes'
END,
l.[name] AS 'OwnerName'
FROM MSDB.dbo.sysjobs j
INNER JOIN Master.dbo.syslogins l
ON j.owner_sid = l.sid
ORDER BY j.[name]
GO
3) The Step "run as" (i.e., proxy account).

The "job owner" (listed from the query above) is an account that is in the sysadmin fixed server role, so I believe the step should be executed under the account used by the SQL Server Agent service (NT AUTHORITY\SYSTEM in our case), as are all of the jobs on this server. We use a specific account for all of the "job owners".... we try to not do anything using the "sa" account (I could not tell you what the sa pwd is... it is locked away in a drawer).

The job step has the "run as" left blank (i.e., the "Proxy account").

Thanks!

You can still allow jobs to be owned by sa even if the Login is disabled or the password is unknown. In fact it's actually a pretty common thing for people to do by default. If done this way the job always runs in the context of the SQL Server Agent service account even if proxies for specific steps are defined.


__________________________________________________________________________________________________
There are no special teachers of virtue, because virtue is taught by the whole community. --Plato

Believe you can and you're halfway there. --Theodore Roosevelt

Everything Should Be Made as Simple as Possible, But Not Simpler --Albert Einstein

The significant problems we face cannot be solved at the same level of thinking we were at when we created them. --Albert Einstein

1 apple is not exactly 1/8 of 8 apples. Because there are no absolutely identical apples. --Giordy
Post #1418603
Posted Thursday, February 14, 2013 3:16 PM


SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Thursday, June 13, 2013 2:02 PM
Points: 198, Visits: 656
Could it be there was a momentary loss of connectivity to the domain controller and the credentials passed could not be verified? I don't recall if I've encountered this particular error or not, probably.
Post #1420323
« Prev Topic | Next Topic »

Add to briefcase 12»»

Permissions Expand / Collapse