Login failed for user NT AUTHORITY\NETWORK SERVICE

Hi All,
I've done some searching around but can't find an answer to this problem.
I've recently noticed an error in the event logs relating to the Network
Service account trying to connect to my SQL 2005 server. The logs give me
the following information :-
12/06/2007 23:30:01,Logon,Unknown,Login failed for user 'NT
AUTHORITY\NETWORK SERVICE'. [CLIENT: 10.0.0.4]
12/06/2007 23:30:01,Logon,Unknown,Error: 18456<c/> Severity: 14<c/> State: 1
6.
This is all the info I have to go on. Can anyone provide me with some
assistance with trying to troubleshoot?Well, it seems that some process working in Network Service user context is
trying to connect your instance and Network Service has no permission to
connect the target database in SQL Server. Run SQL Server Profiler and catch
failed login attempts (catch Audit Login Failed event with ApplicationName
and DatabaseName columns selected to trace).
Regards
Pawel Potasinski
[http://www.potasinski.pl]
Uytkownik "Matt" <Matt@.discussions.microsoft.com> napisa w wiadomoci
news:AB02D9C1-DF84-4A43-BCA5-4A84B8323525@.microsoft.com...
> Hi All,
> I've done some searching around but can't find an answer to this problem.
> I've recently noticed an error in the event logs relating to the Network
> Service account trying to connect to my SQL 2005 server. The logs give me
> the following information :-
> 12/06/2007 23:30:01,Logon,Unknown,Login failed for user 'NT
> AUTHORITY\NETWORK SERVICE'. [CLIENT: 10.0.0.4]
> 12/06/2007 23:30:01,Logon,Unknown,Error: 18456<c/> Severity: 14<c/> State:
> 16.
> This is all the info I have to go on. Can anyone provide me with some
> assistance with trying to troubleshoot?|||Thanks Pawel,
The only way I am able to force the netork login failure is by restarting
the MSSQL server process. Of course, when I do this with the Profiler
running, I end up with a Trace error in the log as soon as the server goes
online and the logging stops. Any idea how I can make the Profiler keep
running even when the server gets restarted? Or is there a way that I can
make the profiler start when the server starts before loading anything else?
Matt
"Pawel Potasinski" wrote:

> Well, it seems that some process working in Network Service user context i
s
> trying to connect your instance and Network Service has no permission to
> connect the target database in SQL Server. Run SQL Server Profiler and cat
ch
> failed login attempts (catch Audit Login Failed event with ApplicationName
> and DatabaseName columns selected to trace).
> --
> Regards
> Pawel Potasinski
> [http://www.potasinski.pl]
>
> U?ytkownik "Matt" <Matt@.discussions.microsoft.com> napisa3 w wiadomo?ci
> news:AB02D9C1-DF84-4A43-BCA5-4A84B8323525@.microsoft.com...
>
>|||I ment to say "I end up with a Trace error in the log as soon as the server
goes
OFFLINE and the logging stops".
Just to be clear, I see the Failed Audit login message in the SQL log only
when I start the start the server. It doesnn't continuely happen, therefore
the only time I can try and trace the cause of the issue is as the server
starts up
"Matt" wrote:
[vbcol=seagreen]
> Thanks Pawel,
> The only way I am able to force the netork login failure is by restarting
> the MSSQL server process. Of course, when I do this with the Profiler
> running, I end up with a Trace error in the log as soon as the server goes
> online and the logging stops. Any idea how I can make the Profiler keep
> running even when the server gets restarted? Or is there a way that I can
> make the profiler start when the server starts before loading anything els
e?
> Matt
> "Pawel Potasinski" wrote:
>|||OK, with a bit of luck, patience and timing, I managed to get a trace of the
Audit Login Failed notice. It looks like our CRM application is having a ba
d
day and isn't able to logon to something. However, even though I enabled al
l
columns in the Profiler and made sure DatabaseName column was selected, I
only get columns ApplicationName - TextData listed. The all-important info
aon what table the service is trying to access is still missing.
Any thoughts?
"Matt" wrote:
[vbcol=seagreen]
> I ment to say "I end up with a Trace error in the log as soon as the serve
r
> goes
> OFFLINE and the logging stops".
> Just to be clear, I see the Failed Audit login message in the SQL log only
> when I start the start the server. It doesnn't continuely happen, therefo
re
> the only time I can try and trace the cause of the issue is as the server
> starts up
> "Matt" wrote:
>|||Matt (Matt@.discussions.microsoft.com) writes:
> OK, with a bit of luck, patience and timing, I managed to get a trace of
> the Audit Login Failed notice. It looks like our CRM application is
> having a bad day and isn't able to logon to something. However, even
> though I enabled all columns in the Profiler and made sure DatabaseName
> column was selected, I only get columns ApplicationName - TextData
> listed. The all-important info aon what table the service is trying to
> access is still missing.
It's seems difficult to find out which table the CRM app is trying to
access, when it does not comes as far as connecting...
Then again, if you get a single login failure when you start SQL Server,
and the CRM application does not produce an error, maybe this is not
really an issue to lose sleep over?
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx|||Matt,
Is this a standalone server or a cluster? have you recently upgraded to W2K3
SP2? We now see this when we patch or failover our clustered SQL2005 server.
Chris
"Matt" <Matt@.discussions.microsoft.com> wrote in message
news:8AEE2C89-5A8C-4005-A241-862CAE01CE38@.microsoft.com...[vbcol=seagreen]
>I ment to say "I end up with a Trace error in the log as soon as the server
> goes
> OFFLINE and the logging stops".
> Just to be clear, I see the Failed Audit login message in the SQL log only
> when I start the start the server. It doesnn't continuely happen,
> therefore
> the only time I can try and trace the cause of the issue is as the server
> starts up
> "Matt" wrote:
>