When someone creates a new user, they will also choose some of their roles for our applications. Right now I'm looking at how to add their roles through the user creation screens. I have 10 AD groups that will act as roles for these applications, which I've imported into FIM, and the number will grow over time. I'm working on creating a UocIdentityPicker (let's call it roles) that will allow the admin to check a couple boxes to select the roles. What is the best way to then add the user to these group(s) in AD? How can I create sync rules, etc to do this? If I understand the answer to another question correctly, the person was suggesting that you make the groups criteria based. That isn't going to work for us, unless we create a set for every group and make those dynamic somehow. That's just not very feasible or practical. How can we use the values entered in roles to correspond to the actual group memberships in AD?

Why not just have the criteria for the group be the user's role attribute contains Foo?My Book - Active Directory, 4th Edition My Blog - www.briandesmond.com

That seems easy enough, but when I change a group to be criteria based, and give it a criteria of "roles contains FOO" (FOO being the actual group that I searched for), I get: System.InvalidOperationException: Filter definition is not permitted. How can I create that filter?

That seems easy enough, but when I change a group to be criteria based, and give it a criteria of "roles contains FOO" (FOO being the actual group that I searched for), I get: System.InvalidOperationException: Filter definition is not permitted. How can I create that filter? Go under Administration>Filter Permissions and add your "roles" attribute to the lists for administrator and non-admin (or just administrator if you don't want normal people to create these groups).My Book - Active Directory, 4th Edition My Blog - www.briandesmond.com

If I make the group criteria based, I won't be able to add users manually through Security Groups - add member, will I? Is there a way to allow both?

Correct. Make a manual group and nest the criteria group in it.My Book - Active Directory, 4th Edition My Blog - www.briandesmond.com

Would something like this work? I'm working right now with just FIMMA and ADMA. I'm using an UocIdentityPicker and allowing multiple items to be chosen - called RolesPicker. One of the RolesPicker options is an AD Group called FooUsersManual. In FIM we make this a manual group Create new criteria group in FIM, FooUsersCriteria, with a filter in the FIMMA so that we don't create this group in AD (Though we'd have to create a criteria group for every single group that would be accessed on the user's page.... by no means ideal as the list grows and grows) In user creation/update page, RolesPicker input adds the users to a FooUsersCriteria group OR, in Security Groups page, can add users directly to FooUsersManual FooUsersManual then includes FooUsersCriteria group as a member, plus any other manual members. Once the sync runs, the user would be added to FooUsersManual in AD. If FIM is the authoritative source (not AD), how would we make sure that the manually added role gets included in the user's RolesPicker object? Maybe a workflow on adding to the group, we somehow modify the user's Roles value to add another role? Or how can we keep this up to date with the user's actual role groups?

Does whatever will consume this not support nested groups? Your best bet to prevent certain groups from being created in AD is to modify your workflow that adds groups to the outbound sync rule so that those groups aren't provisioned.My Book - Active Directory, 4th Edition My Blog - www.briandesmond.com

It may support nested groups, but I'm not sure that we can guarantee that

It may support nested groups, but I'm not sure that we can guarantee that What I would do then is flip this around. Create the manual group but don't provision it to AD. For your criteria group, change it to: Select user that match ANY of...: * Resource ID is member of <manual group> * Role contains <fooRole>My Book - Active Directory, 4th Edition My Blog - www.briandesmond.com

That's certainly simpler to think about. That would get the right users into the right group in AD. I think all that leaves is making sure the members of groups in the Security Group page also have the group listed in their RolesPicker box. How can I do that?

That's certainly simpler to think about. That would get the right users into the right group in AD. I think all that leaves is making sure the members of groups in the Security Group page also have the group listed in their RolesPicker box. How can I do that? Not sure I follow. The RolesPicker box would be tied to their Roles attribute. The assumption is simply that any time that attribute changes, FIM will update the appropriate group memberships. Barring some sort of problem inside of FIM, it's safe to assume that the roles attribute directly correlates to group memberships.My Book - Active Directory, 4th Edition My Blog - www.briandesmond.com

Sorry, I'm still pretty new to FIM. If I have a RolesPicker object/attribute that then populates the group, I guess I'm just trying to figure out how to re-populate it with any groups added manually.

Sorry, I'm still pretty new to FIM. If I have a RolesPicker object/attribute that then populates the group, I guess I'm just trying to figure out how to re-populate it with any groups added manually. Oh... That's going to be difficult. Is there a reason you can't force the workflow to always be updating the user versus having two entry points (group or user)? Another work-around is I believe there's some sample RCDC code floating around to show a user's groups as a tab on their object in the portal.My Book - Active Directory, 4th Edition My Blog - www.briandesmond.com

Unfortunately we'll have enough picky users that they'll be wanting access like that before long so we're planning for it now. Could we create an extension to add it to the RolesPicker attribute? And actually, the admin would probably want to view the members of the group, but when they add a user manually, they wouldn't see all the members.

Unfortunately we'll have enough picky users that they'll be wanting access like that before long so we're planning for it now. Could we create an extension to add it to the RolesPicker attribute? And actually, the admin would probably want to view the members of the group, but when they add a user manually, they wouldn't see all the members. The way I'd do it is add a custom attribute to the group object which is the name of the role i maps to (or make it multivalued if multiple roles go to one group), and then have a WF activity fire when the membership for manual groups who have that attribute changes. Said activity can grab the user being added/removed and update the user's role attribute.My Book - Active Directory, 4th Edition My Blog - www.briandesmond.com

Given that the current path I'm taking seems to be causing a lot of potential problems, I'm revisiting having one Set per role/AD group, which would allow me to have both criteria and manual members. I am looking at this page: http://social.technet.microsoft.com/wiki/contents/articles/enterprise-roles-in-microsoft-forefront-identity-manager-2010-fim.aspx I'd like to follow something similar to this and create my own standalone roles in FIM. Is it possible to create a Role object, then give it a Set called membershipSet? How would I do that? So far I've created a Role object and bound a few text objects to it, but I'm not sure how to add a Set.

I figured that out by looking at the Set configs