Thursday, January 17, 2008 4:44 PM
If you found this, then you know I'm talking about Microsoft Identity Integration Server (MIIS) / Identity Lifecycle Manager (ILM). A reverse join is a concept that attempts to solve problems arising from joining existing connector space objects to newly created metaverse objects. Microsoft has a great white paper on the subject.
I discovered that I might care about this subject because I couldn't get a few unit tests to pass. I had unit tests covering two inactivation scenarios. The tests followed two accounts (User A, User B) over 3 synchronization cycles. The first cycle provisioned the accounts. The second cycle inactivated them. The third cycle 'brought them back to life'. My tests correspond with what you'd expect: Assert the AD account is there and active, assert the AD account is disabled, assert the AD account is active. User A was inactivated with a status change and was correctly covered by deprovisioning actions with passing tests. User B, however, gave me a fit. User B was deleted (effectively deleted, I simply filtered out her account before the connector space import) before cycle 2 as part of the test fixture setup, deferring to object deletion rules. Her AD account was correctly disabled after cycle 2. So far, so good. However, when I brought her 'back to life' by removing the filter, I received provisioning errors about existing duplicate objects, exactly as outlined in the microsoft whitepaper.
The whitepaper, although lacking in implementation details, does a great job contrasting 2 practical approaches to this problem using reverse joins. One, using transient provisioning is simpler, but it smacks you with a sinking stomach feeling because you are PURPOSEFULLY CREATING DUPLICATE CONNECTOR SPACE OBJECTS! The other, reverse joins with auxillary management agents, has been posted about by Craig Martin. I was at first more interested in this approach because it sounds elegant but also very complex. I despise complexity so much that I gave the other approach some more thought. Glad I did, because it turns out to be valid, robust, and as easy as this:
1. Run profiles must be run in an exact order, where at least a delta synchronization is performed on the CS before export
2. Add this code to your provisioning block, testing the condition of more than one connectors:
ElseIf numConnectors > 1 Then
Dim connector As CSEntry
For Each connector In activeDirectoryManagementAgent.Connectors
If connector.ConnectionRule = RuleType.Provisioning Then connector.Deprovision()
Next
End If
If you're interested, read my blog entry about unit testing identity management solutions.
Cheers!
Thomas