No User login information found in UDT

10/12/2018 6:53 PM

12/26/2022 12:52 PM

User login information is not displayed in User Device Tracker (UDT).

User Device Tracker

The following are the possible causes for this issue:

• Auditing of user logins is not defined and UDT is looking for event IDs 4768 and 4769 from Windows 2008, 2012, 2016, and/or 2019 AD servers.
• Auditing of user logins is not defined and UDT is looking for event IDs 768 and 769 from Windows 2003 AD.
• UDT is not able to poll data as it is not connected to the event log in the domain controller.
• Windows Firewall could be stopping RPC and WMI connection from the Orion server on Domain Controllers.
• IPv6 to IPv4 translation fails.

Refer to the following resolution information to resolve this issue.

Auditing of user logins is not defined 

When attempting to use Basic Audit Policy, the selections within the policy (Success, Failure) are being saved (or checked), but they revert (to unchecked) after 15 minutes. You need to define the settings under Advanced Audit Policy in order to save the selections. To get the event IDs 4768 and 4769 working using Group Policy on Windows 2012 R2, Windows 2016, and Windows 2019 servers, the domain controllers need to have the settings defined under Advanced Audit Policy Configuration instead of under Basic Audit Policy.
 

Use the following settings under Advanced Audit Policy Configuration:

Event 4768

1. Go to Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies > Account Logon > Audit Kerberos Authentication Service.
2. Define the policy and choose both Success and Failure.

Event 4769

1. Go to Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies > Account Logon > Audit Kerberos Service Ticket Operations.
2. Define the policy and choose both Success and Failure.

Advanced Audit Policy Configuration overrides the settings in Basic Audit Policy. This is true unless the administrator has the following policy defined:

Computer Configuration > Policies > Security Settings > Local Policies > Security Options > Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings.

Set to Disable to allow both policies to apply.

The Default Domain Controllers Policy was also defining the settings of the following items:

Events 4768/4769 – Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Audit Policy > Audit account logon events.

It was defined, however neither option (Success, Failure) was checked.

Undefine this policy in the Default Domain Controllers Policy since it is replaced with another Group Policy Object that utilized the Advanced Auditing Policy.

UDT is not able to poll the data

The following information is described in the Administrator Guide.
 

Set up polling of user data across domains

Enabling UDT to poll user data - essentially, by retrieving event log data - on an AD domain controller outside the local domain of the UDT server requires setup both in UDT and the AD domain controller. UDT supports the following methods for getting event log data from another domain:

• Eventing 6

  This is the preferred method and depends on the AD domain controller running Windows 2008 R2.

• WMI

  This method is supported across Windows platforms.

UDT collects user information through a scheduled job (REL). Two settings— UDT.GetUserInfoThroughWMIForEventing6 (disabled by default), UDT.GetUserInfoThroughWMI (enabled by default and should not be changed) — determine how UDT collects the information.

Define credentials for polling across domains

Keep in mind these requirements when you set up your credentials for accessing an AD domain controller outside the local UDT server domain.

• The UDT user account must be part of the target domain.
• The UDT user account must either be a member of the Administrators group on the target domain controller or a limited account with privileges to access the remote security event log and directory service on the remote domain controller. If UDT is using a limited account, the account must be a member of these groups:
  • Domain Users
  • Distributed COM Users
  • Event Log Readers
• The UDT account must be able to access certain WMI namespaces. For more information, see the section below

Setting WMI Namespace Security

You configure access to WMI namespaces through these steps on the target AD domain controller.

1. Open Administrative Tools (Control Panel > Administrative Tools).
2. Double-click Computer Management.
3. Expand Services and Applications and double-click WMI Control.
4. Right-click WMI Control and select Properties.
5. On the Security tab, expand the tree under Root.
6. Select CIMv2 and then click Security.
7. Click Advanced.
8. Click Add.
9. Enter the account name in the text box and click OK.
10. Confirm that Apply to is set to This namespace and subnamespaces.
11. Select the Allow check boxes for Execute Methods, Enable Account, and Remote Enable.
12. Click OK.
13. Select the directory and click Security.
14. Repeat steps 7-12 if you need to set up additional namespaces.

Note: The Custom Security Descriptor (CustomSD) in Windows 2003 Server may obstruct retrieval of user data even though the connection is open.

After you have the desired account set up for WMI access on the AD domain controller, you can add the account credentials to UDT. To do that, see Add an AD Domain Controller.

Windows Firewall 

Windows firewall could stop RPC connection and still give a false positive about WMI access and polling OK/Test DC successful.

Troubleshoot Firewall steps

1. Log in to the Orion server. 
2. Open Event viewer.
3. Click Connect to Another Computer.

   

4. Enter Address of Domain Controller (windows networking), and select Connect as another user.

   

5. Click Set User and enter credentials used to poll Domain Controllers.
6. Expand Windows Logs. 
7. Check to see if Security logs show 4768, 4769 eventing 5, eventing 6

• If an Access denied error is displayed or the RPC server is unavailable, check the firewall.

  
  
  Disclaimer: Please note, any content posted herein is provided as a suggestion or recommendation to you for your internal use. This is not part of the SolarWinds software or documentation that you purchased from SolarWinds, and the information set forth herein may come from third parties. Your organization should internally review and assess to what extent, if any, such custom scripts or recommendations will be incorporated into your environment.  You elect to use third party content at your own risk, and you will be solely responsible for the incorporation of the same, if any.