I see I can monitor Event Viewer, but can you set thresholds for certain events? I'd like to monitor the Security event log for failed logins, but would only like to alarm at a certain threshold (say, 10 per hour). Is this possible?

Thanks, Matt

Article Comments

I'm afraid adding a threshold for the number of events necessary to trigger a notification is not yet possible. That said, we are developing new log sensors and there is a chance such an option will be available, although I cannot say so with certainty yet. Please bear with us.


Mar, 2013 - Permalink

I believe I was able to successfully complete this process to create a sensor capable of reporting on a threshold of failed login attempts. Please let me know if there are errors in the configuration, but testing has shown this to work. It won't maintain a "Down" state, but so long as notifications are configured you should at least be aware of the situation:

  1. Select the device in PRTG you want to monitor for failed login attempts. This will generally be your Active Directory server(s).
  2. Click “Add Sensor” at the bottom of the sensor list
  3. In the ‘Search directly’ box, enter the following: event
  4. Click “Event Log (Windows API)
  5. For “Log File”, select “Security”
  6. For “Filter by ID”, select “On”
  7. For “Match Values (Event ID)”, enter one of the following:
    • To monitor failed login events directly to the server use: 529
    • To monitor failed domain login events use: 675
  8. Uncheck “Inherit Scanning Interval”
  9. For “Scanning Interval”, select “1 hour”
  10. Click “Continue”
  11. Right-click the “Win API Eventlog” sensor, select “Edit”, and click “Settings”
  12. For “Sensor Name”, enter “Failed Login Attempts”
    • It is unknown at this point why PRTG does not let you name this sensor at the time of creation
  13. Click “Save”
  14. Click the “Channels” tab
  15. For “Channel”, click “New Records (ID x)”
  16. For “Limits”, select “Enable Limits”
  17. For “Upper Error Limit (#/s), enter “0.005”
    • I believe this number should equate to approximately 20 failed attempts per hour. Adjust this number according to the environment.
  18. For “Error Limit Message”, enter “Significant Failed Logins”
  19. Click “Save”
  20. Click the “Notifications” tab
  21. Click “Add State Trigger”
  22. For “When sensor is Down for at least”, change “60” to “1” for ‘seconds’
  23. For “When sensor is Down for at least 1 seconds perform”, change “no notification” to the appropriate notification group
  24. Click “Save”

Mar, 2013 - Permalink

Looks about right. And thanks for sharing!


Mar, 2013 - Permalink

Hi all

I've followed the above instructions and the sensor worked for a bit. But when I test a few failed log in attempts, I get the below error message. Any ideas?

Could not retrieve params for eventlog entry (An account was successfully logged on. Subject: Security ID:%1 Account Name:%2 Account Domain:%3 Logon ID:%4 Logon Type:%9 Impersonation Level:%21 New Logon: Security ID:%5 Account Name:%6 Account Domain:%7 Logon ID:%8 Logon GUID:%13 Process Information: Process ID:%17 Process Name:%18 Network Information: Workstation Name:%12 Source Network Address:%19 Source Port:%20 Detailed Authentication Information: Logon Process:%10 Authentication Package:%11 Transited Services:%14 Package Name (NTLM only):%15 Key Length:%16 This event is generated when a logon session is created. It is generated on the computer that was accessed. The subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe. The logon type field indicates the kind of logon that occurred. The most common types are 2 (interactive) and 3 (network). The New Logon fields indicate the account for whom the new logon was created, i.e. the account that was logged on. The network fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases. The impersonation level field indicates the extent to which a process in the logon session can impersonate. The authentication information fields provide detailed information about this specific logon request. - Logon GUID is a unique identifier that can be used to correlate this event with a KDC event. - Transited services indicate which intermediate services have participated in this logon request. - Package name indicates which sub-protocol was used among the NTLM protocols. - Key length indicates the length of the generated session key. This will be 0 if no session key was requested. ). Eventlog of target computer might not be compatible.


Apr, 2016 - Permalink

Unfortunately, we disabled our sensor a couple of years ago due to the high volume of false positives (not PRTG's fault - Windows just logged a high volume of things we couldn't filter).


Apr, 2016 - Permalink

That's a shame, we've got a public facing server that we really need to monitor failed log in attempts on.


Apr, 2016 - Permalink

Hi Simon, You can enable auditing to track successful logon and failed logon attempts made by users. Please checkout this article which summarizes the steps to enable auditing and track such activities : http://www.lepide.com/blog/audit-successful-logon-logoff-and-failed-logons-in-activedirectory/


May, 2016 - Permalink