By: Attila Jakab user 27 Oct 2016 at 2:26 a.m. CDT

38 Responses
Attila Jakab gravatar
I've set up the environment with Linux Ubuntu 14, Gluu 2.4.4, after fresh installation I tried to log in, import some users, add custom attribuets - everything worked fine - just to verify everything is ok. I followed the steps in 'Procedure for replacing OpenDJ with OpenLDAP in 2.4.4' here https://github.com/GluuFederation/community-edition-setup. I downloaded OpenLDAP Silver from Symas. When I issued the command python setup_openldap.py I got this output (I read your email that there can be error messages and they can be ignored but I think these ones are actual errors): ``` GLUU.root@idp:~/community-edition-setup/openldap_migration# python setup_openldap.py INFO Configuring OpenLDAP ERROR 5810ad94 mdb_db_open: database "o=gluu" cannot be opened: No such file or directory (2). Restore from backup! 5810ad94 backend_startup_one (type=mdb, suffix="o=gluu"): bi_db_open failed! (2) slap_startup failed (test would succeed using the -u switch) INFO Exporting all the data from OpenDJ INFO Importing LDIF files into OpenLDAP ERROR 5810ada3 <= str2entry: str2ad(lastModifiedTime): attribute type undefined slapadd: could not parse entry (line=2416) ``` Especially the last lines. ``` Here is the line mentioned in the error message: **2415:** **2416: **dn: uniqueIdentifier=e64ccef7-fd24-43f5-8b83-26da9c2a95a1,ou=session,o=@!E499.AD59.CB91.757D!0001!AFB0.E328,o=gluu **2417: **objectClass: oxAuthSessionId **2418: **objectClass: top ``` Also, I created the environment in a Vagrant box so if needed I can share it with you. When I connect to OpenLDAP instance through jXplorer (a graphical tool to browse LDAP directories) the connection is succesfull but it's all empty. I'd like to ask if we could get some advice/help with this issue, I double checked if the steps were followed correctly and tried to do some troubleshooting by myself but did not figured out what could go wrong. I don't know if it's related but I'd like to mention that we are using some custom attributes in Gluu, were they take in account when writing the migration script? But I also tried the migration to OpenLDAP with a clean Gluu installation and still failed. Thank you.

By Arunmozhi P user 27 Oct 2016 at 2:28 p.m. CDT

Arunmozhi P gravatar
Hi Attilla, There are two error messages that you have reported. 1. database `"o=gluu" cannot be opened` is bound to occur as there is no database at the start of the setup but the config directories get setup without the issue. So this is nothing to worry about. 2. `str2ad(lastModifiedTime): attribute type undefined` This attribute has been made a Functional Attributes in the versions of the OpenLDAP we tested and hence we have removed it from the schema. To fix this we need to know the version and build of the OpenLDAP installation and if possible a link to the copy of the package. Finally about the custom attributes, thank you for pointing that out, I think we have overseen it. We have a script called `convertSchema.py` in the `community-edition-setup` git repository. I will include its use case in the migration readme docs.

By Arunmozhi P user 27 Oct 2016 at 2:37 p.m. CDT

Arunmozhi P gravatar
One more point to note is, we have used Symas OpenLDAP Gold for our tests. Kindly see if you can get the Gold Version for testing.

By Attila Jakab user 28 Oct 2016 at 12:42 a.m. CDT

Attila Jakab gravatar
Hi Arunmozhi, initially we were trying the Symas OpenLDAP Silver, yesterday afternoon we got access to Symas OpenLDAP Gold. With this version we got only the first error ``` "o=gluu" cannot be opened ``` and then INFO messages that it is exporting ldif from OpenDJ and importing ldif to OpenLDAP, and then ended without any error message. So this part looks like went ok, I'm just going to verify if the Gluu is now working with OpenLDAP correctly. Thank you.

By Attila Jakab user 28 Oct 2016 at 1:35 a.m. CDT

