Here’s an example of a UocListView configuration that will add a “Member Of” list to either a User or a Group RCDC. Here I have happened to specify Distribution Lists only.
<my:Control my:Name="GroupMemberOf" my:TypeName="UocListView" my:ExpandArea="true" my:Caption="Member Of">
<my:Properties>
<my:Property my:Name="ColumnsToDisplay" my:Value="DisplayName,Email,Domain,DisplayedOwner" />
<my:Property my:Name="EmptyResultText" my:Value="There are no groups according to the filter definition." />
<my:Property my:Name="PageSize" my:Value="20" />
<my:Property my:Name="ShowTitleBar" my:Value="true" />
<my:Property my:Name="ShowActionBar" my:Value="false" />
<my:Property my:Name="ShowPreview" my:Value="false" />
<my:Property my:Name="ShowSearchControl" my:Value="false" />
<my:Property my:Name="EnableSelection" my:Value="false" />
<my:Property my:Name="SingleSelection" my:Value="false" />
<my:Property my:Name="ItemClickBehavior" my:Value=" ModelessDialog " />
<my:Property my:Name="ListFilter" my:Value="/Group[(Type='Distribution') and ((ComputedMember='%ObjectID%') or (ExplicitMember='%ObjectID%'))]" />
</my:Properties>
</my:Control>
Â
Other things I’d like to be able to do (but as far as I can see you can’t with this version of FIM):
- Modify a person’s group memberships by editing the person (membership to add, membership to remove),
- Show all the groups a person is a member of via nested groups.
Regarding the things you’d like to be able to do but cannot see how to do in FIM. You cannot directly modify a person’s group membership via the memberOf attribute because it is a back-link attribute. In Active Directory, back link attributes are maintained by the system and cannot be manipulated. The best you can do is use it as a reference to the group and modify the member attribute of the group.
Nested groups are an application-centric concept and not a directory-centric concept. Unless the application has specifically been designed to honor nested groups, they will not (e.g., most LDAP membership providers do not recognize nesting, only direct members). There is a performance hit for group nesting — this is why Exchange allows the designation of expansion servers). Windows security groups honor nesting; however, they are generally evaluated once when the user’s token is built. Walking nested groups requires an iterative approach.
Michael, if you read Carol’s post you’ll see she’s not actually using the MemberOf attribute, but hitting the groups directly to determine which groups a user is in.
Carol, could you not do this by having a single “role groups” attribute on the user that is used by criteria-based groups to determine which members are in it? It would essentially be the equivalent of having department based groups based on what the ‘department’ attribute is set to.
You could probably go one step further and create a multi-value reference field with a picker which allows you to select groups that a user should be added to. This will “add the groups to the user”, but you could then use a query similar to the one you’ve used above to do the group membership generation… ie, the ComputedMember criteria is something akin to:
/Person[(roleGroup=’%ObjectID%’)]
Theoretical – but I’m going to have a play to see if this is possible.
(apologies for ultra delayed reply to a year-old post)
I’m doing a lot with roles that are then used in group criteria – it’s a great way to handle things and very flexible. This example here is purely for display purposes only as it can be useful to see a list of all groups while viewing the person’s details.