Bug 1388722 - ldap authentication works for any string appended to correct password.
Summary: ldap authentication works for any string appended to correct password.
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: Appliance
Version: 5.7.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: GA
: 5.7.1
Assignee: Joe Vlcek
QA Contact: Matt Pusateri
URL:
Whiteboard: auth:ldap
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-10-26 03:11 UTC by amogh
Modified: 2017-03-16 19:53 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-03-16 19:53:06 UTC
Category: ---
Cloudforms Team: CFME Core
Target Upstream Version:


Attachments (Terms of Use)

Description amogh 2016-10-26 03:11:57 UTC
Description of problem:
ldap authentication works for any string appended to correct password.
e.g. if user correct password is : "redhat"

any string that starts with "redhatthisworks$%^&*&*" works fine.

Version-Release number of selected component (if applicable):
5.7.0.6-alpha3.20161019140041_ea8e259

How reproducible:
always

Steps to Reproduce:
1. configure the appliance for ldap auth server.
2. go to user groups, add new groups-> retrieve group from ldap 
3. specify the User to Look Up, username, and "password+anystring"
e.g if password is "redhat" enter "redhatthisworks^&^&^&"
4. click on retrieve, observe that groups are retrieved without any auth error.
5. select the user group and add it to appliance.
6. logout and login with ldapusername, and "ldappassword +any string" ldap user authentication works, which is not expected.

Actual results:
ldap authentication works for any string appended to correct password.

Expected results:
Authentication must fail with valid errors, for any wrong password.

Additional info:
only wrong password starting with "correct_password + any string" works, but not any other string pattern "any string + correct password + any string" or "any string+correct password" does not work, and auth fails with expected error messages.

Comment 4 Joe Vlcek 2017-01-13 19:19:36 UTC
I just tried and I am unable to reproduce this.

Can I access the system where this is being observed?

Comment 5 Joe Vlcek 2017-01-16 20:17:58 UTC
Amogh had sent me the below email, which provides an answer to the NEEDINFO.

---
Hi JoeV,

Not sure which version you are using. I think it would be good to check/reproduce this on 5.7.0.6-alpha3.20161019140041_ea8e259. and then check this on the latest build.

Use the same openldap setup/mojo that I provided you and try login with "ldaptest / ldaptestinvalidpass"


Thanks,
Amogh
---

Comment 6 Joe Vlcek 2017-01-16 20:27:07 UTC
I am marking this "CLOSED WORKSFORME".

I have been unable to reproduce this issue on 3 different builds.

cfme-vsphere-5.7.0.6-1.x86_64.vsphere.ova  from 19-Oct-2016
cfme-vsphere-5.7.0.17-1.x86_64.vsphere.ova from 19-Dec-2016
manageiq-vsphere-euwe-201701050200-c3ab503d03.ova from 05-Jan-2017

If it can be recreated please provide more data and reopen.

Thank you, JoeV

Comment 7 Matt Pusateri 2017-03-09 14:22:36 UTC
I just reproduced this with MIQ LDAP with OpenLDAP on 5.6.4.2.  It didn't happen with AD.

Comment 8 Matt Pusateri 2017-03-09 15:16:36 UTC
Also same behavior with External Auth and OpenLDAP

Comment 9 Joe Vlcek 2017-03-14 17:16:39 UTC
(In reply to Matt Pusateri from comment #8)
> Also same behavior with External Auth and OpenLDAP

Matt, Can you please PM me the credentials for the systems where you've reproduced this?

JoeV

Comment 11 Joe Vlcek 2017-03-16 19:21:03 UTC
Matt,

So I do observer the failure on your VM.

but

I am still unable to reproduce this on a fresh install of 5.6.4.2
I've tried both "Mode: LDAP" and "Mode: External (httpd)"

Also: Oddly the CFME code does not authenticate the password. It
relies on OpenLDAP to do it.

The handshake looks like this:

 CFME -> LDAP "is this username/password valid"
 LDPA -> CFME "yes or no"

So can you please try to validate the password with the trailing
characters directly on your LDAP server, take CFME out of the picture.

Please ping me to pair up on this exercise if you would like.

Although there does seem to be something odd going on I am not
able to reproduce it, which makes me think this is surely not
a blocker.

JoeV

Comment 12 Joe Vlcek 2017-03-16 19:53:06 UTC
Matt provided me with the credentials to the OpenLDAP he is using for testing.
I pointed Apache Directory Studio at both the "QE OpenLDAP" and "My OpenLDAP".

When attempting to verify a password on "My OpenLDAP" trailing characters are
not ignored and the password verification fails.

However when attempting to verify a password on "QE OpenLDAP" the trailing
characters are ignored and the password verification succeeds.

This test takes the CFME product out of the picture and it clearly shows
that the problem lies with the "QE OpenLDAP" server.

Matt and I both agree this bug can be closed.


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