Issue with User Filtering in Microsoft Entra with Multiple Sources

[AntonioGvtt (Antonio García Velatta)]

Hi, we are configuring two Microsoft Entra sources pointing to the same tenant to distinguish between regular users and administrators.

• The administrator source uses the filter:

userType eq 'Member' and startsWith(displayName, 'Admin -')

and it works correctly.

• The nominative users source uses:

userType eq 'Member'

but this results in administrators (who are also ‘Member’) being correlated under the same identity, creating two accounts for the same user.

We considered using the filter:

userType eq 'Member' and NOT(startsWith(displayName, 'Admin -'))

but the SailPoint documentation states that NOT is an advanced filter and clarifies:

“The Azure API does not support the advanced query filters while also using an expanded attribute such as manager in the URL. When using the advanced filters, ensure that you remove the manager attribute from the account schema and remove the owners attribute from the group schema.”

In our case, the manager attribute is mandatory, so we cannot remove it.

An alternative solution could be assigning a value to onPremisesExtensionAttributes.extensionAttribute and filtering by that. However, it seems that some fields (like these extended attributes or even EmployeeType) cannot be used in filters, or at least I’m not sure how to reference them properly.

In any case, the error message is as follows: [ConnectorError] Error occurred while fetching a page during aggregation: Request failed with status code 400.

Does anyone know how to solve this issue or if there’s a way to use these attributes in filters?

Thanks!

[RAKRHEEM (Rakesh Bhati)]

Hi Antonio,
Thank you for the post. We have a similar requirement and what we did is had a filter on the connector rather than making it apart of Advance filter. Please go through the below link and you can add the filter.

IdentityNow Account Filtering during Account Aggregation

Let me know if your issue gets resolved. Please mark it as Resolved.

[AntonioGvtt (Antonio García Velatta)]

Hi Rakesh,

Thanks for responding to my question. I’m not sure if I understand the link. I used the following request:

[
  {
    "op": "add",
    "path": "/connectorAttributes/account.filterString",
    "value": "( userType == \"Member\" && !(displayName.startsWith(\"Admin -\")))"
  }
]

I received a 200 OK response for the correct ID of the source. However, after executing an aggregation, the result is the same. In this case, should I make any other changes to the source configuration, or did I forget something?

Thanks!

[RAKRHEEM (Rakesh Bhati)]

Hi,
The request is not correct. The correct request should be

[
{
“op”: “add”,
“path”: “/connectorAttributes/filterString”,
“value”: “( userType == "Member" && !(displayName.startsWith("Admin -")))”
}
]

Make a note all the user which satisfy this criteria will be filter out from coming into IdentityNow

[AntonioGvtt (Antonio García Velatta)]

Okay, I changed the last filter and updated it with:

[
  {
    "op": "add",
    "path": "/connectorAttributes/filterString",
    "value": "( userType == \"Member\" && !(displayName.startsWith(\"Admin -\")))"
  }
]

The backslash (\) is mandatory because Postman doesn’t allow me to use double quotes (") without it. I also changed the path from account.filterString to just filterString, but the aggregation on the account still returns the same number of identities, including administrators

[RAKRHEEM (Rakesh Bhati)]

Hi Antonio,
Do you have Visual Studio ? or Get a source from postman and show me how does this look ? We need to check if the filter is properly set on the source

[AntonioGvtt (Antonio García Velatta)]

Hi Rakesh,

Sure, I use Postman to execute the request, but I also use VSC to check the source. This is the code for the filter executed

[RAKRHEEM (Rakesh Bhati)]

Hi Antonio,
Can you remove the ! from the displayName filter and try to do the aggregation again ?

Thanks

[AntonioGvtt (Antonio García Velatta)]

Hi Rakesh,
The idea is that we filtered the users who are not administrators, so we use ! as a Not operation. However, I can remove it just to check if the filter is working and leave the code as:

"filterString": "(userType == \"Member\" && displayName.startsWith(\"Admin -\"))"

But in this case, the result is the same, so I think the filter is not working as expected. Could this be because the userFilters parameter has a value like userType eq 'Member'?

[RAKRHEEM (Rakesh Bhati)]

Can you add a filter as ! (displayName.startsWith("Admin -"))" and remove filter of userType == Members ?

[AntonioGvtt (Antonio García Velatta)]

Yes, I changed the filter. Now it is:

"filterString": "(!(displayName.startsWith(\"Admin -\")))", 

but unfortunately, the result is the same. I’m not sure if something in the source configuration is causing the filter not to affect the aggregation.

[RAKRHEEM (Rakesh Bhati)]

Hi Antonio,
This startsWith is not supported by the filterString. Can you try your filter with containsIgnoreCase filter please and see if it fixes your issues ?

((!(mail.containsIgnoreCase("@xxx") || mail.containsIgnoreCase("@xxx") || mail.containsIgnoreCase("@xxx"))) || (employeeId.containsIgnoreCase("xyz")))

Thanks
Rakesh Bhati

[AntonioGvtt (Antonio García Velatta)]

Hi Rakesh,

Apparently, IdentityNow Account Filtering does not work correctly when using a SaaS connector, as is my case, so we cannot use this type of filter.

Thanks,
Antonio.

[RAKRHEEM (Rakesh Bhati)]

Hi Antonio,
The given filter is working fine when we have Entra ID connected using a Virtual Appliance. I am not sure why this is not working when using Entra ID as SAAS connector.

Thanks
Rakesh Bhati