Not receiving user data from domain controllers and validating active directory in UDT

The following are possible causes:

• The event code in the AD DC is incorrect.
• Event codes are not validated.
• The Event log was not properly generated after the Last Read Log Index which results to a missing user date.
• The Event code is correct (4768, 4769 for Kerberos) but it shows Audit Failures in Event Logs as shown below. UDT only reads off Audit Success and not Audit Failure.

  
  
  

2008 Domain Controllers 

1. Notes Use the Group Policy Management Console  to review and edit the default policy in the domain controller(s). Verify that the Audit account logon events policy is enabled.
   a. Go to Control Panel > Administrative Tools > Group Policy Management.
   b. Navigate to the Default Domain Controllers Policy node, as shown below:
   

c. Right click Default Domain Controllers Policy and press the Edit menu.
d. Navigate to the Audit Policy node, as shown below:

2. Verify the non-administrator domain user is a member of the following groups:

   
   
   

   • Distributed COM Users
   • Domain Users
   • Event Log Readers
   • Remote Desktop Users (applicable only when the UDT server and the DC are on different domains)
3. Verify the non-administrator has access to the following WMI namespaces on both the Domain Controller and the Orion server. Refer to Use WMI Control to Manage Windows Management Instrumentation:
   • CIMV2
   • directory
   • RSOP
4. To ensure this, go to Control Panel > Administrative Tools > Computer Management.
5. Navigate to the WMI Control node as shown below:
   

6. Use the Group Policy Management Console to enable the following policies:
   • Audit Kerberos Authentication Service (to generate 672 or 4768 even code)
   • Audit Kerberos Service Ticket Operations (to generate 673 or 4769 event code)

• To enable NTLM authentication, execute the following query in the database server: 

  UPDATE UDT_Setting SET DefaultValue = '1', SettingValue = '1' WHERE SettingName = 'UDT.RELReturnNTLMLogons'

• By default, UDT supports Kerberos authentication scheme only.

  Authentication	Operating System	Event Code
  Kerberos	Windows 2003	672 and 673
  NTLM	Windows 2003	680
  Kerberos	Windows 2008 and later	4768 and 4769
  NTLM	Windows 2008	4776

2012 Domain Controllers 

1. Windows 2012 Run Group Policy Management Editor on the domain controller and go to the following node:
   Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Audit Policy
2. Expand the node to display a list of possible audit categories that can be configured.
3. Verify that the following are enabled:
   • Audit account logon events
   • Audit logon events
4. Verify that the Event Log on the domain controller that is being monitored by UDT is not full and new events can be added. 
   Note: In some environments, it may be necessary to configure Kerberos Authentication service:
   1. Go to Security Settings > Advanced Audit Policy Configuration > Audit Policies > Account Logon.
   2. Verify that the two items containing Kerberos are defined.
      The events should now appear in the Domain Controller's event log. It may take up to 30 minutes for the events to appear in UDT.

Windows 2012

1. Define the following settings for R2 Domain Controllers using Advanced Audit Policy Configuration instead of Basic Audit Policy:
   • Audit Kerberos Authentication Service: Define the policy and select both Success and Failure.
   • Audit Kerberos Service Ticket Operations: Define the policy and select both Success and Failure.
     Note: The Advanced Audit Policy overrides the Basic Audit Policy unless the following policy is defined:
     Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings
2. Disable the Audit account logon events in the Default Domain Controllers Policy.

For more information, refer to the following:

• All Logon/Logoff Audit Policies 
• Event 4768 
• Event 4769 
• Basic Auditing vs Advanced Auditing 

Validate the Active Directory event log in UDT 

The following validations are applied to event log entries: In some cases, this problem has been traced to the wrong event codes being generated on the domain controller(s).

1. Event logs generated within the past 30 minutes are evaluated.
2. Event logs should have an event code of 4768. The username should not end with “$,” and the status code should be 0x0.
3. Event code 4768 should have a corresponding 4769 event log and should generate within 20 seconds of the 4768 event code creation.
4. If steps 2 and 3 are met, event code 4769 will be parsed and its record will be marked as last read in the record index.
5. The next DC polling cycle will use the index of event code 4769 and retrieve the event logs having a record id greater than the last read record index.

Notes:

• If the event code is 4776, 4768, 672, or 680 with an authenticated user name is ending with “$,” the entry will be ignored.
• If the event log entry status code is not “0x0” it will be ignored.
• Event logs with status code 4768 or 672 should have respective 4769 and 673 event log entries within 20 seconds of the event code creation. If the 20-second window is not met, the event log entries will be ignored.
• The compatibility checker will look for event codes 4768 and 4769 from the last 30 minutes.
• If event code 4768 is present and the user name does not end with “$,” event code 4769 should generate within the next 20 seconds.
• IP addresses should match for event logs 4768 and 4769.
• The username for event log 4769 should match the username in the 4768 log.
• If the 4768 log username starts with “.\” it will be skipped and comparisons will happen as mentioned in the previous point.
• If the information is valid (steps 1 through 8) perform the following steps:

f. Subtract 1 from that value and place the index value into the compatibility checker.

i. Open the compatibility checker (C:\Program Files(x86)\Solarwinds\Orion\UDT\UDT compatibility cheker.exe) and click Settings from the menu in the upper-right corner.

ii. Select Remote Event Log > Last Read Log Index > Edit and paste the Event Record ID.

g. Start a new session for the AD DC Server. This reveals whether there are successful event logs for the DC.

You can see an event log record if available, after the last record index gets populated in the UDT CC.

You can also see the event log information in the UDT compatibility checker log file (C:\Program Data\Solarwinds\Logs\Orion).

If there are no event logs generated after the Last Index, you can see a message in UDT CC that there are no log entries to read.