Please, first note that in no circumstances CA Technologies will provide way to un-encrypt password data from other vendors.
For such request you would need to directly handle with the own vendor.
Task 1: Export Data from the LDAP-Compliant Directory Server into LDIF File Format
See the vendor-supplied documentation for instructions.
If flags or options exist for exporting data from the foreign directory, be sure to select the method that:
- Produces LDIF output with the least amount of proprietary information included
- Provides maximum conformance to the IETF Request for Comments 2849 of the IETF, available for download at: http://www.ietf.org
Task 2: Analyze the LDIF User Data for Any Required Schema Additions Referenced in the LDIF Data
See "Schema Files Provided with CA Directory" from CA Directory Reference Guide.
Any attributes not found in the CA Directory base schemas require publishing of additional schema before the importation of the LDIF file.
Task 3: Publish Additional Schema in CA Directory
See "Schema Publishing" from CA Directory Administration Guide.
CA Directory supports schema publishing through LDAP Version 3.
This enables LDAP directory clients to read the directory schema dynamically from the DXserver using LDAP Version 3.
For further information, see section 4.2 Subschema Subentries in RFC 4512.
Task 4: Remove Any Proprietary Directory Data from the LDIF File
Certain elements of the LDAP v3 standard have not yet been formalized, such as AC attributes.
As a result, various directory vendors implement AC policy objects in ways that do not translate well across vendor installations.
There may be other proprietary metadata unrelated to access control. You should remove this as well.
Understanding the various IETF RFCs can help you determine which directory metadata is proprietary to a given vendor and which complies with the LDAP standards, and is thus portable by way of an LDIF file.
Task 5: Remove Operational Attributes from the LDIF File
Four of the standard LDAP v3 operational attributes, namely, creatorsName, createTimestamp, modifiersName, and modifyTimestamp are automatically generated by Oracle Internet Directory whenever entries are created or imported. It is not possible to instantiate these values from existing directory data, for example by using LDIF file importation.
Therefore you should remove these attributes from the file before attempting to import.
Task 6: Remove Incompatible userPassword Attribute Values from the LDIF File
By default, the passwords stored in the userPassword attribute by CA Directory are encrypted using SHA-1.
However, you can use a different encryption scheme to encrypt these passwords.
See "Choose an Encryption Method for Passwords Stored in a DSA" from CA Directory Administration Guide for the userPassword attribute hash algorithms supported by CA Directory.
The userPassword attribute hash values used by some vendor products are not compatible with CA Directory.
As a result, you must remove all lines corresponding to the userPassword attribute and value from the LDIF data file unless they are represented in plain text or contain no value.
Task 7: Import the LDIF Data
See "DXloaddb Tool—Load a Datastore from an LDIF File" from CA Directory Reference Guide.
Task 8: Reset userPassword Data
After importation of the LDIF data, you must manually re-enter or upload userPassword information separately into the directory.
Be sure that the passwords comply with the CA Directory password policies and are in clear text.
See "DXmodify Tool -- Add New or Changed Information to a Directory" from CA Directory Reference Guide.