Bug 682755 - Not able to login to rhq as ldap user
Summary: Not able to login to rhq as ldap user
Alias: None
Product: RHQ Project
Classification: Other
Component: Core Server
Version: 4.0.0.B02
Hardware: Unspecified
OS: Unspecified
high vote
Target Milestone: ---
: ---
Assignee: Simeon Pinder
QA Contact: Corey Welton
Depends On:
Blocks: rhq4 gwt-admin-usersroles
TreeView+ depends on / blocked
Reported: 2011-03-07 13:48 UTC by Sunil Kondkar
Modified: 2011-10-06 19:48 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed:

Attachments (Terms of Use)

Description Sunil Kondkar 2011-03-07 13:48:46 UTC
Description of problem:

I entered below LDAP config properties in rhq Administration->System Settings page. 

After saving the settings, i tried to login to rhq as LDAP users which is failing. The login screens displays the message 'The username or password provided does not match our records.'

The server log does not display any error.

Below are the details:

1. Server: Redhat Directory Server 8.2

2. OS: RHEL 5.4

3. LDAP URL-> ldap://

4. Username: cn=Directory manager

5. Search Base: dc=rajantest

6. Login Property: uid

7. Password=Redhat123

8. Search Filter: objectclass=*

9. Group Search Filter: objectclass=groupofuniquenames

10. Group Member Filter: uniquemember
11. LDAP Enabled = yes

12. SSL = No

LDAP Users:

1. sunil1/Redhat123
2. vijay1/Redhat123

Version-Release number of selected component (if applicable):

Build# 1074  (Version: 4.0.0-SNAPSHOT Build Number: 77ad7aa)

How reproducible:

Steps to Reproduce:

1. Login to RHQ
2. Navigate to Administration->System Settings page.
3. enter the above LDAP config properties
4. Click on 'Save' button
5. Logout and login as LDAP user (Ex: sunil1/Redhat123)
6. The login screens displays the message 'The username or password provided does not match our records.'
Actual results:
Not able to login to rhq as ldap user

Expected results:
ldap user login should be successful.

Additional info:

1. LDAP user is not able to login but the ldap groups are displays in 'LDAP Groups' tab of Administration->roles.

2. Used same LDAP configuration settings on jon241 build. I was able to login as ldap user. (

Comment 1 Simeon Pinder 2011-03-07 15:17:11 UTC
Curious. A few questions:
i)Does the login problem still happen when the searchFilter field is empty?
ii)Were there any other login failures in the console?

If the searchFilter change doesn't change the results, please download the TestLdapSettings tool(from the following link) to the server box and run through the test cases with the test credentials to see if there is any additional additional debug behavior:


I just tested that ldap auth/authz is still working for me on a recent local build of master.

Comment 2 Sunil Kondkar 2011-03-08 13:01:00 UTC
I tried with keeping searchFilter field empty but still not able to login as ldap user.

There are no errors in server log.

Next, i downloaded the TestLdapSettings tool and tested the LDAP query simulation with the same LDAP config properties which is passing. 

Below are the test results with TestLdapSettings tool:

STEP-1:TESTING: Attempting to bind to server:ldap://
 with user 'cn=Directory manager' and password entered.

STEP-1:PASS: LDAP bind credentials are correct. Successfully connected to 'ldap://'.
 This means the LDAP Bind credentials for the RHQ Server authentication/authorization requests to ldap server are correct.

STEP-2:TESTING: To validate the test user the following LDAP filtered component will be used to find matching users:

STEP-2:PASS: The test user 'sunil1' was succesfully located, and the following userDN will be used in authorization check:

STEP-2:PASS: The user 'sunil1' was succesfully authenticated using userDN 'uid=sunil1,dc=rajantest' and password provided.
*Note: the loginProperty must match the loginProperty listed in dn: for the user. It is the DN that RHQ will lookup and use.

STEP-3:TESTING: This ldap filter (objectclass=groupofuniquenames) will be used to locate ALL available LDAP groups