Attila Jakab gravatar
Hi, it looks like it's not working, when we connect to the OpenLDAP instance through jXplorer (GUI tool to browser LDAP directories) with these options: **host** 10.10.10.10 **port** 1636 **protocol** LDAP v2 **level** SSL+Username+Password **user DN** cn=directory manager,o=site **password** password it does not list anything, it's all empty, but the connection succeeds. When we try to open Gluu in browser it does not work at all. With OpenDJ in place it worked. Just to make sure we installed correct OpenLDAP version I share the exact package name we installed: ``` symas-openldap-gold.64_2.4.44-5_amd64.deb ``` Symas provided us also versions devel, nonopt and client. Please advice what can possibly cause the issue and if we have the right version installed. Thank you. Regards, Attila.

By Attila Jakab user 28 Oct 2016 at 1:54 a.m. CDT

Attila Jakab gravatar
Ok this morning I tried the whole process again, a clean installation of Gluu 2.4.4. on Ubuntu 14.04 - everything works. I install then OpenLDAP ``` symas-openldap-gold.64_2.4.44-5_amd64.deb ``` and got the same error as previously **ERROR 5812f5c0 <= str2entry: str2ad(lastModifiedTime): attribute type undefined slapadd: could not parse entry (line=2416)** Please advice. Thank you. Regards, Attila.

By Arunmozhi P user 28 Oct 2016 at 12:03 p.m. CDT

Arunmozhi P gravatar
Hi Attila, Thank you for the detailed reports of everything you have done. The issue seems to be about the lastModifiedTime attribute. Somehow I have never run into this error. I will add a function to change this attribute to the new definition after referring to the schema. I will update you once that is done and you can continue your testing. Kindly bear with us until then. Thank you.

By Arunmozhi P user 29 Oct 2016 at 12:24 a.m. CDT

Arunmozhi P gravatar
Hello Attila, I have updated the script as I said. Now the data gets imported without issue. I have tested and verified. The `lastModifiedTime` shouldn't be an issue. I still have reservations about your custom attributes. I will be adding steps to migrate that. Meanwhile, test with the updated script and let me know how it goes. Thank you for your patience.

By Arunmozhi P user 29 Oct 2016 at 12:41 a.m. CDT

Arunmozhi P gravatar
Here is one more observation and recommendation. The attribute `lastModifiedTime` is a deprecated Functional Attribute of the OpenLDAP system and hence it is read-only. So When migrating from OpenDJ to OpenLDAP we have renamed it to `oxLastAccessTime`. But then the codebase of 2.4.4 uses the attribute `lastModifiedTime` to store its sessions. So you won't be able to use the web UI to access. If your evaluation is solely on the LDAP software performance, I think testing it without the WebUI should be fine. But if you want to test the entire Gluu Server with OpenLDAP, then I suggest waiting for our 3.0.0 build which will have both OpenLDAP the relevant codebase. We can give you instructions about getting our alpha builds when as they come live. Thank you.

By Attila Jakab user 31 Oct 2016 at 3:27 a.m. CDT

Attila Jakab gravatar
Hi Arunmozhi, Thank you for your answers. I tried the updated migration script, now did not get those errors mentioned above. However, I'm not sure if the migration went well. When I try to connect to OpenLDAP through jXplorer with values mentioned above, it connects succesfully but I got '_Unable to list_' message, and the whole structure is empty. When I try to search for any user (I did not import any user to OpenDJ before trying the migration script, only the default admin user is present so I expect to get only one result - the admin user) with the following command: ``` ./ldapsearch -H ldaps://10.10.10.10:1636 -D "cn=directory manager,o=site" -w password -b o=site -s sub "objectclass=*" ``` or like this ``` ./ldapsearch -p 1636 -D "cn=directory manager,o=site" -w password -h idp.economistdev.com -b o=gluu -s sub "objectclass=*" ``` (I try also with o=gluu instead of o=site) I always get this message: **ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)** (In my /etc/hosts the idp.economistdev.com is set to 10.10.10.10) When I check for the status with ``` service solserver status ``` I get **Symas OpenLDAP LDAP services slapd is running** so OpenLDAP is running. In the _symas-openldap.conf_ under /opt/symas/etc/openldap I see that the host is set correctly: **HOST_LIST="ldaps://10.10.10.10:1636/ ldaps://127.0.0.1:1636/ ldapi:///"** What I noticed there is no _ldap.conf._ file only _ldap.conf.default_, so I copied this files to make an _ldap.conf_ and filled the values BASE to **o=site** and URI to **ldaps://10.10.10.10:1636** but still the same error. Any advice why can't I see th contents of OpenLDAP, why I get these messages when I try to issue ldapsearch and why when I (succesfully) connect with jXplorer it does not show anything in directory structure? Thank you. Regards, Attila.

