Hi Everyone,

I am having troubles with FIM/AD group management. We currently have our environment setup so that groups are managed through FIM but only for user accounts. If we were to FIM manage a group that had admin users in it the admins would be stripped out on the next sync, this is due to their admin account not existing in the FIM portal. Is my solution to get the admin accounts into portal? If so what is the best way to do that?

We have two ADMA's one for users the other for admins each linking back to different OUs in AD. To create an admin account we check a box on a users FIM account, provisioning logic fires and the account is created in the admin OU. On the sync the admin account is joined to the appropriate MV object. I could setup projection logic to project into FIM portal however it would have to be a different resource type other than 'person'. This causes an issue with criteria base FIM managed groups because you can only base criteria off of one resource type. For instance our department shares are all managed through FIM, the criteria being "Select 'User' that match all of the following conditions" You can do "Select 'User' and 'Admin' that match all of the following conditions".

This leads me to believe that the admin accounts would need to project as 'people' within portal. However this is not possible, due to their regular accounts already being joined to a 'person' objects, if I'm not mistaken.

One way is to have a nested group in AD for users, which is managed by FIM and add that to the main group. This way the parent has Admin Users and the nested group made from person users.

Example:

Group A  = Parent

Group B = Member of Group A

User 1, User 2, User 3 = Members of group B

Admin1, Admin2, Admin3= Members of Group A

Beside your problem with the two object types of admins and regular users you face another problem with your design having two MAs for Active Directory user accounts. The reason is you cannot sync Groups in one MA and possible Group member in a second MA. Groups and their member must be synced using a single MA.

Henry

Henry is right that referential integrity means you must have all of the members of group in the same MA as is managing the group's membership

That's a great point, I hadn't thought of. It's starting to sound like I may not to be able to do this the way we want then. We have to have the two MA's for password syncronization between our accounts. Is the best way to handle this the way Nosh described above?

Hi again

in the early days of MIIS / ILM and now FIM (soon MIM) there was an alternative way available which still can be applied: Group Populator. The solution is easy to implement, can be modified by your Needs because the source code ist available and it is really fast.

Using the "Group Populator" you can define your Group Membership based on every piece of Information available in your Metaverse. The concept and the solution framework can still be downloaded in the "Microsoft Identity and Access Management Series"

http://www.microsoft.com/en-us/download/confirmation.aspx?id=17974

There was also a simple GUI available for the Group criteria management: http://crosbysite.blogspot.de/2008/02/using-group-populator-application-with.html 

Henry

I don't really see how anyone who has FIM Portal CALs would want to use Group Populator, but it is certainly an option.

Hello,

I have the same situation at one customer, but not only with admin accounts.

There are at least some other account types which are also member of groups where normal users belong to.

So I ended up putting them all into portal but seperate them with a attribute "UserClass" and modify some of the resource like sets, searchscopes and so on to only display the relevant users to different audiences.

This attribute is set based on the OU the user belongs to.

There is no problem to have normal and admin accounts of the same user in portal, beside that it need a CAL

/Peter

I suggested GroupPopulator not to avoid CAL licenses but to achieve a dynamic Group solution without the need to change the concept of two different object types Donald uses so far.

I agree with you and Peter to choose FIM Portal in all other cases where Information is available in the Portal to create filter for Group membership.

Henry

A few years back I was presented with a customer that needed to manage Admin accounts, service accounts, test accounts and application accounts (stuff that apps use but doesn't need run as a service right, maybe batch but not service).

So we created a new object type for special accounts. On it we has an account type attribute (we also put this attribute on the person object). Every special account had to be owned by a standard Person (in fact for some account types it had to be an active FTE). Based on the account type we had some different rules. In order to more easily manage the group memberships we used MPRs sets and workflows to automatically create person objects (that couldn't be edited directly). We had a separate AD MA for provisioning the special accounts. But the person object for the special accounts would join up to the user that was imported through the standard AD MA. This allowed for clean group management.

Your other approach is to manage group membership as an attribute of the user and use a PowerShell MA or something like it to simply add and remove members of a group rather than manage the entire membership in a group.