You can use JumpCloud Agent, Directory Insights, and Windows Event Viewer logs to help you find out why a user has been locked out of their device.
Completing a Quick Review of the Logs
Timestamp Considerations:
- The jcagent.log is reported in the local device time.
- Directory Insights is reported in UTC but converted to local time in the console.
- Windows logs will be recorded in local device time but if opened on another device during viewing will be converted to the time of the device being used for review.
Determine if an End User was Locked Out of their Local Device
The fastest way to determine if a user has been locked out of their local device due to failed logins on that local device is to review the JumpCloud agent log file(s) for a “lock out” action. This “lock out” action will also result in the user being locked out from the JumpCloud User Portal.
Search for: Locking user within the jcagent.log*
2021/01/26 17:17:37 [8506] [INFO] Locking user acaw9. User reached maximum failed password attempts (3)
2021/01/26 17:18:18 [8506] [INFO] Locking user acaw9. User reached maximum failed password attempts (3)
Log Analysis Examples
Search for: failed to login from within the jcagent.log*
2021/01/26 17:16:23 [8506] [INFO] User acaw9 failed to login from <nil>, process name: , caused by password change failure: false
2021/01/26 17:17:28 [8506] [INFO] User acaw9 failed to login from <nil>, process name: , caused by password change failure: false
2021/01/26 17:17:32 [8506] [INFO] User acaw9 failed to login from <nil>, process name: , caused by password change failure: false
2021/01/26 17:17:37 [8506] [INFO] User acaw9 failed to login from <nil>, process name: , caused by password change failure: false
Search for: Processing disabling users within the jcagent.log*
2021/01/26 17:14:02 [8506] [INFO] Processing disabling users, disableUsers=map[]
2021/01/26 17:18:17 [8506] [INFO] Processing disabling users, disableUsers=map[acaw9:0xc00054a5a0]
Search for: Locking user within the jcagent.log*
2021/01/26 17:17:37 [8506] [INFO] Locking user acaw9. User reached maximum failed password attempts (3)
2021/01/26 17:18:18 [8506] [INFO] Locking user acaw9. User reached maximum failed password attempts (3)
Search for: failed to login from within the jcagent.log*
2021/01/26 07:58:48 [8506] [INFO] User acaw9 failed to login from <nil>, process name: , caused by password change failure: false
2021/01/26 07:59:06 [8506] [INFO] User acaw9 failed to login from <nil>, process name: , caused by password change failure: false
Search for: Processing disabling users within the jcagent.log*
2021/01/26 07:48:36 [8506] [INFO] Processing disabling users, disableUsers=map[]
2021/01/26 07:59:31 [8506] [INFO] Processing disabling users, disableUsers=map[acaw9:0xc00021c900]
2021/01/26 08:34:09 [8506] [INFO] Processing disabling users, disableUsers=map[]
Search for: Locking user within the jcagent.log*
-- <no entries returned from log>
Analysis & Next Steps
In the second scenario, the end user only fails login 2 times, but is placed in the disabled user state and there is no lockout action reported in the logs. This indicates that either:
- The end user may have already attempted and failed to log into the User Console, or has proceeded to attempt to log into the User Console and failed.
- The end user may have also failed to log into another bound device, so the “lock out” action was triggered from another device and Directory Insights data review will be required.
To complete the analysis, Directory Insights data should be reviewed in the console for the end user that is being investigated and All devices should be selected as noted below.
Due to failed login reporting and processing, it may be necessary to expand the search for failed login attempts well before the lockout or disable actions noted in the JumpCloud agent log. The final failed login attempt is often noted after the “Lock out” event is reported in Directory Insights as the platform will trigger the lockout on the local device before the log for the failed login attempt can be pushed to Directory Insights per processing overhead.
Performing an In-depth Log Review
While the previous process is useful for quickly determining if a user has been locked out of their local device, further review can be required to determine the underlying causes.
To perform an in-depth log review, you can use information gathered from the following resources:
Review the JumpCloud Agent Log
To review the JumpCloud Agent Log, search the agent log for a failed login message similar to the following:
2019/04/30 08:41:04 [4184] [INFO] User USERNAME failed to login from <nil>, process name: -, time: 2019-04-30T15:41:03.636975000Z
A message of this type will generally indicate a Windows service is causing the issue. This entry will be helpful to us when cross-referenced with Windows Event logging to determine the root cause of the lockout.
<nil> is where the JumpCloud agent normally reports the IP address if it were an external connection. If it does indeed report as <nil>, it was a local connection on the device. <nil> most commonly appears in the log, however, localhost or 127.0.0.1 (local connection being a local process) may also be logged
Review the Windows Logs
To review Windows logs, you must first load your saved Event Log into the Windows Event Log Viewer.
When importing and reviewing Windows Event logs that originated in another timezone, logs are commonly converted to the local device timezone.
To load your saved Event Log into the Windows Event Log Viewer:
- Right-Click on Windows Log.
- Select Open Saved Log.
- Navigate to the location where the log is saved.
- Open the log.
- When the log is loaded:
- From the right-hand Actions pane, click Filter Current Log…
- On the Filter Current Log dialog, locate the field with a value <All Event IDs>. Click into this field to filter by Event IDs.
- Click the OK button at the bottom of the Filter Current Log dialog. Note: that depending on the size of the log this could take some time.
- Examine the Logon Type.
- Logon Type: This is a valuable piece of information because it tells you how the user just logged on. See this article for a table of logon type codes.The Logon Type field indicates the kind of logon that was requested. The most common types are:
- Type 2 - an interactive logon.
- Type 3 - a network logon.
- Logon Type: This is a valuable piece of information because it tells you how the user just logged on. See this article for a table of logon type codes.The Logon Type field indicates the kind of logon that was requested. The most common types are:
- If this appears to be a third-party application, you will want to investigate that specific application for stored credentials.
See cross-referencing logs section for the next steps to help you determine what process may be causing the lockout
Cross-referencing Logs
In some cases, you might need to cross reference the JumpCloud Agent logs and the Windows event Logs to find out what is causing a user lock on a Windows device.
The following is an example of how to do this with a 5379 event.
To cross-reference logs:
- Locate a failed login entry in the JumpCloud agent log. Note the timestamp and have Directory Insight information available.
- From the Windows Event Log, filter for your selected event ID.
- It may be useful to add an additional filter for date and time so the filtered results correlate with the selected incident from the JumpCloud agent log and the number of entries to be review are reduced
- If there is a correlating time between the JumpCloud log and the Windows Event Log, open that specific event:
Opening the event will display detailed information. In this example, we can see the highlighted event’s source and the date and time it occurred. The General tab shows basic information, while the Details tab shows raw event data.
- The 5379 event occurs when a user performs a read operation on stored credentials in Windows Credential Manager (WCM). Since the successful read from WCM correlates with a failed login in JumpCloud it’s very likely that there’s an issue with the credentials cached by WCM.
- The next step would be to open WCM and make a note of which applications have cached credentials. If there are multiple credentials, it’s necessary to utilize the process of elimination to determine which applications in WCM are causing the lockout.
- Examining other events will follow a similar process of correlating timestamps and user activity with Windows Event log entries to determine the source of the issue.
When the problematic process is svchost.exe, be aware that this is a generic host process name for services that run from dynamic-link libraries. As a result, the source of the bad login error is not immediately recognizable. Troubleshooting svchost.exe presents a unique challenge because of this. The investigation involves determining what’s running under svchost during a user’s session, then confirming against the JumpCloud agent log or Directory Insights for processes with related timing.
To generate a list of all svchost.exe processes:
On any version of Windows, you can use the command line to generate a list of all the svchost.exe processes along with the service that is running inside each.
You need to run this command in the context of the user affected by lockouts, so make sure they’re logged in to the device before elevating to admin and collecting the svchost information.
- Open a command prompt by clicking on Start and typing in cmd.
- Ensure you select Run as Administrator, enter admin credentials as prompted
- At the command prompt enter: tasklist /svc | find "svchost.exe"
- This generates a list of all running processes, then passes that list to the find command and filter to only show the svchost.exe processes.
- To output this to textfile: tasklist /svc | find "svchost.exe" > c:\tasklist.txt
Persistent account lockout incidents require prompt investigation, can be frustrating, and are often difficult to isolate. This guide is intended to assist administrators in understanding common lockout causes, determining the reason behind the lockout, and preventing future incidents. We hope it has been useful. If you continue to experience issues or need further assistance, or would like to share feedback and comments, submit a support ticket from the Admin Portal. See Contact JumpCloud Support for instructions.