Can the Placeholder Connector be used to generate the "back-link" memberOf attribute for a user based on group.member

A common FIM requirement is to be able to provision users based on membership of an AD group. For FIM to be able to do this OOTB would be required that it was possible to define a SET based on the (derived or explicit) ComputedMember collection of a group, but as of a recent FIM build this is now not possible.

In the following thread, Markus Vilcinskas (moderator of the ILM and FIM forums on TechNet) suggests a solution designed to work around this shortcoming: http://social.technet.microsoft.com/Forums/en-US/ilm2/thread/a8f5ecea-7375-48da-a920-e4bcea87bba3?prof=required

... and in this thread on the same subject I pointed out that the post marked as an answer to the problem is no longer valid: http://social.technet.microsoft.com/Forums/en-US/ilm2/thread/e6661c08-3747-4c99-bb1a-cbba75b89726

At NAB this requirement was satisfied using a custom activity (written by Paul Williams, MVP) prior to UNIFY involvement in the account.

In the end, all of the above mechanisms are really just complicated work-arounds and leave you asking the question ... surely there's a better way?

I am thinking that we could promote the use of the Identity Broker Placeholder Connector to write out both group and user objects with the group.member relationship, and "reflect back" (via a Group.Relation.dn transformation) the "back-link" user.memberOf collection (which confuses everyone when they first see this collection in AD only to find that the memberOf attribute isn't "real" but calculated in AD). The benefit of this approach would be that we could "black box" this solution (it is 100% generic) and it would provide superior performance and simplicity over any of the suggested work-arounds above, especially leveraging the intrinsic delta import capability of Identity Broker which would translate changes to group.member into changes to user.memberOf.

Firstly, can someone confirm that the above configuration will work the way I have described, and secondly (if the assumption is correct) what would it take to package this solution (IdB 3.*, Placeholder Connector, IdB for FIM, pre-generated MA configuration) as a salable commodity to the FIM world?

I am thinking that Peter Wass may have done something like this in the past, but at the time wasn't thinking of how it could apply to this dilemma. Note that this is a special case where the authoritative source of the group.member change is the AD MA. If we had our own Identity Broker for Active Directory MA then we wouldn't need to worry about the Placeholder connector, and could provide this feature OOTB. That might be an even more appealing option, but in the meantime I'm thinking that the only thing stopping the Placeholder Connector option from being a reality is UNIFY buy-in, followed by packaging and marketing ...