This topic has 1 reply, 2 voices, and was last updated 6 years, 6 months ago by 
.
-
Posts
-
Hello,
I’m trying to migrate some users from LDAP to another LDAP server, which is connected to my OpenIDM.
The user passwords on the LDIF file are {SSHA}hash.
Doing the reconciliation, OpenIDM could create on my local database the correct crypto, but using ./cli.sh encrypt password it does not work.
Does anyone know what is done with the LDAP password by the reconciliation process to generate the crypto password?
Thanks,
FelipeI am not sure why you are using OpenIDM for this type of tool as simply exporting the data from one LDAP server and importing it into the other LDAP server is much easier (assuming you are using the same schema, hashing algorithms, etc.).
If you MUST use OpenIDM to perform this process, then keep in mind that you cannot unhash a hashed password. As such, any passwords pulled from LDAP Server 1 are basically unusable in OpenIDM. The “fun” part is if you are using OpenIDM’s password field in your LDAP to OpenIDM mapping, if so, then OpenIDM automatically encrypts the incoming data (so now you have an encrypted AND hashed password). To get the decrypted hashed password, you would need to decrypt the OpenIDM password field and this can be performed with a translation in the mapping before passing it to LDAP Server 2.
Alternatively you could use a different field for storing the password in OpenIDM (i.e. call it ldapPassword). Then the data would be stored in the field “as is”. This shouldn’t be a problem since it is unusable to OpenIDM anyways.
Finally, another alternative is to simply perform a system to system (LDAP to LDAP) mapping and sort of bypass OpenIDM altogether. OpenIDM then acts more like a data broker between the two system resources in this sort of coordination.
These are the approaches I would take in attempting to do what you are mentioning. But keep in mind the export to LDIF / import from LDIF is the easiest option if you can go that route.
You must be logged in to reply to this topic.
