• 2 replies
  • Latest Post - ‏2018-06-15T21:40:22Z by yn2000
4 Posts

Pinned topic Itim 5.1 AD Recon

‏2018-06-15T03:11:44Z | itim5.1
I'm reaching out if i can get some assistance on itim 5.1 AD Adapter customization.
there is requirement to recon the AD objectGuid attribute  into itim.
i have opened the ADprofile and updated the following:
<!-- ******************************************************** -->
        <!-- -->
        <!-- ******************************************************** -->
        <attribute-type single-value="true">
            <description>Allow erADObjectGuid</description>
The erADAccount class is updated with
<attribute ref="erADObjectGuid" required="false"/>
erADAccount.xml is updated with
<formElement direction="inherit" label="$erADObjectGuid" name="data.erADObjectGuid">
          <input type="text" size="50" name="data.erADObjectGuid"/>
        </formElement> is updated.
The profile imports Ok into itim and i can see the attribute on the account form using the designer applet. The provisioning policy is updated to read  this attribute.
However , the issue is the following:
1: The existing account form does not show the new erADObjectGuid  input even though i see the input from the account designer applet.
2: The avialable recon attributes under run recon page does not show the new erADObjectGuid attribute.
Why did ibm not include this attribute in the adapter schema ?
Is there a best practice steps for doing something  like this ?
The adapter documentation has very little on this.
  • franzw
    501 Posts

    Re: Itim 5.1 AD Recon


    If I remember correct you need to a extension file exschema.txt in the adapter data directory...

    This is definitely documented in the adapter installation guide :



    Franz Wolfhagen

  • yn2000
    1133 Posts

    Re: Itim 5.1 AD Recon


    Why did ibm not include this attribute in the adapter schema?

    Short Answer:
    Why would anybody use objectGuid in the AD adapter?

    Long Answer:
    objectGuid is generated by AD system and it is not a value that you can 'provision'. You use objectGuid externally (outside of AD) only when AD be the source/authoritative data, so that it can provide a more consistent link to other external repositories. In addition, to use objectGuid externally, most people translate the original hexadecimal value with a translator script to make a string and that script has to be used consistently on all of target repositories.

    In the other hand, AD adapter is a translator of a provisioning request from TIM to AD, which is part of the whole TIM 'provisioning' processes. Just a reminder, 'provisioning' means creating, updating, and deleting data into the target. So, in the world of AD adapter, TIM is the source and AD is the target, not the other way around. Yes, TIM introduces a reconciliation process, but the main objective of the reconciliation process is to check which attribute violate the 'provisioning policy', so that TIM can correct (or mark/suspend) it, while, as mentioned, objectGuid is an attribute that cannot be corrected.

    Yes, I use objectGuid for many things, including with TIM, but I use it to link data into the TIM datafeed process, and definitely I never use it in the AD adapter. In other words, the design to put objectGuid value in the TIM Account entity (in the back of TIM via AD Adapter) instead of in the TIM Person entity (in the front of TIM via TIM datafeed) just for a display, which can only displaying the translated value, is a very questionable move.

    So, why would anybody use objectGuid in the AD adapter?

    Rgds. YN.