FIM 2010–Issues Setting DN Values using Calculated Strings

A colleague of mine was recently working on a problem where he wanted to create a DN in the declarative synchronization rules by using a string attribute value in the metaverse. The string value was created in the FIM Service by a workflow and imported into the metaverse via the FIM MA where the synchronization rule then used it.  This worked fine for the initial flow only rules and therefore seemed seemed pretty straight-forward when he set up the persistent flow so that accounts could be dynamically renamed. That said, the persistent flow failed and wouldn’t perform the rename as expected. It was a rather curious error and to him quite frustrating. The detailed situation he had was this:

A workflow was setup that built a DN string that was put into a FIM attribute. This attribute was then imported into the Metaverse. The workflow did everything including the escaping of the “,” in the RDN component. An example of the the string, a fully defined FQDN, was similar to “CN=Checkley\, Blain, OU=Users, DC=Happyface, DC=inc”.

The synchronization rules were set so that the attribute value in the MV attribute was used for the DN. So it was a pretty simple rule that was used for both the initial flow and persistent flows (where adFqdn is the attribute that stores the calculated string imported from FIM):

adFqdn => dn

Interestingly enough, although it worked fine for the initial flow only and the entry got created but the rename, which should have been seen as part of the provisioning section of the preview, didn’t occur when the persistent flow would be called. It simply tried to map an attribute value to DN when it did the attribute flows which didn’t work.

By modifying the code a bit so the workflow generated the Target OU and the RDN being explicitly defined and escaped using the “EscapeDNComponent” worked and the renames occurred correctly. The completed flow rule in this case that worked was (as before, adTargetOU is the calcuated OU string in the MV that was generated by and imported from the FIM Service):

CustomExpression(EscapeDnComponent(“CN=” + displayName) + “,” + adTargetOU => dn

Hope this helps anyone who may have run into a similar situation. Appears that having the DN as a string is fine for the initial flow rules however, you have to more explicitly show the system it is a DN for it to do the renames as part of the persistent flow.

This entry was posted in Forefront Identity Manager 2010. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s