Hello.
I am trying to migrate all my internal stored Directories/Groups/Users from Crowd to openLDAP.
1) I already found this ticket (migrate from one directory to another) which is not solved yet:
https://jira.atlassian.com/browse/JRA-27868
So my question: Is there already any possibility which I did not find yet??
2) If there is no built solution yet the idea is to export a ldap-dif from Crowd-database and import it in openLDAP.
Maybe with a statement like this:
select 'dn: cn=' || user_name || ',ou=users,dc=ebcont,dc=com' || chr(13) || 'objectClass: person' || chr(13) || 'objectClass: top' || chr(13) || 'email: ' || email_address || chr(13) || 'uid: ' || user_name || chr(13) || 'cn: ' || user_name || chr(13) || 'structuralObjectClass: person' || chr(13) || 'givenName: ' || display_name || chr(13) || 'userPassword:: '|| credential || chr(13) || chr(13) from cwd_user ub;
Hi Christopher,
Hope this helps
-Ashma
Ashma, Caspar - thank you very much for your information!
I feared that there is no easy solution but thanks for the hint with CSV-import/export!!!!!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
By design, password hashes in a directory using atlassian-security are stored as an irreversible cryptographic hash (assuming the underlying hash algorithm is sound, which we believe it is - we use PBKDF2), so there's no trivial way to get the passwords out of Crowd.
If you are willing to spend some development time on this (or pay someone to do so), you could write a plugin for Crowd which provides a custom password encoder which authenticates users the way AtlassianSecurityPasswordEncoder does (as in, copy paste the code for that) but implements UpgradeablePasswordEncoder to always upgrade the passwords to a hashing algorithm supported by OpenLDAP. Then, when you switch the existing internal directory to use your custom password encoder, users will gradually be migrated over to the new hashing algorithm as they log in successfully.
Then again, requiring a password reset is by far the simplest solution here.
Unfortunately, I can't comment on JRA-27868 on the JIRA backlog because I'm a developer on Crowd (and aside from that we have a general policy of not providing ETAs for issues anyway).
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.