By Attila Jakab user 31 Oct 2016 at 3:41 a.m. CDT

Attila Jakab gravatar
Also sharing output when I append **-d-1** to the end of the command to get some debugging I get this: ``` ldap_create ldap_url_parse_ext(ldap://idp.economistdev.com:1636) ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP idp.economistdev.com:1636 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 10.10.10.10:1636 ldap_pvt_connect: fd: 3 tm: -1 async: 0 attempting to connect: connect success ldap_open_defconn: successful ldap_send_server_request ber_scanf fmt ({it) ber: ber_dump: buf=0xcc5800 ptr=0xcc5800 end=0xcc5830 len=48 0000: 30 2e 02 01 01 60 29 02 01 03 04 1b 63 6e 3d 64 0....`).....cn=d 0010: 69 72 65 63 74 6f 72 79 20 6d 61 6e 61 67 65 72 irectory manager 0020: 2c 6f 3d 73 69 74 65 80 07 65 63 6f 6e 64 65 76 ,o=site..econdev ber_scanf fmt ({i) ber: ber_dump: buf=0xcc5800 ptr=0xcc5805 end=0xcc5830 len=43 0000: 60 29 02 01 03 04 1b 63 6e 3d 64 69 72 65 63 74 `).....cn=direct 0010: 6f 72 79 20 6d 61 6e 61 67 65 72 2c 6f 3d 73 69 ory manager,o=si 0020: 74 65 80 07 65 63 6f 6e 64 65 76 te..econdev ber_flush2: 48 bytes to sd 3 0000: 30 2e 02 01 01 60 29 02 01 03 04 1b 63 6e 3d 64 0....`).....cn=d 0010: 69 72 65 63 74 6f 72 79 20 6d 61 6e 61 67 65 72 irectory manager 0020: 2c 6f 3d 73 69 74 65 80 07 65 63 6f 6e 64 65 76 ,o=site..econdev ldap_write: want=48, written=48 0000: 30 2e 02 01 01 60 29 02 01 03 04 1b 63 6e 3d 64 0....`).....cn=d 0010: 69 72 65 63 74 6f 72 79 20 6d 61 6e 61 67 65 72 irectory manager 0020: 2c 6f 3d 73 69 74 65 80 07 65 63 6f 6e 64 65 76 ,o=site..econdev ldap_result ld 0xcbd590 msgid 1 wait4msg ld 0xcbd590 msgid 1 (infinite timeout) wait4msg continue ld 0xcbd590 msgid 1 all 1 ** ld 0xcbd590 Connections: * host: idp.economistdev.com port: 1636 (default) refcnt: 2 status: Connected last used: Mon Oct 31 08:40:02 2016 ** ld 0xcbd590 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ld 0xcbd590 request count 1 (abandoned 0) ** ld 0xcbd590 Response Queue: Empty ld 0xcbd590 response count 0 ldap_chkResponseList ld 0xcbd590 msgid 1 all 1 ldap_chkResponseList returns ld 0xcbd590 NULL ldap_int_select read1msg: ld 0xcbd590 msgid 1 all 1 ber_get_next ldap_read: want=8, got=0 ber_get_next failed. ldap_err2string ldap_result: Can't contact LDAP server (-1) ldap_free_request (origid 1, msgid 1) ldap_free_connection 1 1 ldap_free_connection: actually freed ```

