I need a join rule for AD groups. We have existing Ad groups I need to join with and we don't have the samaccountname available in our mgirated data (data in fim, pre initialisation). Ideally I'd like to join on the DN using a rules extension, but I can't get the DN as an attribute from AD. This is either an AD or Sync Engine limitation? The MS documentation: http://social.technet.microsoft.com/Forums/en/ilm2/thread/f09bc7d6-8a0f-484d-9038-1b54d8457e91 Says to join on samaccountname, which we are doing for users, but we can't do for groups as we don't have this attribute in the MV entities. The long way round to this is to try and get the samaccountname into our migrated data somehow so we can do that join, but I'm looking for a way to join on the DN. Does anyone know if this is possible? Unfortunately the data-migration process wasn't done with a proper FIM analysis so we didn't see this coming and we have trouble passing all the data we want through the migration process... I know, I know...

Hi Amethi, You say that the "long way" is getting the sAMAccountName in the FIM data, but if you have somehow the dn in FIM, wouldn't it be possible to recover the account names from AD with a script? Something like For each group in FIM: - read group information from FIM - determine dn of group in AD - get samaccountname from AD - set samaccountname for group in FIM Then you would just need to import the updated data and join on the account name. Is this feasible for you? Cheers, Paolo Paolo Tedesco - http://cern.ch/idm

It's a good suggestion, thanks Paolo, though it means I have to add another stage to my migration process, not quite ideal. Though I'm coming to the conclusion that I really am going to have to have the samaccountname in FIM from the very beginning so everything joins up as recommended. Actually, I've just thought how I could do it, and it might not be as difficult as I thought. The way we do the migration process is like this: Goal: All entities need to be in FIM first as there are no inbound sync rules to get existing data from CD's to MV. Solution: Insert all entities from CD's to FIM via web-services so they join-up when FIM is initialised. I can just add another phase into this web-services app that queries AD for the samaccountname and puts it into FIM. Thanks :)

Wouldn't it be even easier to declare some migration-only inbound sync rules? You use them just for the migration process, then delete them. You just have to pay attention to the MV attribute precedence, but it's probably much easier (and possibly also less error prone)... Cheers, PaoloPaolo Tedesco - http://cern.ch/idm

You would think so :) But no, our data comes in from an extensible management agent, so that would need a new version developing and then the sync rules are quite complex. It would have been too much effort. The application to load entities into FIM via web-services is really quite simple and didn't take long to develop. We'll be bringing one country onboard to fim every month for two years, so the data-loader application approach is easier to manage for us as well. Though the problem I have encountered with this is that the FIM schema is not really a schema at all as it does not allow you to define constraints, i.e. uniqueness validators. This has to be done in RCDC, but if I'm putting entities in via web-services these aren't used obviously, so it is possible to put invalid data into FIM, i.e. duplicate users. This is annoying and means I have to build in schema validation into this external application(!).

You would think so :) :D But no, our data comes in from an extensible management agent, so that would need a new version developing and then the sync rules are quite complex. It would have been too much effort. The application to load entities into FIM via web-services is really quite simple and didn't take long to develop. We'll be bringing one country onboard to fim every month for two years, so the data-loader application approach is easier to manage for us as well. Though the problem I have encountered with this is that the FIM schema is not really a schema at all as it does not allow you to define constraints, i.e. uniqueness validators. This has to be done in RCDC, but if I'm putting entities in via web-services these aren't used obviously, so it is possible to put invalid data into FIM, i.e. duplicate users. This is annoying and means I have to build in schema validation into this external application(!). Defining uniqueness constraints is a feature that I would have liked as well. An alternative to the unique validation in the application could be building a custom authorization workflow to check for duplicate values... Ciao, PaoloPaolo Tedesco - http://cern.ch/idm

Yes, that's an idea... though I don't know if FIM would process the authorisation workflow and fail the web-service call if it failed, or if it would return a success to the web-service call and then reject the entity creation after it had run the workflow. I hope it would run it and then return, not the other way around.

If you are using the public client (http://fim2010client.codeplex.com/) you will get an exception of type System.ServiceModel.FaultException<Microsoft.ResourceManagement.Client.Faults.AuthorizationRequiredFault>, which basically means that there is a pending authorization for the request. At that point you should probably query the Request objects to find which one has the object you just tried to create as a target... The bottom line is that verifying uniqueness in the application is probably easier :) Ciao, PaoloPaolo Tedesco - http://cern.ch/idm