Why source IP addresses aren’t always resolved by Windowsserver in eventid 4625

Syspeace monitors failed logins attempts on Windows systems

Sometimes though, the event (Eventid 4625 or eventid 529 and a few other security events we monitor) doesn’t actually contain the source IP address thus leaving Syspeace with nothing to block.
If there’s no IP address to block, it can’t be put into to the Windows Frewall Syspeace rules and the bruteforce attack can continue.

This essentially happens when you switch from RDP layer security to using a certificate.

An article on Stackoverflow might be pointing to a solution though

http://stackoverflow.com/questions/1734635/event-logging-ipaddress-does-not-always-resolve

Essentially, the suggestion is to change this setting in the Local Security Policy of the server running Syspeace.

Computer ConfigurationWindows SettingsSecurity SettingsSecurity 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

Here’s a warning though!

If you’re using the RD WEB also to publish Remote Resources.
For some reason , your MAC OS clients will stop recieving Remote Resources since it seems to run on NTLM version 1 (and I would guess Android and XP too )
Also scanners may stop working locally if they need to write files to a newtorks share
I tried a lab with this and when seting the – Network security: Restrict NTLM: Incoming NTLM traffic — Deny all accounts , the remote resources can’t be refreshed.

There are a few warnings when changing this setting and you should investigate if there are applications or services in your server environment that are dependent on LM or NTLM (v1).

I’ve changed the setting on a number of servers and haven’t seen anything stop working but still you should investigate before changing.