By Arunmozhi P user 31 Oct 2016 at 10:53 a.m. CDT

Arunmozhi P gravatar
Hello Attila, Try using the bindDN/rootDN `cn=directory manager,o=gluu` instead of `o=site`. I used ApacheDirectory Studio to test. It works fine. Maybe the rootDN is the issue.

By Attila Jakab user 31 Oct 2016 at 11 a.m. CDT

Attila Jakab gravatar
Hi Arunmozhi, in my comment I am mentioning that I tried both o=gluu and o=site but still fails. Any other ideas? Did you try on Ubuntu 14.04 with Gluu 2.4.4 clean installation with no other specific configuration? Regards, Attila.

By Arunmozhi P user 31 Oct 2016 at 11:23 a.m. CDT

Arunmozhi P gravatar
Hi Attila, Yes. I tested on a clean installation using Ubuntu 14.04. I am going to test again using jXplorer and try to recreate your exact setup. I will update you on the situation. Thank you.

By Attila Jakab user 31 Oct 2016 at 11:33 a.m. CDT

Attila Jakab gravatar
Hi Arunmozhi, I had a meeting with Mike S., the issue is now solved. The command line ldapsearch was not working because I was in a bad directory (/opt/symas/bin) instead of opt/openldap/bin. The jXplorer did not work because I was missing the Base DN: o=gluu in the login screen. Thank you, Regards, Attila.

By Attila Jakab user 31 Oct 2016 at 11:41 a.m. CDT

Attila Jakab gravatar
Arunmozhi, last thing - the migration for custom attributes, is it still in process or it's already added to the current migration script? Regards, Attila.

By Arunmozhi P user 31 Oct 2016 at 11:57 a.m. CDT

Arunmozhi P gravatar
Attila, I am happy to hear that the issue has been resolved. We have a script for schema migration. Migration of custom attributes has to be done manually using that script. I will add the steps to the README docs and update you with the information. Thank you.

By Attila Jakab user 31 Oct 2016 at noon CDT

Attila Jakab gravatar
Arunmozhi, thank you, sound great. Do you have any time estimation when will that script for custom attributes migration available? Attila

By Arunmozhi P user 31 Oct 2016 at 12:38 p.m. CDT

Arunmozhi P gravatar
Hi Attila, Regarding the custom attributes. We need some inputs. Do you have them defined in a specific ldif file? Or were all of them created with the oxTrust Webui? Or is there a mix of attributes defined in a ldif file and some created via the webui? This will help us prepare the instructions. Thank you.

By Attila Jakab user 31 Oct 2016 at 12:47 p.m. CDT

Attila Jakab gravatar
They were all created in the Gluu web UI.

By Arunmozhi P user 31 Oct 2016 at 2:17 p.m. CDT

Arunmozhi P gravatar
Thank you for the input. The script has now been updated to migrate the custom attributes as well. You can test your data migration now. Thank you.

By Attila Jakab user 02 Nov 2016 at 2:49 a.m. CDT

