locked
dynamic object type conversion RRS feed

  • Question

  • Hi,

     

    I'm running into situation where I need to change object type in my target AD forest when user object is moved in the source AD forest.  Here is the simplified scenario:

    1.  Source forest has OU "A" and OU "B"

    2.  All user objects in OU "A" are provisioned as users into "Users" OU in the Target forest

    3.  All user objects in OU "B" are provisioned as contacts into "Contacts" OU in the Target forest

    4. When user is moved in Source forest from OU "A" to OU "B", I need user object in the Target forest to convert to  

        contact object and be moved to "Contacts" OU.

    5. When user is moved in Source forest from OU "B" to OU "A", I need contact object in the Target forest to convert

        to user object and be moved to "Users" OU.

     

    Can anyone suggest a good approach to this scenario?  Any help is greatly appreciated

     

    Best Regards,

    Roman

    Wednesday, November 12, 2008 4:42 PM

Answers

  • In your provisioning code examine the state of your metaverse object.

     

    Do you have a connector in the source MA in OU A and a connector in the Target that is a Contact if so deprovision the Contact record and provision a user object to the Target MA. If no connector in the Target then provision a user to the Target MA.

     

    Do you have a connector in the source MA in OU B and a connector in the Target that is a User if so deprovision the User object and provision a Contact object. If no connector in the Target then provision a Contact.

     

    This assumes that you set the the deprovision option on the Target to Delete on next export.

     

     

    Wednesday, November 12, 2008 5:28 PM
  • Yep, you need two sync runs because you need the confirmation of the deletion from AD.

    Theoretically, you could also do this in one sync run (deprovision the user and provision the contact).

    However, this is not really a best practice since there are a lot of things that can go wrong with a staged deletion in a connector space.

     

    You need the operational attribute to enable your provisioning code to make a decision. It is in general a good idea to have some state related information attached to an object.

     

    If something goes wrong, you have at least in case of a troubleshooting scenario a chance to figure out how it should be and compare this with the “is-“ state.

     

    You could of course just flow the source DN into the MV.

    I’m usually suggesting a bit vector. You can find more details on this in Provisioning based on Group Membership.

    However, you can always scale your implementation down…

     

    Cheers,

    Markus

     

    ///////////////////////////////////////////////////////////////////////
    Markus Vilcinskas

    Technical Writer
    Microsoft Identity Integration Server
    mailto:markvi@microsoft.com.NO_SPAM

    This posting is provided "AS IS" with no warranties, and confers no rights.
    Use of included script samples are subject to the terms specified at
    http://www.microsoft.com/info/copyright.htm
    ///////////////////////////////////////////////////////////////////////

     

    Wednesday, November 12, 2008 8:55 PM
    Moderator

All replies

  • In your provisioning code examine the state of your metaverse object.

     

    Do you have a connector in the source MA in OU A and a connector in the Target that is a Contact if so deprovision the Contact record and provision a user object to the Target MA. If no connector in the Target then provision a user to the Target MA.

     

    Do you have a connector in the source MA in OU B and a connector in the Target that is a User if so deprovision the User object and provision a Contact object. If no connector in the Target then provision a Contact.

     

    This assumes that you set the the deprovision option on the Target to Delete on next export.

     

     

    Wednesday, November 12, 2008 5:28 PM
  •  

    When you detect the requirement on the inbound side, you should flow an operational attribute into the metaverse.

    As a first step, deprovision the user object and stage a deletion.

    When you process the deletion of the user object from the ADMA side, you should add code to your provisioning method, that evaluates the connectors and your operational attribute in the metaverse.

     

    If the attribute is set, and the AD user connector is missing, provision a new contact objects.

     

    Key is to split this operation into two separate operations. You can’t change object types in AD. So, you would have to delete the user and as soon as you have confirmation for the user deletion, create a contact.

     

    Just as a side note, please keep in mind that deletions in AD are destructive. It might be more advisable to move the user into a separate container as disabled object and to create the contact when the disabled user state has been imported from AD.

     

     

    Cheers,

    Markus

     

    ///////////////////////////////////////////////////////////////////////
    Markus Vilcinskas

    Technical Writer
    Microsoft Identity Integration Server
    mailto:markvi@microsoft.com.NO_SPAM

    This posting is provided "AS IS" with no warranties, and confers no rights.
    Use of included script samples are subject to the terms specified at
    http://www.microsoft.com/info/copyright.htm
    ///////////////////////////////////////////////////////////////////////

     

    Wednesday, November 12, 2008 7:22 PM
    Moderator
  • Thanks Markus! 

    Deletion confirmation means I need to do import from the target AD.  Does this mean that the process would require 2 synchronization runs to complete?  One to deprovision the object and second to create a new one? 

     

    Also, is operational attribute really neceserry?  If I jump out of the provisioning code right after the deprovision, with the next synchronization the new object will be provisioned anyway.  Correct?

     

    Best Regards,

    Roman

    Wednesday, November 12, 2008 8:32 PM
  • Yep, you need two sync runs because you need the confirmation of the deletion from AD.

    Theoretically, you could also do this in one sync run (deprovision the user and provision the contact).

    However, this is not really a best practice since there are a lot of things that can go wrong with a staged deletion in a connector space.

     

    You need the operational attribute to enable your provisioning code to make a decision. It is in general a good idea to have some state related information attached to an object.

     

    If something goes wrong, you have at least in case of a troubleshooting scenario a chance to figure out how it should be and compare this with the “is-“ state.

     

    You could of course just flow the source DN into the MV.

    I’m usually suggesting a bit vector. You can find more details on this in Provisioning based on Group Membership.

    However, you can always scale your implementation down…

     

    Cheers,

    Markus

     

    ///////////////////////////////////////////////////////////////////////
    Markus Vilcinskas

    Technical Writer
    Microsoft Identity Integration Server
    mailto:markvi@microsoft.com.NO_SPAM

    This posting is provided "AS IS" with no warranties, and confers no rights.
    Use of included script samples are subject to the terms specified at
    http://www.microsoft.com/info/copyright.htm
    ///////////////////////////////////////////////////////////////////////

     

    Wednesday, November 12, 2008 8:55 PM
    Moderator
  • Markus and David, Thank you for your help!!

     

    Wednesday, November 12, 2008 9:22 PM