• State Not Answered
  • Replies 7 replies
  • Subscribers 95 subscribers
  • Views 2489 views
  • Users 0 members are here
Options
Related

Exclude some AD groups from automatic removal due to expired employee's exitdate

Wilke Jansoone
over 3 years ago

Hello,

I am using OIM 8.1.4.

One of the functional requirements of my company is that when an employee's exit date is reached, that all AD group memberships are removed except a limited number of special assignments (O365 related).

In our configuration the employees get their AD group memberships via either:

- Employee => Business Role => System Role => AD Group(s)
- Employee => System Role => AD Group(s)

I initially thought I could manage this by setting the XOrigin flag for the special AD group assignments to 3 (indirect + direct) and then when OIM executed the removal process (manage level's retain group settings are not enabled) it would take into account this flag and leave these direct group memberships.

Unfortunately this is not what happens, all the groups are removed irrespective of the XOrigin flag. It seems that the removal of the AD groups dictated by the manage level's retain group settings does not take into account the XOrigin flag. After the processes have done their job, I see in the object browser that the employee still has the business roles assigned, the system roles are assigned (XIsInEffect: true) and the ad groups are also still assigned  (XIsInEffect: false).

So my question is, can you advise me how I can configure the system or implement a process that ensures that the AD group removal process is able to exclude a number of special AD group assignments of being removed. So it seems a small extension on the existing OOB processes but have no idea how to tackle.

Many thanks in advance for your assistance.

Regards,

Mrs. Wilke Jansoone

  • 0 over 3 years ago

    One idea is to do this via MatchPatternForMembership.

    That means: The TSBBehavior is configured so that memberships are always retained.

    The categories [0] "NormalGroup" and [1] "KeepGroup" are defined for "Group", above which the (manual) identification of the groups takes place.

    For "Account" there are the categories [0] "InheriteNormalGroups" and [1] "InheriteKeepGroups". These are set on the accounts using a template.

    First of all, all accounts have set [0] and [1]. For example, if an account is disabled, [0] is removed. The account then loses all inherited NormalGroups and only keeps the KeepGroups.

    BUT: This only works for inherited groups. 

    Solution: You need to build a process that converts all direct membership into orders for terminated users.

    It's not as small as you might have hoped     but it should work.

  • 0 over 3 years ago in reply to Markus Weiss-Ehlers

    Hello Markus,

    Thank you for your feedback. Although I do not yet understand what you are telling me, it seems interesting. I tried to look for more information on the concept of MatchPatternForMembership but could not find much of that. Can you point me to a reference page that tells me more about MatchPatternForMembership?

    Thank you in advance.

    Regards,

    Wilke

  • 0 over 3 years ago in reply to Wilke Jansoone

    Sorry, Wilke. MatchPatternForMembership is the property name at a group used for the feature "group inheritance based on categories". You will find more here:

    https://support.oneidentity.com/technical-documents/identity-manager/8.1.5/administration-guide-for-connecting-to-active-directory/36#TOPIC-1645496

  • 0 over 3 years ago in reply to Markus Weiss-Ehlers

    Hello Markus,

    Works like a charm. Thank you. Can you confirm that when we would like to take advantage of AD group inheritance using categories we need to attribute all AD groups with the required categories?

    Thank you.

    Regards,

    Mrs. Wilke Jansoone

  • 0 over 3 years ago in reply to Wilke Jansoone

    When you want to take advantage of your solution for every group you need to tag them, yes. But in general, untagged groups will be inherited regardless if the user is tagged or not (at least this is how I am remembering it). But this should be explained in the docs as well.

  • 0 over 3 years ago in reply to Markus Weiss-Ehlers

    Hello Markus,

    Do I have it correct that when you disable the 'retain groups' options for AD manage levels, AD group membership is controlled via inheritance. The inheritance is then either based on assignment via roles or based on categories. So the only way to remove AD group membership is to disable inheritance, either by removing role assignment or category mapping.

    One last question, is AD group membership via inheritance through categories a robust way to manage ad group membership in a more granular fashion?

    Thank you in advance.

    Regards,

    Mrs. Wilke Jansoone

  • 0 over 3 years ago in reply to Wilke Jansoone
    Wilke Jansoone said:
    Do I have it correct that when you disable the 'retain groups' options for AD manage levels, AD group membership is controlled via inheritance. The inheritance is then either based on assignment via roles or based on categories. So the only way to remove AD group membership is to disable inheritance, either by removing role assignment or category mapping.

    No, when you disable "retain groups on..." all group memberships will be inactived (XIsInEffect=1) but the entries are still in the database to be able to re-activate those memberships.

    Wilke Jansoone said:
    One last question, is AD group membership via inheritance through categories a robust way to manage ad group membership in a more granular fashion?

    Yes, but it depends on how many categories you are having (current limit is 32, coming with version 8.2 it will be 64)