How to resolve a "Expert Mode" query rule violation?

Hi all, Community!

we are facing some problems trying to implement a rule violation in Identity Manager 8.12.

The main issue is that the query to detect the violation is quite complex, and we must write it in expert mode. In particular, we need to detect all the assignments (ADSAccountInAdsGroup) a person has, but for which there is no PersonWantsOrg with orderstate = “Assigned”. If this happens, the violation is raised.

Since we have to use expert mode, there seems to be no way for the approver to use the "Resolve" button (in the web portal) functionality, which, on the contrary, are fully usable if the query were written in simple mode.

If you have any idea, please share…

Thanks in advance.

Alberto

Parents
  • As you are using 8.1, you can try to formulate your SQL condition as sub-query for AD groups in simple mode.

  • Hi Markus

    Please be very clear. Is there a way to dig into the type of assignment of an object to a person, and check if that assignment comes from a PWO (adsgroup à accproduct à BaseTree à PersonWantsOrg) or comes from direct assignment, inheritance, or other kind of indirect assignment? This using the Editor Mode?

    Maybe there is a way to pass inside the query the uid_person of the “current” person (as we pass, for example, the pwo parameters of the current request inside the station in a workflow)?

    Maybe using the “ function” (sorry I couldn’t find enough info about those function, that are selectable in the Query Mode?

     

    Thank in advance

    Alberto

  • While still thinking about a solution with the compliance rule, wouldn't this instead be a usecase for a recertification (with auto-removal) of these memberships?

    Or what is the exact use-case for this? I am asking, because any group membership from a request will end in an "Requested" membership. So why do you want to resolve the "unrequested" memberships via a compliance rule?

  • Markus

    First of all, thanks for taking care of this “issue”.

    Even we thought to use Recertification, “we” decided to go Violations.

    Let’s say there is a ADSGroup. This ADSGroup

    • can be published into to ITShop through it’s product (ADSGroup.UID_AccProduct).
    • can be bound to an Eset, published into to ITShop through eset’s product (ADSGroup.EsetHasEntitlement.UID_Eset.UID_AccProduct)
    • can be bound to some object assignable to a Person/AdsAccoun
    • A combination of the 3 options above

    Again, the ADSAccouontInADSGroup could come from

    • ADSGroup direct assignment
    • ADSGroup indirect assignment without PWO
    • ADSGroup indirect assignment through approved PWO
    • A combination of the 3 options above

    We need to detect all the assignments for which there Is no approved request (PWO) and consequentially raise a Violation.

    This is the scenario.  

    Alberto

Reply
  • Markus

    First of all, thanks for taking care of this “issue”.

    Even we thought to use Recertification, “we” decided to go Violations.

    Let’s say there is a ADSGroup. This ADSGroup

    • can be published into to ITShop through it’s product (ADSGroup.UID_AccProduct).
    • can be bound to an Eset, published into to ITShop through eset’s product (ADSGroup.EsetHasEntitlement.UID_Eset.UID_AccProduct)
    • can be bound to some object assignable to a Person/AdsAccoun
    • A combination of the 3 options above

    Again, the ADSAccouontInADSGroup could come from

    • ADSGroup direct assignment
    • ADSGroup indirect assignment without PWO
    • ADSGroup indirect assignment through approved PWO
    • A combination of the 3 options above

    We need to detect all the assignments for which there Is no approved request (PWO) and consequentially raise a Violation.

    This is the scenario.  

    Alberto

Children
No Data