This article describes common directory services and user awareness issues and suggested solutions.
Error: Unable to Connect to the Domain Controller
This error message indicates on a connectivity failure with the domain controller (DC) mostly because of invalid credentials. This error message is usually followed by “Invalid Credentials” error message.
Verify that you entered the LDAP Authentication Connection Settings (Login DN, Base DN and password) correctly in the Cato Management Application (Configuration>Directory Services).
This error message indicates on permissions issue. The Cato Management Application notifies when it’s unable to access the DC. This error message is usually followed by the event: “DC_Connectivity_Failure” in the analytics section. The Cato Management Application generates this event (once an hour) when the connection with the DC fails.
Follow these steps to troubleshoot this issue:
- Check the username and password. Verify that you entered the correct Login DN and password. Verify that the Cato Socket sends the correct username in the connection attempt by capturing the packets (PCAP) on the LAN interface of the Socket or the DC itself.
- Check the user permissions to read the event log from domain controller settings. Follow the online help guide - windows configuration.
- If you enabled the Daily sync Directory Service Groups and Users (User Awareness), verify that you configure the Domain Controllers for Real Time Sync. Click “Show Status” and see if you get “Connection Successful” result.
- Check for events in the Event Discovery in the analytics section. You can filter the events based on event type: system and event sub type: Directory Services and look for DC connectivity or sync errors.
- Follow the online help guide and verify domain controller configuration settings.
- Check that traffic isn’t blocked by the internet or WAN firewall. Firewall rule that blocks unidentified users can block the Cato sync user and blocks the directory services.
- Walk through all the configuration steps in the Online Help Guide once again to verify that every step was performed correctly. If permissions are not set correctly on the service account used for the connection, you will get an access denied error.
The Cato Management Application generates this error when the PoP is unable to access the DC for real time sync. This error appears when clicking on the "Show Status" button in the Domain Controllers for Real Time Sync section or by email to the Account Admins.
This error usually indicates on a misconfiguration of the User Awareness feature settings. It can also occur due to firewall or routing configuration. Follow these steps to troubleshoot the issue:
- Check the Event Discovery and verify if there are events of unidentified users.
- Check that traffic isn’t blocked by Internet/WAN Firewall because of unidentified users.
- If it’s the first time you enable the User Awareness feature and you get DC sync errors, go to the Online Help Guide and verify that every step is configured correctly.
- Make sure that the DC is up and running.
- Run a traffic capture form the Socket UI capturing the packets (PCAP) on the LAN interface of the Socket, click on the Show Status button. Stop the capture and look for the WMI query from the Cato PoP and the server response in the capture file (using any network packet analyzer tool such as Wireshark). If the DC is behind an IPsec site, run the capture on the DC itself.
The error NT_RPC_NT_CALL_FAILED indicates that the RPC service on the DC doesn’t respond. This error appears when clicking on the "Show Status" button in the Domain Controllers for Real Time Sync.
- Verify that the Domain controller is up and running and check the CPU and memory. Sometimes high CPU or memory causes the server overload.
- Verify that the DC windows services are started and set for automatic startup:
- Remote Registry
Error: NT Code 0x80010111
This error means the PoP cannot communicate with the DC because of an RPC header mismatch between the PoP and the DC.
This error is common specifically on Windows Server 2022 where the DC's RPC version is validated.This is a known issue that customers may run into. If you receive this error please open a ticket with Cato Support to address it.
User Isn’t Mapped by User Awareness
In some cases, users are shown as "unmapped user" in the Event Discovery window. The reason for an unmapped user is that the PoP was able to discover the username in real time (using WMI queries) but this user wasn’t imported during the LDAP sync and is unidentified. Therefore, the event AD Name field shows unmapped user.
- Verify that the user belongs to the group. If you configured Cato’s Directory Services to import users and groups from the DC, and a user doesn’t belong to the configured group, it then appears as an unmapped user.
- Check the audit policy configuration for the DC. For more information see Configuring the Audit Policy for the Domain Controller.
Logon Events Don’t Appear in the Event Discovery
If you enabled User Awareness for your account but you can’t see any users log on events in the Event Discovery follow the steps that described in the following solution.
Check the audit policy configuration on the DC. For more information see Configuring the Audit Policy for the Domain Controller.
The Directory Services Sync Doesn’t Import Users
With User Awareness, shows in real time what are the usernames of hosts behind sites. It allows you to see the usernames of hosts and not just the IP addresses in the Analytics sections. User Awareness and VPN Users are populated from the Directory Services Sync. The Sync uses LDAP to query the Active Directory (AD) server. Sometimes the LDAP sync fails because of different reasons. For example, Microsoft LDAP has a known limitation that only allows objects with less than 1500 attributes to be returned in any single query. Large organizations can easily have more than 1500 members assigned to a group. Thus, when the PoP runs the LDAP query, any groups with more than 1500 members will return an empty members list to the Cato Management Application.
Follow these steps to troubleshoot this issue:
- Verify that the following windows services in the DC are running and set to automatic:
- Remote Registry
- You can adjust the DC Microsoft LDAP policy attribute for MaxValRange. This attribute controls how many values will be returned. Use the following two articles to raise the MaxValRange or remove the restriction entirely. If you don’t want to modify the AD attribute, then Cato can collect groups with less than 1500 users.
MS article on how to adjust MaxValRange using tool ntdsutil: https://support.microsoft.com/en-gb/help/315071/how-to-view-and-set-ldap-policy-in-active-directory-by-using-ntdsutil
MS article/blog on how to remove restriction completely:
Missing Audit Events when using GPO
If you are using a GPO with advanced security audit policy settings and not all Event IDs are being logged, follow the steps that are described in the solution.
Check the audit policy configuration for the DC. For more information see Configuring the Audit Policy for the Domain Controller.
Configuring the Audit Policy for the Domain Controller
The audit policy can either be defined locally on the DC or applied via GPO. GPO overrides the local security policy. Advanced audit policy settings override the basic audit policy settings.
Verify that the audit policy is configured with the Event IDs that User Awareness uses in the Windows security log in order to map users to IP addresses.
The following list contains the Event IDs the Cato uses in the audit policy:
- 4768 - A Kerberos authentication ticket (TGT) was requested
- 4769 - A Kerberos service ticket was requested
- 4770 - A Kerberos service ticket was renewed
- 4776 - The domain controller attempted to validate the credentials for an account\
- 4624 - An account was successfully logged on
- 4648 - A logon was attempted using explicit credentials
- 5140 - A network share object was accessed
- 5145 - A network share object was checked to see whether client can be granted desired access
To Configure the Audit Policy Locally on the DC
- Open Local Security Policy.
- Go to Security Settings > Local Policies > Audit Policy to configure the basic audit policy, or go to Security Settings > Advanced Audit Policy Configuration > Audit Policy to configure the advanced audit policy that provides more granular control over logging.
To Configure the Audit Policy using Group Policy:
- Open Group Policy Management Editor.
- Right click on the GPO that applies to all Domain Controllers and select "Edit"
- Expand Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Audit Policy for basic audit policy or Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policy for advanced audit policy.
The following list contains the Event IDs that are used by Cato’s User Awareness:
Basic Audit Policy
- Audit logon events - 4624, 4648
- Audit account logon events - 4768, 4769, 4770, 4776
- Audit object access - 5140, 5145
Advanced Audit Policy
- Account Logon
- Audit Kerberos Authentication Service – 4768
- Audit Kerberos Service Ticket Operations - 4769, 4770
- Audit Credential Validation – 4776
- Audit Logon - 4624, 4648
- Object Access
- Audit File Share – 5140
- Audit Detailed File Share - 5145
You can verify what the effective audit policy on a DC is by running the following command from a command prompt: auditpol /get /category:*
Please sign in to leave a comment.