Population: Fetch Identities with specific application disabled

[mili_patel]

Hi All,

Need to create a Population, where we need Identities who is having a specific application disabled. Let’s say I have an application account “Active_Directory” and there is searchable Link attribute “disabledAccount” (this will be set to true if IIQDisabled of the AD link is true). Hence I need all the users who has disabled AD link. I’ve used the following filter

< GroupFilter>
< Filter operation="COLLECTION_CONDITION" property="links">
< CollectionCondition>
< CompositeFilter operation="AND">
< Filter operation="EQ" property="application.name" value="Active_Directory"/>
< Filter operation="EQ" property="disabledAccount" value="true"/>
< /CompositeFilter>
< /CollectionCondition>
< /Filter>
< /GroupFilter>

This Filter is fetching users having disabled AD Links and if disabledAccount is false for AD, but is true for some other application account, even then it is fetching those Identities. Here, it is checking for all the links disabledAccount attribute, but our requirement is we need to check disabledAccount = true only for AD Application. How do we achieve this in population? tried CompoundFilter and population is not supporting it. Please help!

[Remold (Remold Krol)]

The simplest solution I can think of of is a Identity attributes based on an application rule. Where the application is AD and the rule sets the attribute based on UserAccountControl of the AD account (can also be IIQDisabled).

Identity attribute: hasADAccountDisabled

String userAccountControl = (String) link.getAttribute(userAccountControl);
uac = Long.parseLong(userAccountControl);
 if ((uac & 2) != 0) { 
  return "true"; // Disabled
} else {
  return "false"; // Enabled
}

Creating a population on the identity attribute should be a piece of cake

Note: find a proper solution for identities which have multiple AD accounts. The above example does not take this into account.

– Remold

[Jarin_James]

Hi @mili_patel

You can try the following. The example shown is for different boolean attribute but you can use the same logic in your case as well.

As shown in the above example you can use the Application and Service Account is the searchable Link attribute. And this is how the filter look like

 <GroupFilter>
    <CompositeFilter operation="AND">
      <Filter joinProperty="Link.identity.id" operation="JOIN" property="id"/>
      <CompositeFilter operation="AND">
        <Filter operation="EQ" property="Link.application.id" value="c0a800697d9e181c817d9f01ea3a0331"/>
        <Filter matchMode="START" operation="LIKE" property="Link.Service Account" value="true"/>
      </CompositeFilter>
      <Filter ignoreCase="true" operation="EQ" property="links.application.id" value="c0a800697d9e181c817d9f01ea3a0331"/>
    </CompositeFilter>
  </GroupFilter>

And it is working for me as expected by returning the users only for the specified application

[drosenbauer (Devin Rosenbauer)]

Yes! I knew it!

I posted here several months ago about how the CollectionCondition Filters aren’t working properly in recent versions of IIQ, and this is exactly the behavior I was seeing. This is actually the specific documented example on the Compass “Filters and Filter Strings” article, and it does indeed not work.

Filter collectionCondition appears to be broken?

Is anybody else seeing some odd behavior with Filter.collectionCondition? Specifically, it doesn’t seem to be joining only once on the table, but rather many times. This is the example query from the Filters and Filter Strings documentation page on Compass: links.collectionCondition("application.name == \"AD\" && privileged == \"true\"") With HQL debugging on, this renders as follows: select identityAlias.id, identityAlias.name from sailpoint.object.Identity identityAlias inner join i…

The good news is that it’s easy with Links, and @Jarin_James has the correct answer: use a join. This only works because there’s no intermediate join table between Identity and Link (ala spt_identity_assigned_roles), so you can join from Link to Identity directly.

[drosenbauer (Devin Rosenbauer)]

Oh also, it’s important to note that this may primarily affect Populations. This is because they translate the filter into HQL, and then run that as a search against the database directly. They do this because they’re answering the “who matches?” question. It’s the translation to HQL that’s behaving oddly.

Other places filters are used, like role assignment selectors, may use an in-memory matcher, because they need to answer “does this person match?” … and the logic for Filter.collectionCondition may be implemented properly by those matchers.

[mili_patel]

Thanks mate! I’ve been into Advanced search directly and stuck there by missing this basic approach. Cheers!