Skip to main content

Hi,

 

Scenario 1: The account filter is not functioning for the workstyle we applied. We used an Azure AD group to block the application in this workstyle, but the account filter does not work for the "Block App" workstyle. Instead, it qualifies for other workstyles. To clarify, we have listed the "Block App" workstyle at the top and the other workstyles below it.

 

Scenario 2: When we remove the account filter and apply a computer filter by adding a hostname entry, the created block application rule will function correctly.

 

Is the EPM policy workstyle Account filter not functioning with Azure AD groups on Windows?

AzureAD groups have worked great for us. It really does come down to group membership synced to the local machine. This process is initiated when the user logs in to the machine, you can also execute a sync using the endpointutility.exe /aad command. 


Hi, 

 

Thanks @Josh Bristow  for the update but my query is when i am adding azure Ad group in the account filter the workstyle rule( "Block App") not affecting to this group rather than it will qualifying another workstyle rule in the policy. To clarify, we have listed the "Block App" workstyle at the top and the other workstyles below it.


Hey , @Manasvi  , there might be some issues with the account filter might be you are not adding correct SID for the AD group you need to use here.

 

Do try , adding the Azure AD group on a particular Application group specific to that “Block App” functionality you want as per new features in the new BT versions.


Do check that if it works.

 


Note to use Entra ID Security Groups, it is required that users are logging on to the PC using the UPN and not the on-prem AD Domain/username format

logon as Domain/username will not refresh Entra ID Group membership and filtering will not work.


This is a similar older discussion.
https://beekeepers.beyondtrust.com/topic/show?tid=5648&fid=7


@Manasvi Generally @Jens Hansen’s & @Josh Bristow’s answers address the most common issues we see that cause the issue you’re mentioning. They’re also the first asks that Support would ask you to confirm.

Just out of curiosity: when you run a ‘whoami /user’ || ‘whoami /all’ on one of these machines does the SID start in S-1-12? Or S-1-5?


in other words:
Check the SID Prefix: Look at the SID prefix:
If the SID starts with S-1-5, it is an on-premises AD account.
If the SID starts with S-1-12, it is a Microsoft Entra ID account.

whoami /user

If your accounts starts with S-1-5 Azure Groups will not work.


Reply