Attila Jakab gravatar
Hi Arunmozhi, I tried the updated migration script. In OpenDJ I had my custom attributes added through Gluu Web UI, except the default admin user I imported two additional users to OpenDJ with those custom attributes. Here is a sample user from ldif file: ``` dn: inum=@!E499.AD59.CB91.757D!0001!AFB0.E328!0000!A8F2.DE1E.D7FC,ou=people,o=@!E499.AD59.CB91.757D!0001!AFB0.E328,o=gluu inum: @!E499.AD59.CB91.757D!0001!AFB0.E328!0000!A8F2.DE1E.D7FC objectClass: gluuPerson cn: web: {"product":"web","entitlements":[{"ID":"bb0cb915-2c0c-4e56-b471-23882026a626","source":"gp:12999763169054705758.1384811746159600","start":1397189359,"end":1399997359}]} app: {"product":"app","entitlements":[{"ID":"3034617d-bfce-41b4-968b-f9c2e80e09ba","source":"gp:12999763169054705758.1384811746159600","start":1397189359,"end":1399997359}]} displayName: gluuStatus: active iname: *person*dbantroch@example.com uid: dbantroch@example.com userPassword: heslo legacyPassword: heslo objectClass: ox-E499AD59CB91757D0001AFB0E328 objectClass: top ``` When the user is imported to OpenDJ the userPassoword is hashed to SSHA512. After running the migration script I got the following: ``` GLUU.root@idp:~/community-edition-setup/openldap_migration# python setup_openldap.py INFO Scanning setup.properties.last for data INFO Converting existing custom attributes to OpenLDAP schema WARNING Skipping Line: modifiersName: cn=Directory Manager,cn=Root DNs,cn=config WARNING Skipping Line: modifyTimestamp: 20161102070048Z Traceback (most recent call last): File "setup_openldap.py", line 236, in <module> setup.render_templates() File "setup_openldap.py", line 90, in render_templates self.outputFolder) File "setup_openldap.py", line 81, in renderTemplate newFn.write(template_text % self.__dict__) KeyError: 'encoded_ldap_pw' ``` The error is probably with passwords.. so I tried the same (reverted back my virtual machine with Gluu to a clean state) but only with custom attributes added, no additional users imported except the default admin users. Got the the same error. I gave it a third time - **without any custom attributes added** (so same as on Monday when the script worked) or any modification, the script fails again.. Now with this error: ``` GLUU.root@idp:~/community-edition-setup/openldap_migration# python setup_openldap.py INFO Scanning setup.properties.last for data INFO Converting existing custom attributes to OpenLDAP schema Traceback (most recent call last): File "setup_openldap.py", line 235, in <module> setup.create_user_schema() File "setup_openldap.py", line 218, in create_user_schema with open(schema_99, 'r') as olduser: IOError: [Errno 2] No such file or directory: '/opt/opendj/config/schema/99-user.ldif' ``` Previously, on Monday, when no custom attributes were present the script worked fine. Please advice. Regards, Attila.

By Michael Schwartz Account Admin 02 Nov 2016 at 6:16 a.m. CDT

Michael Schwartz gravatar
Here is the sample script: ``` #!/usr/bin/python import uuid ORG_INUM = "@!281E.2A69.9D58.5507!0001!C4A2.021C" ATTR_PREFIX = "1001" attrs = [{'attr-name': 'test', 'org-inum': ORG_INUM, "attr-description": "test description"}] template = """dn: inum=%(attr-inum)s,ou=attributes,o=%(org-inum)s,o=gluu objectClass: gluuAttribute objectClass: top description: %(attr-description)s gluuAttributeType: string displayName: %(attr-name)s gluuAttributeName: %(attr-name)s gluuAttributeOrigin: economistPerson gluuAttributeEditType: admin gluuAttributeViewType: admin gluuStatus: active inum: %(attr-inum)s """ for attr in attrs: # Won't have collissions because it is two segments r1 = str(uuid.uuid4())[:4] r2 = "%s.%s" % (ATTR_PREFIX, r1) attr['attr-inum'] = "%s!0005!%s" % (ORG_INUM, r2) print template % attr ```

By Attila Jakab user 02 Nov 2016 at 10:09 a.m. CDT

Attila Jakab gravatar
Any updates on the ticket?

By Arunmozhi P user 02 Nov 2016 at 11:26 a.m. CDT

Arunmozhi P gravatar
Hi Attila, I am testing the script with different combinations. As you might have clearly seen, the errors you mention are different and come up at different scenarios. I will update you soon. Mostly with a couple of hours. Thank you.

By Arunmozhi P user 02 Nov 2016 at 12:37 p.m. CDT

