Bug 1117919 - LDAP connection test fails to verify Base DN
Summary: LDAP connection test fails to verify Base DN
Keywords:
Status: CLOSED EOL
Alias: None
Product: JBoss BRMS Platform 6
Classification: Retired
Component: Installer
Version: 6.0.2
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: DR4
: 6.1.0
Assignee: Miroslav Sochurek
QA Contact: Dominik Hanak
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-07-09 15:59 UTC by Tomas Livora
Modified: 2020-03-27 20:04 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-03-27 20:04:00 UTC
Type: Bug


Attachments (Terms of Use)
LDIF file (98 bytes, text/x-ldif)
2014-07-09 15:59 UTC, Tomas Livora
no flags Details
LDIF file (581 bytes, text/x-ldif)
2014-07-29 13:49 UTC, Tomas Livora
no flags Details

Description Tomas Livora 2014-07-09 15:59:49 UTC
Created attachment 916874 [details]
LDIF file

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):
BPMS/BRMS 6.0.2-GA

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.

Actual results:

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

Expected results:
No warning message because it is possible to connect to the LDAP server.

Additional info:
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.

Comment 2 Miles Tjandrawidjaja 2014-07-09 18:28:14 UTC
Hello,

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.

Comment 3 Tomas Livora 2014-07-29 13:49:50 UTC
Created attachment 922155 [details]
LDIF file

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.

Comment 4 Miles Tjandrawidjaja 2014-07-30 15:37:04 UTC
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.

https://code.engineering.redhat.com/gerrit/gitweb?p=installer-commons.git;a=commitdiff;h=b4b612d244d057b2bd08834a40a45c44ced8ae77

Comment 5 Thomas Hauser 2014-09-29 16:09:06 UTC
This doesn't seem to be working correctly for me in the latest builds.

Comment 6 Tomas Livora 2014-09-30 11:24:31 UTC
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.

http://git.app.eng.bos.redhat.com/git/jbossqe-installer.git/commit/?id=559ca1f8aadfa7ba4917c823fd332cc95ece0792

Comment 7 Thomas Hauser 2014-09-30 18:58:21 UTC
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
Recursive: No

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.

Comment 8 Tomas Livora 2014-10-01 09:25:53 UTC
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.

Comment 9 Thomas Hauser 2014-10-10 16:11:50 UTC
The new check should work on many more situations. It takes into account the filter and the recursive search fields correctly as well.

Comment 10 Tomas Livora 2014-10-22 13:12:46 UTC
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


Note You need to log in before you can comment on or make changes to this bug.