As an introduction, FIM2010 comes with an out of the box management agent that is able to synchronize with SUN Directory Services. Although when using SUN DS 6.x you first have to set the correct version of the SUN DS system into the registry of the machine that hosts the FIM Sync service to prevent from running into a “Unknown Server Version” when performing an export or import. For FIM 2010 the key is called iPlanetMASupportedServers and is located in HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\FIMSynchronizationService\Parameters I won’t go into more detail about that here because you can read all about this on several other blogs and TechNet.
In most cases the sync to SUN DS is pretty straightforward. You enter the details of your SUN DS server, use a SUN account that has the appropriate privileges and start flowing attributes. But, as with many directory services solutions you are able to extend the schema that is used on SUN DS to store extra attributes on for example the group object. When extending the schema in SUN DS, SUN DS want you to create an extra objectclass and then create a “parent-child” relationship between the to be extended objectclass and the new objectclass. Although it might seem like a logical choice to select the objectclass type that you want to extend as the parent, in some customer environments you might find that the objectclass “top” is chosen as the parent. You can do so without any harm because there is also an attribute “objectclasses” which is mandatory and allows you to specify all the objectclasses during the creation of an object when you for example manually create an object.
But how does FIM handle this situation?
After you extended the schema in SUN you replicate the new schema changes using your SUN Management agent in FIM and you’re ready to go. But! Since the attributes are now actually spread over two separate objectsclass types in SUN we run into an issue when using a Synchronizationrule in the FIM Portal. A sync rule in the FIM portal lets us flow attributes to and from an external systems, in order to do this FIM wants you to specify the MetaVerse resource type, and the external system resource type. That raises the question what resource type do we select for the external system because we now have the option to either select the actual SUN DS Group objectclass OR the newly created objectclass (the so called child). J And as you might have guessed, FIM can’t know about the relationship because “top” was defined as the parent in this example environment, so when we select the actual SUN DS Group objectclass we can only flow the attributes that exist within that objectclass, the attributes of the objecttype that we created for the extension are of course not included. And, when we select the newly created objectclass type we can only flow attributes from that objectclass. Sound like a chicken-and-egg problem doesn’t it?
You could, of course, define 2 synchronization rules, one that flows the attributes of the actual SUN DS Group objectclass, and one that flows the attributes of the newly created objectclass type. But since you don’t have the attributes available of the parent when flowing to that newly created objectclass type, you (usually) don’t have an attribute available to build the relationship upon. Another solution would be to use an ECMA to build your own customized SUN DS MA, but that doesn’t make much sense since the MA for SUN DS is available out of the box. A solution would be (and I think should be) to define the actual SUN DS Group objectclass type as the parent for the newly created objectclass. This seemed the more logical choice from start anyway. In that case we can select the newly created objectclass as the source on the synchronization rule and still have the attributes available that were defined on the extended attribute class.
The lesson here: Watch the (custom) objecttype classes and their relationship closely when flowing attributes to your SUN DS environment!
No comments:
Post a Comment