Arunmozhi P gravatar
Hi Attila, The issue was we have been updating our master branch of the repository and a few dependent files got changed affecting the openldap migration scripts. I have created a new branch `openldap-migration` which will preserve the files. I have updated the instructions as well. Kindly use the new branch. [https://github.com/GluuFederation/community-edition-setup/tree/openldap-migration/openldap_migration](https://github.com/GluuFederation/community-edition-setup/tree/openldap-migration/openldap_migration)

By Attila Jakab user 03 Nov 2016 at 2:30 a.m. CDT

Attila Jakab gravatar
Hi Arunmozhi, Mike, thank you for the update. The script now works - I tried with clean Gluu and also with custom attributes added, I can confirm that the custom attributes were migrated from OpenDJ to OpenLDAP using your provided script. However, what I noticed, when I import a user (lets say through jXplorer) in **OpenDJ**, the ``` userPassword ``` field will be hashed to SSHA512 since this is the Gluu default password policy. But when I do the same, when I import a user in **OpenLDAP** (again, through jXplorer) the``` userPassword ``` field stays untouched - it's imported as it is without hashing it. Any ideas on this? Is this on purpose? Thank you. Attila.

By Arunmozhi P user 03 Nov 2016 at 11:23 a.m. CDT

Arunmozhi P gravatar
Hi Attila, It is good to hear that you were able to perform the migration. The password policy in OpenLDAP is configured using the ppolicy module presently and we haven't yet applied any specific customisations on the configuration yet. Thank you for brining it to our notice we will be testing and updating the Password Policy on OpenLDAP. I am closing the ticket as the migration issue has been resolved. Thank you. Regards, Arunmozhi

By Arunmozhi P user 03 Nov 2016 at 2:02 p.m. CDT

Arunmozhi P gravatar
Hi Attila, While researching about the Password Policies, I stumbled upon this [http://stackoverflow.com/a/11731604](http://stackoverflow.com/a/11731604), which basically says, OpenLDAP isn't responsible for hashing and it is upto the client to do it. OpenLDAP would support storage and validation of hashed passwords. Since we exported an imported the data here, the data is stored as such in plaintext. I have testbed for our Gluu Server 3.0.0 with OpenLDAP, I assure you the passwords are hashed and stored safely. Thanks again for bringing this up. I will keep this point in mind when preparing migration from 2.4.4 to 3.0.0. Regards, Arun

By Attila Jakab user 04 Nov 2016 at 4:36 a.m. CDT

Attila Jakab gravatar
Hi Arunmozhi, can you please clarify your comments? I'm not sure I understand. So, in OpenDJ when we imported a user lets say through command line ```ldapmodify``` or ```import-ldif``` the password was hashed based on the configured password policy, so lets say to SSHA512 or Bcrypt. How will this behave now? How can we store hashed password (SSHA512 or Bcrypt) in OpenLDAP, so the password validation will work? We must pre-hash the passwords before storing them in OpenLDAP? Please clarify. Thank you. Regards, Attila.

By Arunmozhi P user 04 Nov 2016 at 11:10 a.m. CDT

Arunmozhi P gravatar
Hi Attila, The default policy of the OpenLDAP system is to save the passwords in cleartext so that things like length, weight etc can be computed and checked. But after digging deep, I was able to find a config for the ppolicy overlay module of OpenLDAP which would allow us to store hashed passwords and still be useful. So to answer your questions: > How will this behave now? How can we store hashed password (SSHA512 or Bcrypt) in OpenLDAP, so the password validation will work? Yes. We can store hashed passwords in OpenLDAP and validation would work. [http://www.openldap.org/doc/admin24/security.html#Password%20Storage](http://www.openldap.org/doc/admin24/security.html#Password%20Storage) <- this page lists all the hashes OpenLDAP supports. > We must pre-hash the passwords before storing them in OpenLDAP? I have enabled the auto hashing of any cleartext password sent to OpenLDAP in the slapd.conf file and this should be applied for the `ldapmodify` data as well. I am however not sure about the `slapadd` or `import-ldap`. I will be testing it for our evaluation and will update you too. Thanks.

By Arunmozhi P user 04 Nov 2016 at noon CDT

Arunmozhi P gravatar
Hi Attila, I have verified. The imported data no longer stores cleartext. So our after our migration procedure, you should be seeing hashed passwords in the jXplorer client. Thanks. Regards, Arun.

By Attila Jakab user 07 Nov 2016 at 1:42 a.m. CST

Attila Jakab gravatar
Hi Arunmozhi, can you specify how you achieved that the imported user's passwords are automatically hashed? I don't see that the script here https://github.com/GluuFederation/community-edition-setup/tree/openldap-migration/openldap_migration was updated. Can you specify what configuration needs to be done? Because currently when I import a user, the user's ```userPassword``` field stays cleartext. Thank you, Attila.

By Arunmozhi P user 07 Nov 2016 at 10:44 a.m. CST

Arunmozhi P gravatar
Hi Attila, It was added to the configuration file `slapd.conf`. You can see the commit [here](https://github.com/GluuFederation/community-edition-setup/commit/e7cf6f750c3be88053d5469af805e01126210f5f). > Because currently when I import a user, the user's userPassword field stays cleartext. I am a little confused. Can you check the value of `userPassword` attribute across the different stages? * When it is stored in OpenDJ, * When it is in the exported LDIF file * After it is imported into the OpenLDAP This might help us identify where the hashing is failing. For me it is the SSHA hash everywhere. So can't really see the cleartext. Thanks. - Arun

By Attila Jakab user 07 Nov 2016 at 10:48 a.m. CST

Attila Jakab gravatar
Hi Arunmozhi, user's passwords in OpenDJ are SSHA512, when they are exported they are also SSHA512. But I mean a situation when I am importing a new user that was not previously in OpenDJ. So I have a ldif with a single user like this ``` dn: inum=@!E499.AD59.CB91.757D!0001!AFB0.E328!0000!A8F2.DE1E.D7FD,ou=people,o=@!E499.AD59.CB91.757D!0001!AFB0.E328,o=gluu inum: @!E499.AD59.CB91.757D!0001!AFB0.E328!0000!A8F2.DE1E.D7FD objectClass: gluuPerson cn: web: {"product":"web","entitlements":[{"ID":"6b613b26-bdae-4d5c-87e2-f610710ab64c","source":"gp:12999763169054705758.1397332069676065","start":1397193806,"end":1400001806}]} app: {"product":"app","entitlements":[{"ID":"0c0c891b-af68-46a1-b0cb-c356370213eb","source":"gp:12999763169054705758.1397332069676065","start":1397193806,"end":1400001806}]} displayName: gluuStatus: active iname: *person*hwaeger@example.com uid: hwaeger@example.com userPassword: heslo legacyPassword: heslo objectClass: ox-E499AD59CB91757D0001AFB0E328 objectClass: top ``` and after importing this ldif file the ```userPassword``` field stays cleartext. Attila.

By Arunmozhi P user 07 Nov 2016 at 12:40 p.m. CST

Arunmozhi P gravatar
I see. Check and add these lines in your slapd.conf if they don't exist. * Below the line which says `overlay ppolicy`, there should be a line called `ppolicy_hash_cleartext` * Above the section `Main Database housing o=gluu information` add another setting `password-hash {SSHA}` If you doing a new migration. Then you don't have to add these, the repo is updated with these settings. Thanks.

By Attila Jakab user 08 Nov 2016 at 3:02 a.m. CST

Attila Jakab gravatar
Hi Arun, it seems like it's working, I tried with one user. I'm just wondering why it didn't worked before, I did not change anything. Anyways, looks good so far. Is there a way to hash it to SSHA**512**? Thanks, Attila.

By Attila Jakab user 08 Nov 2016 at 9:05 a.m. CST

Attila Jakab gravatar
Hi, any updates please? Regards, Attila.

By Arunmozhi P user 08 Nov 2016 at 9:21 a.m. CST

Arunmozhi P gravatar
Hi, I am afraid not. You can see the complete list of supported algorithms [here in OpenLDAP docs](http://www.openldap.org/doc/admin24/security.html#Password%20Storage) However there is a BCRYPT overlay you can enable if you want it. The instructions can be found [here in Github](https://github.com/wclarie/openldap-bcrypt) I hope it helps. Regards, Arun