none
eDirectory auxiliary class sync problem RRS feed

  • Question

  • Hello guys,

    I am trying to sync objects from eDirectory 8.8.5. Everything works fine, I map inetOrgPerson objects to person objects. I discovered if an inetOrgPerson object has an auxiliary class attached in eDirectory it does not get synchronized into the connector space. In case it is referenced by another user or group, a placeholder object is created.

    When I remove the auxiliary class, the object gets synchronized fine.

    Is there a solution/workaround?

    I believe I have the latest hotfix rollup installed, 4.1.3599.0

    Thanks,
    Csaba


    Csaba

    Thursday, February 26, 2015 10:50 AM

Answers

  • Unfortunately we did not have the time to wait for Microsoft support to investigate and fix this, so we looked for a workaround.

    The workaround was to recreate the auxiliary class and instead of specifying inetOrgPerson as SUPerior class we used organizationalPerson. This way FIM detected the objectClass correctly and did not exclude.

    To preserve the attributes we used a temporary class and ldapmodify magic.

    Hope this helps.


    Csaba

    • Marked as answer by Csaba Varszegi Wednesday, August 26, 2015 8:05 AM
    Wednesday, August 26, 2015 8:05 AM

All replies

  • I was wrong, the latest hotfix rollup for FIM 2010 R2 SP1 is 4.1.3627.0. Unfortunately installing the latest update did not fix my problem.

    Csaba

    Thursday, February 26, 2015 11:40 AM
  • I've managed to this using something like this

    void IMVSynchronization.Provision (MVEntry mventry)
    {
        ConnectedMA ManagementAgent;
        int Connectors;
        CSEntry csentry;
        ValueCollection vcObjecClass;
        
        ManagementAgent = mventry.ConnectedMAs["Some Management Agent"];
        Connectors = ManagementAgent.Connectors.Count;
        
        if(1 == Connectors)
        {
    
            // Use the existing connector.
            csentry = ManagementAgent.Connectors.ByIndex[0];
            
            // Convert the existing ObjectClass entries to a string array.
            vcObjecClass = Utils.ValueCollection(csentry.ObjectClass.ToStringArray());
            
            // Add the auxiliary class to the string array and then
            // set the ObjectClass to the modified string array.
            vcObjecClass.Add("new-aux-class");
            csentry.ObjectClass= vcObjecClass;
        }
    }

    How to: Change the ObjectClass Property

    Thursday, February 26, 2015 3:05 PM
  • Hi,

    Can you please give me more details? As I see this is an MV extension. At the moment I have my placeholders in the connector space, no corresponding MV object as this MA would project to the metaverse.

    Thanks,
    Csaba


    Csaba


    Thursday, February 26, 2015 3:37 PM
  • Oops, sorry. I read your question too quickly, because I have had that problem. I haven't had your problem but will post if anything comes to mind.

    Thursday, February 26, 2015 4:10 PM
  • I turned on verbose logging and I see "Entry excluded by object class: <dn>"
    "Entry #1 in batch filtered out."

    Few lines above it says "CLDAPObjectClassFilter::ComputePrimaryObjectClass."
    "CLDAPObjectClassFilter::FindOCInfo(name=inetOrgPerson)"
    "CLDAPObjectClassFilter::FindOCInfo(name=organizationalPerson)"
    "CLDAPObjectClassFilter::FindOCInfo(name=person)"
    "CLDAPObjectClassFilter::FindOCInfo(name=top)"
    "CLDAPObjectClassFilter::FindOCInfo(name=ndsLoginProperties)"
    "CLDAPObjectClassFilter::FindOCInfo(name=theauxclass)"


    Csaba

    Wednesday, March 4, 2015 4:51 PM
  • Which Management Agent are you using to connect to eDirectory? While creating a generic LDAP ECMA, I needed to specify all of the various classes associated with an object otherwise it was filtered out. Granted this is specific to my implementation.  However, I would suspect it has to do with how objects are being mapped in the Management Agent configuration.

    If given the option with your management agent, you might try adding an additional mapping such as shown in the image.

    -Jason

    Wednesday, March 4, 2015 8:26 PM
  • Csaba, so you import objects from eDirectory into the eDirectory MA's CS. When you search the CS, can you see these attributes (the ones attached to the auxiliary object class)? Might also be worth trying the Generic LDAP Connector, which also supports eDirectory.

    Cheers,

    Tom Houston, UK Identity Management Practice

    Wednesday, March 4, 2015 8:33 PM
  • I would like to use the built-in eDirectory MA. I tried the Generic LDAP connector, but I'm having a strange issue (imports only the users whose GUID's first byte is not 0x00, some of the imported users have the aux class!).

    Tom, as there is no object with the aux class imported I cannot see the attribute in CS. According to my investigation today, after the ComputePrimaryObjectClass method the objects with the aux class get filtered.

    I came up with a workaruond, delete the aux class, recreate and inherit from organizationalPerson (insted of inetOrgPerson). This appears to work on FIM side, but I don't know if this will break the app on eDirectory side. I would prefer a solution without touching eDirectory.

    As I understand, the ComputePrimaryObjectClass method might identify the wrong objectClass and cause the object to be filtered. Unfortunately I did not manage to find any documentation on this method or primary object class in eDir MA at all :(


    Csaba

    Wednesday, March 4, 2015 11:20 PM
  • You're not having much luck here! As I see it you're trying to use the standard eDirectory connector to talk to a standard eDirectory implementation and it's not working. I'm quite certain LDAP allows auxiliary object classes to inherit from anywhere other than top. Can you raise a case with PSS?


    Tom Houston, UK Identity Management Practice


    Thursday, March 5, 2015 6:21 PM
  • I have opened a case today morning. I would prefer using the eDirectory connector. I tried the generic LDAP connector, the aux class is not a problem, but as I said in one of my previous comments, it does not import the users which have 0x00 as the first byte of the GUID. According to the trace, the anchor property of these object is null. I couldn't figure out why...

    Csaba

    Thursday, March 5, 2015 6:34 PM
  • Did you find a solution to using the eDirectory MA?  I am having this same issue.  I can work around it by using the OpenLDAP MA, but I would like to find a solution that would allow the use of the eDirectory MA.

    Wednesday, August 26, 2015 12:12 AM
  • Unfortunately we did not have the time to wait for Microsoft support to investigate and fix this, so we looked for a workaround.

    The workaround was to recreate the auxiliary class and instead of specifying inetOrgPerson as SUPerior class we used organizationalPerson. This way FIM detected the objectClass correctly and did not exclude.

    To preserve the attributes we used a temporary class and ldapmodify magic.

    Hope this helps.


    Csaba

    • Marked as answer by Csaba Varszegi Wednesday, August 26, 2015 8:05 AM
    Wednesday, August 26, 2015 8:05 AM
  • Did you ever get a response from Microsoft support regarding this?

    Thanks!


    Did my post help? Please use "Vote As Helpful", "Mark as answer" or "Propose as answer". Thank you!

    Friday, April 15, 2016 1:33 PM
  • Yes, we were told it is likely to be a code issue, therefore it might take months to release a hotfix.

    Csaba

    Friday, April 15, 2016 2:27 PM