Event Logging IPAddress does not always resolve
I am hooking the Security event log with System.Diagnostics.Eventing.Reader.EventLogWatcher class, and I am watching Event ID 4625 on a 2008 server box, for incoming failed logins (RDP, specifically).
The log capturing is working fine, and I am dumping the results into a queue for related, later processing. However, sometimes the logs captured have the IPAddress data field filled (resolved), and sometimes they do not.
I have run windump while watching the server, trying my usual RDP logins from different servers and OS flavors, and the only conclusion I can come to about this is a version difference issue, and not bad coding. Although I could be wrong, LOL.
The problem is in the event logs themselves with regard to these connections. All the failed RDP logins are logged, and are processed correctly, but some of the logs simply do not record the source IP address of the failed connection.
Does some newer flavor of mstsc somehow cause a remote event log to NOT log the source IP address? This seems to be true for any other 2008 server I run against this hooked server. Any 2003 or XP machine that I've tried so far is logged correctly.
If you need more information, let me know. Thanks SO!
EDIT
Do I need to do something crazy -- like implement sharpPcap and correlate IPs to eventlogs that way? =/. Can lsass be queried maybe (isn't it the only thing that typically writes to the Security log)?
Answer
I finally got this working. This was happening because there were two authentication methods being used for RDP connections: NTLM and User32. I changed GPO settings to kill the foreign NTLM connections.
These are the GPO settings I set that did the magic. Please note that this is a Server 2008 R2 box.
Required
Computer Configuration\Windows Settings\Security Settings\Security Options
Network security: LAN Manager authentication level -- Send NTLMv2 response only. Refuse LM & NTLM
Network security: Restrict NTLM: Audit Incoming NTLM Traffic -- Enable auditing for all accounts
Network security: Restrict NTLM: Incoming NTLM traffic -- Deny all accounts
Recommended
Do not allow for passwords to be saved -- Enabled
Prompt for credentials on the client computer -- Enabled
I changed some other security-related keys, too, but these should be the core ones. Forcing incoming network traffic away from using NTLM allows every single 4625 event to contain the IP Address of the failed computer, as they are force to use User32 logon.
Let me know if this seems totally insecure or there might be a better way to do this, but this allows proper counting and logged of failed attempts while retaining a level of encryption for the connection.