none
Corrupted criteria based groups RRS feed

  • Question

  • Hi,

    I have a problem with the AD groups managed with FIM. I created an empty group in AD, I imported it in MV and exported to the Portal (with membershiplocked = true). In the Portal I created a specific filter. The criteria based group worked well.. until today when I wanted to change the filter.

    Even with an administration account, I cannot change anymore the filter criteria because of this error:

    "Group validation failed: A group with calculated membership cannot have explicit members added or removed."

    I noticed that in advanced view -> extended attribute I have some manually managed members plus the filter! Why? I didn't add them! I cannot delete these members because of the error posted before.

    1) Can you tell me how to repair this group?

    2) And an other thing. Until now I added members to groups manually on Active Directory. Now I would import these groups (with associated domain policies) and manage them with FIM, overwriting members with a criteria based filter. How can I import them and overwrite members? If I import them with memershiplocked = true I obtain a corrupted group as the group before, in which I cannot set the filter criteria because of there are members in manually managed members in advanced view.

    Thank u in advance.

    Wednesday, September 26, 2012 7:58 PM

Answers

  • Hello Francesca,

    If that is your problem, create the group with criteria in FIM and add this to the AD group you want to manage. If you are satisfied that the proces of adding and removing of users work you can remove the user from the AD group. You even can check if the user us in the FIM group before you remove it from the AD group.

    The same goes for the group whith the manual added users. With this scenario you don't have to change or transfer the rights associated with the existing AD group but can still manage the users from FIM.

    Fer

    Thursday, October 11, 2012 9:23 AM

All replies

  • Hi Francesca,

    The membershiplocked flag will do exactly what the name says. It lockes changes to the group membership which are handy for group like Domain Admins and means that you can only change the memberships in AD. If you plan to change the group membership, so not set this flag. You would probably need to re-import this group without the flag set to get it working with the process you are trying to follow.


    Visit My Blog: http://theidentityguy.blogspot.com/

    Thursday, September 27, 2012 1:05 AM
  • Jsstinq, I'm trying to do this.

    • Import groups from AD to the metavers as manually managed groups (membershiplocked = false only for the first import - done with rule extension)
    • Export groups from MV to the Portal. In the Portal I can see all members manually managed on AD.
    • Change in the Portal the group from manually managed to criteria-based and set the criteria (a subset of user manually managed)
    • Import groups from the Portal to MV (with membershiplocked = true because I changed the property on the Portal)
    • Now I expected FIM detects changes to do in AD, instead it wants to re-change the modication on the Portal, adding the members that are not present in the group on the porta...

    Which is the correct way to do this (overwriting existent members on AD)?


    Note: member attribute has equal precedence.
    • Edited by Francesca85 Thursday, September 27, 2012 8:45 AM
    Thursday, September 27, 2012 7:04 AM
  • Hello Francesca,

    If you want to use criteria based groups you can not import memberships from AD. Imported members are always added as manual. This will corrupt your cirteria based filter. With equal precedence set the last input will be processed, so if group is set up from ad to fim and back any change in AD will be processed again.

    If you want to use AD imported members in a criteria based group you should try to use nested groups. Then you have the target group for AD which has members from a criteria based group (FIM members) and members from a manual managed group (AD Members).

    Thursday, September 27, 2012 11:04 AM
  • Fer, the problem is that I have some groups manually managed and some groups to be automatically managed.

    I tried to create a rule extension to avoid membership attributo flow from active directory only for groups I want to be automatically managed, but wasn't able to implement it. The problem was that the membership attribute is a reference attribute and cannot be managed with rule extension...

    Have you an alternative solution?

    PS: I don't want to use AD imported members in a criteria based group you should try to use nested groups. I want only overwrite them with the members calculated.

    Thursday, September 27, 2012 11:56 AM
  • I don't understand why my group was corrupted. My original procedure was:

    • Import an empty group from AD with membershiplocked = false (I want manage this group only automatically with FIM portal). I can import membership (needed for the other groups manually managed) because the group is empty.
    • Create the criteria on the portal and export membership to AD.

    I've never add users to this group directly from AD. Why did it corrupt? There is no apparent reason... isn't it?

    Is this procedure ok? Even if the empty group is member of an other group manually managed? Please, any suggestion is appreciated.


    • Edited by Francesca85 Thursday, September 27, 2012 12:45 PM
    Thursday, September 27, 2012 12:24 PM
  • you have set equal precedence, what happens is that FIM removes a user which does not fall under the criteria anymore and AD adds the user right back into the group. That will corrupt the group.

    If no users are imported from AD ever, you could set the precedense to FIM then AD that would prevent the flow back. Initial memberships will be imported for the manual managed groups.

    Thursday, September 27, 2012 12:42 PM
  • Ok, but I have an other problem.

    The empty group on Active Directory has 2 groups as members. I want to import it in the Portal and manage automatically only person objects. I noticed that it is not possible because the group on the Portal is corrupted (it has 2 groups as members in advanced view and the property criteria-based.. so I cannot set the criteria for the famous errore above).

    There is a way to manage this issue?

    Thursday, September 27, 2012 1:05 PM
  • Try the other way around. Create an empty group in AD and manage this with the desired criteria. Put the groep managed in FIM in an AD group with the other groups so the group managed by FIM wil nog get the groups from AD.

    From the point of FIM try to work with single objects or merge the objects in FIM. (Resource ID is meber of <group name>)

    That would be:

    FIM Criteria Group

    AD group1

    AD group2

    FIM overal group: (match any criteria)

      Resource ID is member of FIM criteria group

      Resource ID is member of AD group1

      Resource ID is member of AD group1

    Thursday, September 27, 2012 1:31 PM
  • Hi Francesca,

    This is a workable solution that Fer has suggested. I would like to know however what would prevent you from simply creating the group in the portal and exporting it to AD?


    Visit My Blog: http://theidentityguy.blogspot.com/

    Friday, September 28, 2012 1:11 AM
  • Jsstinq,

    groups are existent groups on Active Directory, with already associated domain policies and links with applications. Before FIM these groups were managed manually on Active Directory

    Now I would manage some of them automatically (replacing existent members with calculated members on the portal).

    If I create new groups on the Portal I'll lose any connection of them with policies and applications.

    Thanks.

    Francesca

    Thursday, October 11, 2012 9:13 AM
  • Hello Francesca,

    If that is your problem, create the group with criteria in FIM and add this to the AD group you want to manage. If you are satisfied that the proces of adding and removing of users work you can remove the user from the AD group. You even can check if the user us in the FIM group before you remove it from the AD group.

    The same goes for the group whith the manual added users. With this scenario you don't have to change or transfer the rights associated with the existing AD group but can still manage the users from FIM.

    Fer

    Thursday, October 11, 2012 9:23 AM