String to relational DN export flows

Thanks to Joe Stepongzi for pointing this one out to me: you can flow a metaverse string attribute direct to a connector space relational DN attribute, as long as the metaverse string holds a valid DN.

This is particularly useful in group population. My usual method uses relational DN attributes the whole way through, from importing CS to metaverse to exporting CS. To construct the rDNs, each CS must hold objects representing every possible group member. Get a few groups with 10,000+ members, and you may soon have hundreds of thousands of objects in your CS … and I won’t need to tell you what that does to your sync times and your transaction log.

So, it turns out, you can at least reduce the pain for one half of the equation.

Importing CS   Metaverse   Exporting CS
String attribute → String attribute → rDN attribute

Now the big hurdle here is that you need to get hold of those DN strings in the first place, and have confidence that they are correct. I overcome with another SQL MA that exports the DN to a table. I then have some SQL trickery going on in the background to generate a table of member lists with the ready-made DNs.

This has been particularly useful in a multi-forest implementation where I needed to populate some groups with Foreign Security Objects from another forest. The FSO takes the form of a DN which I constructed from the foreign SSID, and then by using this method I was able to put them into groups.

Now according to Joe there is another half to this equation where you can also effectively output a group composed of string DN members to AD – however you can’t use the native AD MA, you have to use an XMA and LDIF files. This method has several notable benefits:

  • LDIF allows you to add and remove individual group members – you don’t have to repopulate the entire group,
  • As you’re no longer dealing with reference DN attributes in the exporting MA, you won’t need all those thousands of placeholder objects representing the members, which leads directly to
  • Drastically reduced sync times and goodbye to nightmare transaction log scenarios!

However I haven’t had an opportunity to try this out yet. If and when I do I shall return to the subject with more details.