Symantec IGA

The client I am working with has defined multiple structural object classes in his OpenLDAP directory. As a result when I try to explore the newly acquired endpoint in the Provisioning Manager, the explore task fails. Only the object containers make it over to the provisioning directory, but none of the objects in the containers make it over. CA Support has indicated that Connector Xpress does not support directories with multiple structural object classes defined. Has anybody has successfully implemented a work around to this problem?

Support case 00940236 was opened. Worked with customer in creating a project with a single structural objectclass and with auxiliary objectclasses.

Hello Kenny,

We are in a similar scenario where some managed objects have multiple structural classes.

As far as I've read the case and the know issues list, this is applicable to any object (not only containers or accounts), right?

Do we have an enhancement already with the dev team for this or should we create a new idea here ?

Hi Pablo,

For LDAP directories managed by IM, with multiple structural classes, one option is to create muliple CX connectors, e.g. one for each structural class.

Then tie the three (3) account templates to one (1) provisioning role, where any business logic require to manage the three (3) structural class's attributes are managed within the IM provisoning tier, IM PX rules, or with the CX Operational Bindings (javascript) feature set.

We did this for one customer, where three (3) structural objectClasses for a NIS replacement was requested.

NIS Replacement by CA Directory 

See if this has value for your requirements.

Cheers,

A.

Hi,

Just passing by to let you know a quick way to bypass this validation:

Once you class is mapped to all of the LDAP classes (structural or no) edit the metadata and just switch the values defined in the class mapping portion of it, i.e., making any additional structural class be considered like an auxiliary one.

So yes, we are kind of tricking our solution to accept this but: 

1. As far as the endpoint is concerned, it couldn't care less. The resulting ldap operation will have all of the object classes (structural or not) being sent as a single package to it.

2. This seems to be a UI validation only (CX and Prov Manager).

And, to be totally honest, I don't see the point for this sort of validation considering that the LDAP itself doesn't care at all...

This solved the problem for us and no impacts were found after some unitary testing.

Let me know if you need more precise directions on the metadata changes.

Regards,

Pedro

Hi Pedro,

Excellent observation.   Was the endpoint directory CA Directory, Novell eDirectory, Oracle OID, MS LDS, OpenLDAP, etc.?

-  Each one will have/may have different validation checks themselves; especially for referential objects; where structural classes are used.

- This process will still be useful for to determine where referential integrity is or is not required between the structural objects.

Would you "cleanse" your example and share?    Did you directly update the XML (*.con) file with Notepad++ or use an LDIF tool to edit the CX namespace, directly with in the provisioning store?

Cheers,

A.

Pedro, remember that when I showed you how to "trick" the system I said this was being offered "as-is" with no implied support.

Pedro,

I agree with what Kenny has mentioned.

Regards,

N