Active Directory user group resolution failed
search cancel

Active Directory user group resolution failed

book

Article ID: 208831

calendar_today

Updated On:

Products

Data Loss Prevention Endpoint Prevent Data Loss Prevention Data Loss Prevention Core Package

Issue/Introduction

You may receive the error "Active Directory user group resolution failed for different reasons."

1. When agents are connecting via VPN they are not in contact with the Active Directory server when the system first boots up and the agent is initialized.

2. If Agent User Groups are failing to resolve the configured Group or User accounts.

3. If a custom User Group attribute is created the Endpoint Agent edpa log may show, "Failed to resolve attribute : "<custom attribute name>". Error code : -2147016646 , Error description : The server is not operational."

 

Environment

DLP 15.8+

Cause

1. DLP agents re-initialize that process when a network change is detected. Sometimes the underlying connection to the AD server can take longer than expected.

2. If Agent User Groups are configured for specific user accounts and the user no longer exists in AD, then the user group resolution will fail.

3. The Active Directory User attribute name does not match exactly to the actual AD ldapDisplayName.

Other considerations:

Group resolution failed is a common error, especially if the organization has an Endpoint Server in the DMZ. Because the agent can reach the endpoint server while being entirely off network/off VPN, meaning they can't get to active directory but they can get to DLP. This warning can be an appropriate representation of that reality.

If an organization uses many group based rules, but their employees can work from home without needing VPN for their work tools, then they have to accept this warning will occur and it's consequences. 

Let's say someone works from home and they change roles from Legal to Finance. 
And the customer has some policies that apply to legal and some that apply to finance. based on ad groups. 

When the user connects to VPN their agent queries LDAP and stores the groups that user is a member of in grp.ead
Lets say they were last on VPN on Monday, but their role changed Wednesday. 
They still only have the groups for Legal in their grp.ead, so their policies won't apply to them as expected, until they connect to the VPN and on-prem AD is reachable, and the groups update to their new AD groups(unrelated to DLP, related to changes in AD due to their role change)

In these situations as with other potential use cases the warning of "Active Directory user group resolution failed" would be expected behavior, therefor a certain amount of these warnings should be expected. It will be up to the administration to understand the patterns to recognize if these warnings are anything to be concerned with or not.

Example being: if you notice USERID#### always seems to have these warnings every Monday morning, but they clear up Tuesday afternoon. The remediator should look at this users usage patterns and learn that he/she works off of VPN on Monday mornings and does not reconnect or return to office until Tuesday afternoon. It should be noted that is is safe to ignore these warnings for that user under those conditions.

Whereas if you suddenly see a huge spike in this warning for every user overnight, you may want to reach out to your AD team and find out if there is something wrong with the AD server being used by DLP, perhaps that server was decommissioned and there was a failure in communication to the DLP team advising them of the new server to be used.

 

Resolution

1. In the agent advanced settings configuration locate the label named is ServerCommunicator.CONNECT_DELAY_POST_WAKEUP_OR_POST_VPN_SECONDS.int      The default value is 30 seconds. Increase this value until the issue is resolved [The range for this setting is 30 to 600 seconds.]

2. Go to Manage > User Groups, select the User Group that is failing, remove the user accounts that no longer exist in AD and Save.

3. Ensure that the Active Directory attribute name for the Custom Attribute matches exactly to the AD ldapDisplayName.