STEP-3:TESTING: Using Group Search Filter '(objectclass=groupofuniquenames)', 1022 ldap group(s) were located.
STEP-3:PASS: Listing a few(<=10) of the ldap groups located: 
{id=rajangroup665, description=rajangroup665 test, name=rajangroup665}
{id=rajangroup691, description=rajangroup691 test, name=rajangroup691}
{id=rajangroup855, description=rajangroup855 test, name=rajangroup855}
{id=rajangroup487, description=rajangroup487 test, name=rajangroup487}
{id=rajangroup675, description=rajangroup675 test, name=rajangroup675}
{id=rajangroup931, description=rajangroup931 test, name=rajangroup931}
{id=rajangroup151, description=rajangroup151 test, name=rajangroup151}
{id=rajangroup637, description=rajangroup637 test, name=rajangroup637}
{id=rajangroup684, description=rajangroup684 test, name=rajangroup684}
{id=rdutesters, description=, name=rdutesters}


STEP-4:TESTING: about to do ldap search with filter 
 to locate groups that test user IS authorized to access.

STEP-4:TESTING: Using Group Search Filter '(&(objectclass=groupofuniquenames)(uniquemember=uid=sunil1,dc=rajantest))', 1 ldap group(s) were located.
STEP-4:PASS: Listing a few of the ldap groups located: 
{id=testgroup3, description=testgroup3, name=testgroup3}


COMPLETED:PASS: The current settings, for successful steps, should be correct to enter into your RHQ server.

 When you encounter failures, warnings or other unexpected results you should use an external LDAP search utility to check that the generated filters return the expected LDAP results.

Comment 3 Simeon Pinder 2011-03-08 17:13:17 UTC
Using the test tool from the box that's reporting a problem, the ldap tests all passed.  This means that auth an authz should both be working within the UI itself as well.

Which browser is this behavior happening on? 

Have you cleared the cache recently?  I'd blow away the cache and restart the browser to see if that changes the behavior.  I'd also be curious if this behavior is still happening with newer builds?

Comment 4 Sunil Kondkar 2011-03-09 09:46:29 UTC
Tested on below browser version:

Firefox 3.6.3
Firefox 3.6.13
Firefox 3.0.18

Tested with clearing the cache. But no luck.

Also tested with below latest build and observed the same behaviour, not able to login as lDAP user.

Build# 1083 ( Version: 4.0.0-SNAPSHOT Build Number: fbbf83c)

Comment 5 Simeon Pinder 2011-03-10 16:37:39 UTC
I have finally seen this with a fresh DB in master 3/10/11, but it does not happen every time. I am uncertain what the exact reproduction steps are.  Most of the time ldap login works as expected.  There appears to be a failed ldap registration attempt that is happening.  When you get the described error, if you log back in as rhqadmin then delete the 'user' that you were attempting to log in via ldap you can work around this problem.  This appears to be an intermittent registration issue.  I'll continue to track this down.   

Sunil, in your login steps you don't describe what happens at the registration screen.  Do you even see a registration screen? If not that is part of the problem here.

Comment 6 Simeon Pinder 2011-03-10 19:10:21 UTC
Tracked it down. Found a race condition that was most likely exposed by recent performance enhancements and change of HTTP Get/Post for security reasons.  This is why the behavior was inconsistent.
Fixed with commit : 5b1b49ced83

Putting this to ON_QA for verification.

Comment 7 Sunil Kondkar 2011-04-21 06:11:13 UTC
Verified on build#1175 (Version: 4.0.0-SNAPSHOT Build Number: a90faf9)

After saving the LDAP config properties in rhq Administration->System Settings
page, i entered the LDAP user credentials on the login screen. It displayed the registration screen and i was able to login as LDAP user successfully.

Marking as verified.

Comment 8 Corey Welton 2011-05-24 01:13:56 UTC
Bookkeeping - closing bug - fixed in recent release.

Comment 9 Corey Welton 2011-05-24 01:13:56 UTC
Bookkeeping - closing bug - fixed in recent release.

Comment 10 Corey Welton 2011-05-24 01:13:56 UTC
Bookkeeping - closing bug - fixed in recent release.

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