Created attachment 916874 [details]
Description of problem:
When you decide to perform advanced configuration and enable LDAP authentication, it is not possible to test LDAP connection. If you click on "Test LDAP Connection" button on the second "LDAP Configuration" page, you will get a warning message saying "Could not verify the Base DN. Would you like to continue?" even though Base DN is set up properly.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Run your own in-memory LDAP server. I use the one from UnboundID and run it with the following command:
./in-memory-directory-server --baseDN "dc=jboss,dc=org" --port 10389 --ldifFile ldap-config.ldif --additionalBindDN uid=admin,ou=system --additionalBindPassword secret --accessLogToStandardOut --ldapDebugLogToStandardOut
2. Run the installer and enter correct LDAP settings:
Directory Server: http://localhost:10389
Distinguished Name (DN): uid=admin,ou=system
DN Password: secret
Base DN: dc=jboss,dc=org
3. Click on the "Test LDAP Connection" button.
The warning message mentioned above. And the following server output:
[09/Jul/2014:17:37:15 +0200] CONNECT conn=0 from="127.0.0.1:60405" to="127.0.0.1:10389"
[09/Jul/2014:17:37:15 +0200] BIND REQUEST conn=0 op=0 msgID=1 version=3 dn="uid=admin,ou=system" authType="SIMPLE"
[09/Jul/2014:17:37:15 +0200] BIND RESULT conn=0 op=0 msgID=1 resultCode=0 etime=1.208
[09/Jul/2014:17:37:15 +0200] CONNECT conn=1 from="127.0.0.1:60406" to="127.0.0.1:10389"
[09/Jul/2014:17:37:15 +0200] BIND REQUEST conn=1 op=0 msgID=1 version=3 dn="uid=admin,ou=system" authType="SIMPLE"
[09/Jul/2014:17:37:15 +0200] BIND RESULT conn=1 op=0 msgID=1 resultCode=0 etime=0.170
[09/Jul/2014:17:37:15 +0200] SEARCH REQUEST conn=1 op=1 msgID=2 base="dc=jboss,dc=org" scope=2 filter="(dc=jboss,dc=org)" attrs="ALL"
[09/Jul/2014:17:37:15 +0200] SEARCH RESULT conn=1 op=1 msgID=2 resultCode=0 etime=1.476 entriesReturned=0
Notice that there is no warning message about missing base DN. It would look like this:
SEARCH RESULT conn=3 op=1 msgID=2 resultCode=32 diagnosticMessage="Unable to perform the search because base entry 'dc=jboss,dc=or' does not exist in the server." etime=0.163 entriesReturned=0
No warning message because it is possible to connect to the LDAP server.
It is only a warning message and when you decide to continue, the installation will finish successfully. However, it is possible that I miss something and I do not set up LDAP server properly. In that case the warning message should provide more detailed information.
I've tried this and was able to reproduce.
Our check searches the Base DN for entries and if there are no entries we warn the user that we cannot verify the Base DN (entriesReturned=0).
Perhaps this warning is incorrect, but we are not sure of the use case of having an empty Base DN.
Created attachment 922155 [details]
Miles, the warning message is shown even if there are some entries in the directory server. I think this is a problem with the filter. The one entered by a user on LDAP Configuration page should be used. Or maybe the best option would be not to use any filter at all if it is possible.
Thank you for providing the LDIF files.
I've updated the way the ldap validator should search for the basedn, and it should now be able to verify the basedn from UnBoundID.
This doesn't seem to be working correctly for me in the latest builds.
Tom, I have just tried it and the connection test works in both (BPMS and BRMS) installers of version 6.1.0 DR3. I have also added a test for this to our test suite and the connection test itself passes. However, the whole test fails because of another bug 1147939.
I was testing using the .ldif from here: https://mojo.redhat.com/docs/DOC-977872
The current installer reported that the Base DN couldn't be verified when using the following settings:
Base DN: ou=People,dc=jboss,dc=org
Filter type: Username Attribute
Username Filter: uid
As I see it, this should pass validation. Am I incorrect here? Regardless, I have implemented a more robust check which passes our existing tests and also passes the situation above :)
1147939 is resolved for future builds.
Tom, you are right. I have only tested the base DN of the LDAP server but in this specific case base DN means user context. So this issue is not fixed in DR3. Thank you for pointing that out.
The new check should work on many more situations. It takes into account the filter and the recursive search fields correctly as well.
Thomas, it was a very good idea to distinguish between testing user search and testing the connection itself.
Verified on BPMS & BRMS 6.1.0 DR4