Authentication to remote OpenLdap-server

By: Petri Pyoria named 18 May 2018 at 5:56 a.m. CDT

8 Responses
Petri Pyoria gravatar
Could you clarify how certificates should be configured to the Gluu and remote OpenLdap servers to create connection between them? I am able to contact the remote OpenLdap -server from a Gluu server with the ldapsearch-tool following way: ``` LDAPTLS_REQCERT=never ldapsearch -H ldaps://openldap.domain:1636 -D "cn=Directory Manager,o=gluu" -w password -b o=gluu ``` However, connection between the servers fails when I start the Gluu. From an oxauth_persistence.log -file I can see that there is a problem with certificates: ``` (LDAPConnectionProvider.java:77) - Failed to create connection pool with properties LDAPBindException: An error occurred while attempting to send the LDAP message to server openldap.domain:1636: SSLHandshakeException(message='sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target' ``` It seems for me that Gluu does not accept the connection. We are currently using Symas OpenLdap silver-version in the OpenLdap-server. To add Gluu certificate to the OpenLdap server, I just copied **openldap.crt** from the Gluu server and copy-pasted it to **/etc/openldap/ca_bundle.crt** -file in the OpenLdap-server. I also ensured that ca-bundle.crt was configured to **/opt/symas/etc/openldap/slapd.conf** ``` TLSCACertificateFile "/etc/openldap/certs/ca-bundle.crt" ``` In the Gluu-server I changed servers-URI in the ox-ldap.properties -file following way: ``` servers: openldap.domain:1636 ```
CentOS 7.4
closed

Answers

By Mohib Zico Account Admin 18 May 2018 at 8:31 a.m. CDT

Copy
Mohib Zico gravatar
>> how certificates should be configured to the Gluu and remote OpenLdap servers to create connection between them? What type of connection we are talking about? Just for user's authentication or whole Gluu data in remote OpenLDAP server?

By Petri Pyoria named 21 May 2018 at 12:20 a.m. CDT

Copy
Petri Pyoria gravatar
Whole Gluu data in remote OpenLDAP server. We have separate servers for Gluu and OpenLDAP.

By Mohib Zico Account Admin 21 May 2018 at 1:43 a.m. CDT

Copy
Mohib Zico gravatar
Ok, in that sense you have to migrate all schema of Gluu Server, openldap related cert and key as well. We don't have any doc with OpenLDAP for community yet.

By Petri Pyoria named 21 May 2018 at 1:50 a.m. CDT

Copy
Petri Pyoria gravatar
As far as I can say, we have migrated everything. For example, ldapsearch connection with Gluu passwords is working. I thought that steps described above are enough, but perhaps something is still missing? Could you give some details how exactly certificate and key should be migrated to OpenLDAP server? I think that this is is the root problem which I have understood somehow wrong way?

By Mohib Zico Account Admin 21 May 2018 at 2:13 a.m. CDT

Copy
Mohib Zico gravatar
We will publish a doc on how such scenario is achieved with Gluu-OpenDJ; you will be able be compare with that I believe.

By Petri Pyoria named 21 May 2018 at 2:23 a.m. CDT

Copy
Petri Pyoria gravatar
Unfortunately, it sounds that it will be too late for us unless the document will be available in a few days. This problem has halted already our product development. We are purchasing the Gluu license and we should be able to continue development of our authentication application as soon as possible. I have understood that Gluu is moving to usage of OpenLDAP instead of OpenDJ? Why the documentation will be done to the old solution?

By Mohib Zico Account Admin 21 May 2018 at 2:45 a.m. CDT

Copy
Mohib Zico gravatar
In latest deployment we are using OpenDJ instead of OpenLDAP. We encountered some serious issues regarding OpenLDAP in replicated environment which we couldn’t ship to our customers. The OpenDJ related doc you will get is from latest deployment from one customer.

By Petri Pyoria named 21 May 2018 at 4:28 a.m. CDT

Copy
Petri Pyoria gravatar
It seems that we were able to progress at least one step forward by commenting following lines in the ox-ldap.properties -file: ssl.trustStoreFile: /etc/certs/openldap.pkcs12 ssl.trustStorePin: XXXXXXXXXXXXXXXXXX ssl.trustStoreFormat: pkcs12 The file openldap.pkcs12 should have been Ok, but for some reason, it was preventing communication between servers. Could you tell more about the issues? We may see them as well?

Post an answer