Hi. Please note, that enabling LDAP authentication in 4.0 is a bit tricky at the moment. Here is how it's done in 4.0 (steps assume you've already configured CR and imported your users; better also put some of them to Managers group too): 1. Move to " Configuration -> Manage Authentication" page 2. At "Manage LDAP authentication" tab fill in all the fields the usual way 3. Make sure you click "Activate" button, it's mandatory step now; you can also test the connection there 4. Click the "Update" button 5. Switch to "Default auth method" tab and select "auth_ldap_server" method from the drop-down there 6. Click the "Update" button again Please note that step 6) you **must** click "Update" again after making sure "auth_ldap_server" is selected as "Default auth method" - even if it appears like it's already persisted, please click it anyway 2nd time. Please follow those steps closely, and you should make it work (assuming CR is correctly configured).

I have already set up as your guide. Once again I followed your guide and set up, but the results are the same. What is the problem?

Please answer me..

Hi, I have a similar problem. But, I could solve it by my self. I'm using a DS 389 directory server with SSL enabled. I could setup everything using TLS 1.2 on the ldaps port 636. Only for the authentication on directory server (which is configured correctly), the authentication did not work. I have seen message in LDAP log like this: ``` [04/Dec/2019:07:32:08.887004358 +0000] conn=120 op=-1 fd=65 closed - SSL peer had some unspecified issue with the certificate it received. [04/Dec/2019:07:32:08.896911103 +0000] conn=121 fd=65 slot=65 SSL connection from x.x.x.83 to x.x.x.84 [04/Dec/2019:07:32:08.897859410 +0000] conn=121 op=-1 fd=65 closed - Peer using unsupported version of security protocol. [04/Dec/2019:07:32:08.899690296 +0000] conn=122 fd=65 slot=65 SSL connection from x.x.x.83 to x.x.x.84 ``` To solve this problem, I configured the LDAP server using no SSL on port 389. This works fine. But, I think, the problem should be solved by Gluu team. Hope, this helps you ....

Hi. What Daniel says is correct - that may be one of the causes why authentication fails, when LDAPS is used. To quickly confirm it's the cause, edit `/etc/gluu/conf/ox-ldap.properties` file by commenting next lines out, as shown below: ``` #ssl.trustStoreFile: /etc/certs/opendj.pkcs12 #ssl.trustStorePin: QoOtWnoHZdbAqfnYOV78LA== #ssl.trustStoreFormat: pkcs12 ``` Then restart "oxauth" service. That will disable certificate verification. As a more secure solution, consider adding your LDAP server's certificate (the server itself, not root CA's) to `/etc/certs/opendj.pkcs12` truststore. Hyunwoo Kim, could you try to check whether it's the cause in your case?

Thank you for your answers. I will not close the ticket. However, I will test it and leave a post. We will close the ticket when we come to a conclusion.

Here is the test I did. I use Ping Identity Directory Server (version 6.0.1.2) I have configured LDAPS with a self-sign certificate. Then I added my LDAP from the Configure-Manage Authentication-Manage LDAP Authentication menu. 1. Bind DN: cn = directory manager 2. Max connections: 1000 3. Primary Key: uid 4. Local Primary Key: uid 5. Server: Port: {LDAPServer Hostname}: 636 6. Base DN: ou = people, c = kr 7. Change Bind Password: Save password value 8. Use SSL: Enable 9. Click the Active button 10. Test Connection: Success First, configure as above and set "Default Arc" to LDAP that I added in "Default Authentication Method". After that, authentication failed when trying to log in with ID / PW from OIDC-linked Web Page. (ID / PW is the user information in the LDAP that I registered. Ex} uid=user.1,ou=people,c=kr / password) The next test was to disable Use SSL and change 636 Port to 389 Port. Test Connection was successful. However, Login also failed with Authentication Fail. The access log of LDAP registered by me is normally recorded in both tests. (I can see "Bind Success" message in Log) Finally, we will test the content guided by Aliaksandr Samuseu. We will inform you of the result by Post. Thanks to read.

Additional test content. First I added opendj.crt to the TrustStore that my LDAP uses between SSL communications. The result is still an Authentication Fail. Next, I commented out three lines starting with ssl. ~ In /etc/gluu/conf/gluu-ldap.properties. After that, I restarted the Gluu Server, and after verifying the authentication, Authentication Fail also occurred. Find out if there's another way. Thanks to read.....

I went through various tests. Importantly, I need to use the Cache Refresh feature to use additional LDAP. Thank you for the many answers.