Veteran

Solved

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

Forum|Forum|1 year ago
October 3, 2024
19 replies
983 views

I have a hybrid environment where my on-prem AD group accounts are created and then later on syncd to Entra ID. When I add one of the syncd groups, the filter does not get applied at all. Does anybody know how EPM checks for which group a user belongs to? I tried creating a separate Entra ID cloud group and added myself as a member, got the sync completed via the API, then added an account filter using this group, still does not get applied. What am I missing?

Best answer by Paul

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

Hi @Jasper,

In that case, it’s very likely this will be where the issue is coming from. EPM is attempting to query the group membership data from PM Cloud using the UPN of the logged on user.

For most customers their local AD domain UPN and the UPN of the synchronized accounts in Entra are different, so whilst we might log in with john.smith@ad.local, that account exists in Entra as john.smoth@corporate.domain. Obviously if we ask PM Cloud for ‘john.smith@ad.local’, that UPN doesn’t exist so no group data is returned to the cache.

The information was a little buried in my reply, but as I noted earlier, for workstyle targeting with hybrid-joined environments we recommend adding both on-prem AD groups and Entra ID groups to your workstyle filters, so that however you user logs in (against an AD domain controller or Entra) they should get the correct experience.

If some of that doesn’t hold true for your environment, then perhaps the issue lies elsewhere, but that seems like the most likely cause based upon what you’ve described.

Show previous replies

Paul

BeyondTrust Employee

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.

J

JasperAuthor

Veteran

@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.

Paul

BeyondTrust Employee

@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?

J

JasperAuthor

Veteran

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

PaulAnswer

BeyondTrust Employee

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

Hi @Jasper,

In that case, it’s very likely this will be where the issue is coming from. EPM is attempting to query the group membership data from PM Cloud using the UPN of the logged on user.

For most customers their local AD domain UPN and the UPN of the synchronized accounts in Entra are different, so whilst we might log in with john.smith@ad.local, that account exists in Entra as john.smoth@corporate.domain. Obviously if we ask PM Cloud for ‘john.smith@ad.local’, that UPN doesn’t exist so no group data is returned to the cache.

The information was a little buried in my reply, but as I noted earlier, for workstyle targeting with hybrid-joined environments we recommend adding both on-prem AD groups and Entra ID groups to your workstyle filters, so that however you user logs in (against an AD domain controller or Entra) they should get the correct experience.

If some of that doesn’t hold true for your environment, then perhaps the issue lies elsewhere, but that seems like the most likely cause based upon what you’ve described.

E

eohlin

Apprentice

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.

Paul

BeyondTrust Employee

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.

E

eohlin

Apprentice

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).

Paul

BeyondTrust Employee

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.

Badge Earners

Sign up

Login to the community