What is this?

This knowledgebase contains questions and answers about PRTG Network Monitor and network monitoring in general.

Learn more

PRTG Network Monitor

Intuitive to Use. Easy to manage.
More than 500,000 users rely on Paessler PRTG every day. Find out how you can reduce cost, increase QoS and ease planning, as well.

Free Download

Top Tags


View all Tags

Monitor failed logins via Event Viewer

Votes:

0

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

event-log eventlog windows-event-log

Created on Mar 15, 2013 2:05:28 PM



Best Answer

Accepted Answer

Votes:

3

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”

Created on Mar 18, 2013 10:13:34 PM



7 Replies

Votes:

0

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.

Created on Mar 18, 2013 3:06:06 PM by Patrick Hutter [Paessler Support] (7,225) ●3 ●3



Accepted Answer

Votes:

3

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”

Created on Mar 18, 2013 10:13:34 PM



Votes:

0

Looks about right. And thanks for sharing!

Created on Mar 20, 2013 1:19:49 PM by Patrick Hutter [Paessler Support] (7,225) ●3 ●3



Votes:

0

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.

Created on Apr 21, 2016 2:52:48 PM



Votes:

0

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).

Created on Apr 22, 2016 2:37:03 PM



Votes:

0

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

Created on Apr 25, 2016 8:25:23 AM



Votes:

0

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/

Created on May 2, 2016 6:28:40 AM




Disclaimer: The information in the Paessler Knowledge Base comes without warranty of any kind. Use at your own risk. Before applying any instructions please exercise proper system administrator housekeeping. You must make sure that a proper backup of all your data is available.