Auxiliary Classes/Attributes within an LDAP Directory are not written to target

I've connected an LDAP Directory which syncs correctly with the standard attributes. But the auxiliary attributes are not written back to the target System. Even with the target System browser from within the synchronization Editor the auxiliary attributes are not written back to the System. I've connected d1im v7.1 (current Version) with the same user as we had before with the v6.1.2 Version. Therefore I guess it can't be an Access Problem. To I miss something concerning auxiliary attributes/classes and an LDAP Directory?

Thanks in advance

  • For the auxiliary attributes needs to be created a custom mapping. Check the mapping for the class and add the wanted attributes to the mapping.
    For more help please see the documentation:

  • In reply to Tomi Kääriäinen:

    Thanks for your answer, but the mapping is not the Problem. This part I did according the manual already. The problem is, that they are not written to the target System, neither with an adHoc Projection nor directly with the integrated Target System browser which you can start from within the SyncEditor (Tab: Configuration -> Target System -> Browse...).

    From the target system browser, a standard attribute is written immediately to the directory. If I change an attribute which is assigned via an auxiliary class, then this attribute is not updated in the directory.
  • In reply to rolf.joggi:

    You are right. I started investigating the issue as you said the property is not even updated through the target system browser. Principally it works. I just tested it.
    The problem might be in the LDAP system. Please create a support case and give the details of your LDAP system the used schema and the attributes used.
  • Hi Rolf,

    Is the auxiliary class listed in the list of objectclasses in the objectclass attribute? If you set/update an attribute that is part of an auxiliary objectclass, the objectclass must be listed otherwise the update will be discarded.

  • In reply to Barry Jackson:

    Thanks Barry. This did the trick.
  • I just went through this myself and even though we hard-coded the aux objectclass in the value template and added it to the list it was still error'ing out (saying objectclass did not exist). This is for anybody else reading this solution (which works)...make sure you keep upper case on both objectclass and structuralobjectclass attributes, yes the case matters for this! =)
  • In reply to Barry Jackson:


    I've ran into the same problem to where all of the fields from auxiliary classes are showing and properly mapped, however, none of them would sync to the target system. I've read Barry's post, but I am confused as to where I need to list the objectclass, does anyone have an example they don't mind sharing? The way I understood is that on the TargetSystem config under 'Schema classes' I need to create a filter and list all of the auxiliary class names, I've tried doing something like this StructuralObjectClass = myAuxClass1 or StructuralObjectClass = myAuxClass2, but that didn't work. Is my syntax bad or am I completely in the wrong area trying to do this?

  • In reply to sshvets:

    Hi Sergei,

    The auxiliary objectclass needs to be listed in the multi-valued attribute 'ObjectClass@LDAPAccount'.

    So you might have:

    PERSON (Structural)
    MYPERSON (Auxiliary)

    If 'MYPERSON' is NOT listed as one of the values of 'ObjectClass@LDAPAccount' ..... all updates to attributes of MYPERSON will be discarded.

    You don't need to do anything in the sync project/editor to get this to work.

    HTH, Barry.