EPM filter not working for on-prem sync group to EntraID

There is a process that syncs entra groups to the local machine. Unless this process occurs, any group changes will not be seen on the device. You can logout and back in, reboot, or issue an endpointutility.exe /aad command to kick off the sync process. That has been my experience when seeing this issue. Hope this helps.

Missing in the guides.

EPM checks based on the endpoints local cached group memberships from Active Directory or Entra Active Directory. Often times it’s easiest to have the user log out and back into their machine to have to group memberships updated and allow EPM to recognize those changes.

​​​​​​​

@Austin Lawson , have done that a couple of times. I know that when I sign in, EPM can leverage and check my cached local AD group membership but when I add an EntraID group as my filter (which uses GUID, not SID), it cannot seem to recognize it.

Thanks @Jens Hansen , I did run the endpointutility.exe /aad a couple of times already and it showed as “Successful” but it is still not getting filtered. Is there any way for me to check how EPM actually queries a user’s group membership to check on the filters being defined? 

Hi @Jasper  Make sure you log off and back on, that is still a requirement for now.
The old school way was simply from an standard Command Prompt run “whoami \all” that would give you all the Group memberships from AD, and you would be able to validate it. For Entra ID it’s different, I don’t think you can do it directly from the client side with out tools. If you are a Hybrid joined domain, you could fall back to ON Prem AD Groups, that would resolve the issue for matching your filters, but require that you get the AD Connector installed on a resource that is allowed to browse AD. Check the local users & Groups and your account also might show here also. (this is an On-prem account)
 

In order to use groups for Workstyle filtering, EPM uses two different mechanisms. 

For On-Prem Active Directory and local groups, this data is natively cached on the endpoint after a successful logon. EPM does not actively perform any operation to update or refresh this itself, but simply consumes the data that the O/S provides. Changes to group memberships may be available to EPM during a login session, but logging off and back on again is a good practice to confirm this has occurred. 

As Jens notes, this information is available to review using the whoami /groups command.  

For Entra ID groups, this group membership data is not cached locally by the O/S, so in order to leverage it for the purposes of Workstyle filtering, EPM needs to create and maintain its own client-side cache of that membership data. 

This client-side cache is within the agent’s protected container in %ProgramData% and is updated at user login, and as Josh noted, can be manually refreshed using the endpoint utility included as part of the Agent. 

However, this will only pull Entra groups if you are logging on with your Entra UPN, as it needs to use this to identify the account and resolve the groups. If you are authenticating against AD, you will not have Entra groups associated with the sync’d identity - so for workstyle targeting with hybrid environments we recommend adding both on-prem AD groups and Entra ID groups to your filters.  

To complete the picture, the client-side cache is pulling the membership data from a cache in PM Cloud, to allow us to quickly provide this data back to the endpoint, rather than having to make a Just-In-Time request to Entra itself. This cache is periodically updated (e.g., pulling back all groups so you can select them as filters), but updates groups which are referenced in Workstyle filters every 10 minutes. You can also manually force either of these syncs via the PM Cloud UI, if required. 

In terms of troubleshooting, after confirming you are authenticating against Entra when logging into the endpoint, I would ensure that you have your PM Cloud cache updated, perform the client-side cache update (either by logging out and back in, or using the endpoint utility) and then inspecting the agent’s group membership cache to confirm whether it is present. 

If you are still facing issues, then I would certainly suggest you reach out to the support team to help investigate further. 

Would it be possible to get a tool to validate client side cache of the Entra ID Groups?

Hi Jens, the cache is essentially just a set of files which represent the Entra groups for a given user in their GUID format. You can certainly write a simple script to just return the list of GUIDs currently present in the cache, but a dedicated tool isn’t required. 

Obviously the usual caveats apply that the cache location is protected by anti-tamper, so you would need to either run your script as a true admin or elevate it via EPM using a custom token with tamper protection disabled. 
 

GUID’s are more than sufficient for people to validate if the groups are present.
Then since groups are already known by PWS Cloud, do a compared of GUIDs and return the names to the EPM App maybe? We only need to focus on the groups used in the filters of the workstyles in this case.

The cached group membership data in PM Cloud isn’t exposed as it isn’t required for normal operation, but you could certainly compare the client-side cached GUIDs against the groups that are assigned to the user within Entra. 

@Paul , I am assuming that the client-side cached folder you mentioned, is  the AzureADCache folder that automatically gets created inside ProgramData\Avecto? My API is able to read and sync the EntraID group but is not showing the cached folder on any of my endpoint.

Hi @Jasper - if the PM Cloud configuration is in place (I’m assuming you are using PM Cloud based upon some of you previous comments) and has synced etc, then the most obvious issue is that we are unable to identify the user to correctly return their associated groups.  

Can you confirm that your users are logging into their endpoint with an Entra ID account, rather than a local admin account against a DC? Also, for my reference, are the users sync’d from AD, native Entra or external users invited into the Entra tenant you have integrated?

Hi @Paul , that is correct. we are using PM Cloud.

Users are logging into their endpoints against on-prem DC (not local admins) and these user accounts get syncd from AD to EntraID as well including their group memberships

I just encountered another situation where “C:\ProgramData\Avecto\Privilege Guard\AzureADCache” can fail to be created. And that would be RDPing into a machine or VM. 

I spent hours troubleshooting this… “Why is AzureADCache” missing!?!?

As soon as I stopped RDPing into the computer, and logged on to it physically, the folder appeared immediately. 

If you haven’t already ​@eohlin, I would suggest getting that logged with the support team for further investigation, it may be that logon type is not correctly triggering the group refresh operation. 

It may be a useful troubleshooting step to confirm whether using the endpointutility.exe (included with the client install) with the /aad parameter described previously in this thread, to trigger the same refresh operation manually, and confirm it correctly populates/updates the group when logged in via RDP.
 

Hey ​@Paul, I’ll create a support ticket for it. :) 

I tried running endpointutility.exe /aad while logged in via RDP, but nothing happened. I waited probably 20 minutes or so, and it was still running in the console (and the AzureADCache folder never appeared).

Great minds! 😉

I would certainly include that detail when raising the case. The team will likely ask you to capture some logs and I think there is value in capturing them for both of the scenarios you’ve tested, as is certainly appears something more fundamental is failing in this scenario than simply the refresh not being triggered.