I'd like to write a service that pulls Event Viewer records, specifically from the Security log. Of particular interest to me are things like event id 4625 (audit fail) messages. Ideally I'd like to store the IP of clients that cause audit fails more than n times in m seconds for some amount of time.

Sounds easy enough, so I quickly whipped up a .NET service to do just this. However, when I pull these audit failures, the "Source Network Address" value is always equal to "-". I would like to know how Windows can get all the way through a logon, end in failure and not know the peer's IP address.

Also worth noting is the few times that the IP address does get logged the log entry does in fact contains lots of other useful information (like the Process that generated it, the failure reason, transmitted services, etc).

Can someone please tell me why the Security Log doesn't know the IP address of people trying to log in and failing?

  • 1
    Might be helpful if you give us an OS version... and/or what level of logging you're doing on Security events, as you may need to increase your logging level to see what you're asking for. Jun 18 '12 at 18:58
  • Server 2008 R2 Standard. I think the logging level would only affect which events were logged, i.e. whether audit failure gets logged. My problem is the events inconsistently have and don't have the IP address of the client trying to connect.
    – kmarks2
    Jun 18 '12 at 19:09
  • 1
    have you enabled auditing?
    – tony roth
    Jun 18 '12 at 19:45
  • 1
    RdpGuard docs may help. Installing the software is not required. rdpguard.com/windows-server-how-to-catch-failed-logons.aspx
    – slat
    Jul 13 '15 at 12:47
  • See my answer to this question - serverfault.com/questions/379092/…
    – wqw
    Oct 17 '15 at 12:57

Can someone please tell me why the Security Log doesn't know the IP address of people trying to log in and failing?

Here is the cause for something like Remote Desktop.


There is no option in Windows to enable or disable the logging of IP address, at least not to my knowledge.

For Remote Desktop I discovered that going into "Remote Desktop Session Host Configuration" and changing the RDP-TCP connection to have the security layer of "RDP Security Layer" instead of "Negotiate" or "SSL (TLS 1.0)" brought back the IP addresses.

Whether you really want to do this is another question for you, "If you select RDP Security Layer, you cannot use Network Level Authentication."


IP addresses not being present in Windows logs isn't all that uncommon, especially if (for example), the failures are coming from a service, like IIS and you only have "basic" level logging for IIS... or SMTP and you have "basic" level logging for SMTP, etc.

Not the way I'd set my logging defaults if Windows was my OS, but Gates never asked for my input. I'd suggest adjusting your logging levels (and expanding the max log file sizes) and seeing if that doesn't resolve the problem. It's not that Windows doesn't know the source IP, but that the logging level is set such that it's not recording that information. (And, for whatever it’s worth, setting the logging level to something useful is one of the first steps I undertake on a new Windows server or server template.)


Similar to what HopelessN00b said, the most likely reason why you don't see this information is because the audit failure are generated by a service on behalf of the user. So the user isn't authenticating directly (as he or she would when logging into Windows for example), but through some other service like IIS, SQL, etc. You would then have to parse the logs of those services to find out the IP address.

Now, if the authentication is directly through Windows, then you should usually see the IP address, or if it's coming from the local machine.

There is no option in Windows to enable or disable the logging of IP address, at least not to my knowledge. So, there is no real logging "level". You either enable a logging category, or not. The only thing you can configure is whether to log audit failures and/or audit success events (maybe see this article: http://blogs.technet.com/b/askds/archive/2007/10/19/introducing-auditing-changes-in-windows-2008.aspx).

BTW, there are lots of free products out there which monitor the event logs (e.g. we develop EventSentry), it's usually much easier to just use that rather than write your own (unless you do it as an exercise of course :-) ).

Hope this helps.


Much probably originated by NTLM inbound traffic. I could not find a way of logging the ip but you can block it, here you can find why is not logged and steps on how to disable inbound NTLM traffic https://serverfault.com/a/729662/200398


You can log from the firewall. If it is a brute force attack from a single IP this will be easily matched. The firewall could be upstream. How you then automate the detection and blocking of the connection is up to you. They will never run out of endpoints.

You might also consider a script that door knocks a hole in your firewall, this is routinely done nowadays on the cloud with NSG (Network Security Group) manipulation in the simplest extremes. Trampolining through jump or bastion servers is also popular.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.