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.
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
(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.
(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.
Yes I am certain that I am not pulling groups from LDAP.
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 ***