An Intro to Joins

Joining 101

A join is a connection between a metaverse object and a connector space object.

• Joined CS objects are called “Connectors”,
• Unjoined CS objects are called “Disconnectors”.

Multiple relationships are permitted in one direction:

• A single metaverse object can be joined to multiple CS objects,
• However a single CS object cannot be joined to multiple metaverse objects.

If you don’t want multiple joins you need to check for it in code – more on that in subsequent posts.

Get them right

Joins are fundamental to ILM. They are the fabric over which the data flows. Get them wrong and things can go weirdly astray – attributes going to the wrong place, passwords updated in the wrong account, rubbish being allowed to hang around because it’s joined to something, even though that something is not at all relevant… So it’s worth spending some time thinking about getting your joins right.

A New Directory

Lucky you if you’ve got a brand new directory to manage. You don’t need to worry about existing objects – ILM will create everything. So do you need join rules?

Yes you do. Always plan to be able to clear out the connector space and re-import. Add suitable join rules to your MA so the objects can re-join automatically.

An Existing Directory

Now this is far more likely. The directory already exists, and has been managed for some time by other methods. You are now asked to take over object updating and object creation. Before you can even look at provisioning, you must get an idea of what is there already. And the way to do this is by joining as many objects to the metaverse as possible.

I suggest these general steps:

1. Make a clear distinction in the connected data source (CDS) between what ILM will manage and what it will not. In the case of user objects in AD, you may propose a new “Unmanaged” OU for those user objects which ILM will not touch, and then exclude it from the view of the MA. Strenuously avoid any kind of shared management proposals, like “we want ILM to create users, but we also want to create them manually in the same OU“; “we want ILM to manage these groups, but we still want to manually add members”. The correct answer to these proposals is “bugger off”, though there may possibly be nicer ways to say that.
2. Only project objects into the metaverse from an authoritative identity source, such as an HR database. It is usually a bad idea to project from a mature data source such as an existing AD, where there are likely to be old accounts, test accounts, and other rubbish that you don’t want in your metaverse.
3. Try and get as many objects joined as you can using join rules.
4. Use the Joiner tool to manually join as many remaining objects as you can.
5. Use csexport, from the MIIS Resource Kit, to list the disconnected objects remaining in the CS. Go through the tedious process of figuring out what should be joined, what can be deleted, and what can’t be joined or deleted – these latter objects should be moved to an Unmanaged location in the CDS or, at an absolute minimum, tagged somehow as “Unmanaged” and thereafter filtered out by the MA.
6. Hopefully get to the point where Disconnectors=0 in your CS!

Why all this fuss about Disconnectors?

I’m no tidyness freak (trust me, if it wasn’t for my lovely cleaner my house would be in a right state), but I do believe in putting in the extra work now to save myself trouble down the track. Random disconnectors may well cause trouble:

• You can’t control username uniqueness. A username may be perfectly acceptable to your provisioning code, and you’ll only find out that it’s already in use when your MA fails to export the object.
• People start to get used to ILM managing the objects and want to know why it’s “not working properly” because it didn’t delete or update particular examples. Although of course it is working properly, it just can’t manage what it’s never connected to.
• You risk a random, disconnected CS object becoming joined to a metaverse object, thus messing up flow rules, password sync, and preventing the correct object being provisioned.

And the rest…

I had originally thought to write one “all you ever wanted to know about joins” type post, but it turns out there’s quite a lot to say. More posts will follow on advanced (coded) join rules, and some specific scenarios.