Bug 1443442

Summary:	Ldap authentication without ldap groups keeps trying to connect to the ldap to pull groups
Product:	Red Hat CloudForms Management Engine	Reporter:	Felix Dewaleyne <fdewaley>
Component:	Appliance	Assignee:	Joe Vlcek <jvlcek>
Status:	CLOSED DUPLICATE	QA Contact:	Matt Pusateri <mpusater>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	5.7.0	CC:	abellott, dajohnso, dclarizi, fdewaley, jhardy, jvlcek, mpusater, obarenbo
Target Milestone:	GA
Target Release:	cfme-future
Hardware:	All
OS:	All
Whiteboard:	auth:miqldap:openldap
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-10-09 17:52:24 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	CFME Core	Target Upstream Version:
Embargoed:

Description Felix Dewaleyne 2017-04-19 09:33:51 UTC

Description of problem:
Ldap authentication without ldap groups keeps trying to connect to the ldap to pull groups

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

How reproducible:
all the time in customer setup

Steps to Reproduce:
1.configure a openldap server for authentication
2.configure 5.7.1.3 to authenticate users against a local group and not pull group info
3.

Actual results:
during authentication the worker will keep trying to bind to the ldap to create the user. 

Expected results:
the ldap user is able to log in

Additional info:
during troubleshooting the user tried to enable "get groups from ldap", then disabled it again. their setup is from an updated cfme to 5.7.1.3 - it was updated from a previous release. Their setup requires to use a local group and not ldap groups.

Comment 4 Felix Dewaleyne 2017-06-14 10:44:26 UTC

there is a possible workaround to this issue :

if you insert the full dn of a user this allows login without fetching groups from LDAP. For this to be possible, the input field maxlength for the user needs to be extended to 100. it seems only the html element enforces the length. 

Sample value used :

dn=thisisauserwithalongusername,ou=personalusers,ou=thisismyou,dc=mycompanyname,dc=com

Comment 5 Joe Vlcek 2017-06-26 13:41:04 UTC

(In reply to Felix Dewaleyne from comment #4)
> there is a possible workaround to this issue :
> 
> if you insert the full dn of a user this allows login without fetching
> groups from LDAP. For this to be possible, the input field maxlength for the
> user needs to be extended to 100. it seems only the html element enforces
> the length. 
> 
> Sample value used :
> 
> dn=thisisauserwithalongusername,ou=personalusers,ou=thisismyou,
> dc=mycompanyname,dc=com

I spoke with the UI team group managerm Dan Clarizio. Dan is not inclined to
make this change to the UI and would rather we address it in the back end.

I have not been able to reproduce this.

Is the issue that the user can log in but unexplained message are being observed
in the log files?

Can we get all the .log files under vmdb/log that show the problem?

The way this is supposed to work is the group must exists in CFME database.
Please confirm the group the customer expects the user to be associated with
already exists. If it doesn't the group needs to be manually created.

Comment 6 Felix Dewaleyne 2017-07-19 08:42:25 UTC

(In reply to Joe Vlcek from comment #5)
> (In reply to Felix Dewaleyne from comment #4)
> > there is a possible workaround to this issue :
> > 
> > if you insert the full dn of a user this allows login without fetching
> > groups from LDAP. For this to be possible, the input field maxlength for the
> > user needs to be extended to 100. it seems only the html element enforces
> > the length. 
> > 
> > Sample value used :
> > 
> > dn=thisisauserwithalongusername,ou=personalusers,ou=thisismyou,
> > dc=mycompanyname,dc=com
> 
> I spoke with the UI team group managerm Dan Clarizio. Dan is not inclined to
> make this change to the UI and would rather we address it in the back end.
> 
> I have not been able to reproduce this.
> 
> Is the issue that the user can log in but unexplained message are being
> observed
> in the log files?
> 
> Can we get all the .log files under vmdb/log that show the problem?
> 
> The way this is supposed to work is the group must exists in CFME database.
> Please confirm the group the customer expects the user to be associated with
> already exists. If it doesn't the group needs to be manually created.

are you certain that you are not pulling group authentication from your ldap? For the purpose of the test, it is better if you can create a ldap user that does not have a group at all or a group that doesn't exist in Cloudforms because it doesn't tie to the management of cloudforms - aka a setup where ldap is supposed to not pull group info on the user at all. "get groups from ldap" *must* be disabled.

Comment 7 Joe Vlcek 2017-08-21 13:31:47 UTC

Yes I am certain that I am not pulling groups from LDAP.

Comment 8 Joe Vlcek 2017-10-09 17:52:24 UTC

Based on the logs in this case I strongly suspect the underlying cause to this issue is that same as: https://bugzilla.redhat.com/show_bug.cgi?id=1442791, which has been fixed.

I am going to mark this a CLOSED/DUPLICATE of 1442791
A fix for BZ1442791 has been made in PR:
https://github.com/ManageIQ/manageiq/pull/15661

If it is felt this is not the correct course of action please reopen and provide the information requested in the case, that being:

...
Hi,

my colleagues also ask to confirm that the group in use currently exists in cloudforms : "The way this is supposed to work is the group must exists in CFME database. Please confirm the group the customer expects the user to be associated with already exists. If it doesn't the group needs to be manually created."

I will likely need to collect new data - this case is getting old, are you still using 4.2 ?

Kind regards,
Félix
...

*** This bug has been marked as a duplicate of bug 1442791 ***