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,

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

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,

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.

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)"

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

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 :(

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 wit

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.

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.