Link to home
Start Free TrialLog in
Avatar of PROJHOPE
PROJHOPE

asked on

Login failed for user 'NT AUTHORITY\SYSTEM' in SQL logs

Receiving this in the SQL log files for over two weeks now..unsure where the problem lies.

Date            10/31/2007 3:20:45 PM
Log            SQL Server (Current - 10/31/2007 3:23:00 PM)

Source            Logon

Message
Error: 18456, Severity: 14, State: 11.

Date            10/31/2007 3:20:45 PM
Log            SQL Server (Current - 10/31/2007 3:23:00 PM)

Source            Logon

Message
Login failed for user 'NT AUTHORITY\SYSTEM'. [CLIENT: [ip address]]

I did a SQL profiler trace on this and found the Application name to be Microsoft Windows Script Host.  

Unsure how to resolve this and what the Windows Script Host is doing
Avatar of valicon
valicon
Flag of United States of America image

State 11 means that the access was denied to the server. You may want to see this resource:

http://blogs.msdn.com/sql_protocols/archive/2006/02/21/536201.aspx
Avatar of PROJHOPE
PROJHOPE

ASKER

Thanks I guess I need to know how I can trace more information as to where this application for denied access is coming from.

NT AUTHORITY\SYSTEM is not on this server so something outside of it is trying to gain access and I cannot track enough to see the source of this login...

ASKER CERTIFIED SOLUTION
Avatar of Yveau
Yveau
Flag of Netherlands image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Yveau,

Sorry yes our network team added MOM to our servers.  We normally do not have NT AUTHORITY\SYSTEM or even BUILTIN\Administrators as a login to our SQL servers.

To your knowledge does MOM need to use the \SYSTEM account to check on SQL or can we switch this to our designed Domain account used for SQL services?

I did not had the NT AUTHORITY\SYSTEM account on my 2005 SQL Servers. But for MOM I added them. The MOM SQL Server management package (or whatever it is called) uses that account to check the system tables for all kind of things like failed jobs, etc.

I don't know if you can change the account that MOM uses ... I got a deviation from the security team to re-enable that account again ... They did not see any possible security issue because it is a system account ... and they are the experts o this matter ...

Hope this helps ...
It does one last qustion...what Roles/rights did you give NT AUTHORITY\SYSTEM on SQL?  I don't want to give sysadmin I want to give the bear minimum needed for MOM to reduce security risk.
... shame on me ! We restored the original settings for the account ... yep ... sysadmin :-\
If I could I would play around with it and would start with read access to the master, msdb database, and access to the tempdb for some worktabels maybe ... won't hurt. I'm pretty sure it gets all it's info from the system databases.

If you plan on experimenting with the permissions for that account, can you fill me in on the results ? I'm very curious ...

Hope this helps ...
Yveau,

In my quick findings I found that simply granting NT AUTHORITY/SYSTEM as a login to the SQL server, with only public permissions, default database to 'master' elminates all the failed login errors.

I can live with this since /SYSTEM doesn't have full rights to SQL service

I did find the MOM agent accounts but unsure how to change this (need to consult with another team) long term we may change it to our default SQL domain account
It was to be expected that the errors would be out of the log when you granted the permission. Still strange that no one is complaining about an app that is not working ...

Glad I could be of any help and thanks for the feedback and grade !