Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Celebration

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root

Avatar

1 badge earned

Collect

Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!

Challenges
Coins

Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.

Recognition
Ribbon

Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!

Leaderboard

Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,465,131
Community Members
 
Community Events
176
Community Groups

Migrate from CROWD to openLDAP

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;

But the in crowd saved passwords are saved with password-encryption "ATLASSIAN-SECURITY" -> so I cannot use theses hashes in openLDAP.
Is there a way to change the password-encryption?? So that I can import md5 hashes in openLDAP??
Thank you very much!

3 answers

1 accepted

1 vote
Answer accepted

Hi Christopher,

  1. I haven't paid much attention to the ticket you have mentioned but it would be good to verify if they will be supporting internal directory to external directory migration
  2. When I did a migration from Confluence to LDAP, I used the Crowd CSV import tool. NOTE that "ATLASSIAN-SECURITY" password-encryption is not supported by openLDAP and cannot be changed to anyother hash (We did a good amount of research on this and there is no easy way to carry over the Password therefore we decided to reset the password for all the users during migration).Steps that I followed were
    1. Configure your LDAP to Crowd
    2. Created two CSV exports form the Crowd (or Confluence Directories) for user and another for group membership
    3. Store the two CSV's in the Crowd server and follow the CSV import instructions.

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!!!!!

1 vote

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

Suggest an answer

Log in or Sign up to answer
TAGS

Atlassian Community Events