Description of problem: MIQ LDAP - OpenLDAP - Can't log in to self service UI. Need to check other auth providers (FreeIPA,AD) Version-Release number of selected component (if applicable): 5.8.0.7 Need to verify older versions. How reproducible: Steps to Reproduce: 1. Configure MIQ LDAP - OpenLDAP provider 2. Navigate to self-service UI and try to login. 3. Actual results: Can't login in Expected results: Should be able to login. Additional info: No error message is returned to user, webui just sits there like you've never hit enter or login button.
Created attachment 1265910 [details] EVM Log
Also a problem in 5.7.2.0
Matt, I just tried and was unable to reproduce this using the latest 5.8.0.11 and 5.7.2.1 builds. I tested with the users having a group with the privileged Role: "EvmGroup-super_administrator".
Couldn't reproduce on 5.8.0.11-beta2 Still need to test 5.7.2.1 build
So I don't think this is a blocker anymore, but I still can reproduce an edge case that fails. 1. What I did was configure MIQLDAP and checked "Get Groups from LDAP" I then logged in with several users that had varying roles. See screenshot. All users were able to log into both the classic UI and the SSUI. I then changed the authentication mode to Database and logged in with a db user. Then I enabled LDAP again but did not check "get groups from LDAP" Now I have two users ldapuser3 and ldapuser4 who cannot log into the SSUI. So there may be an edge case that fails. Both of those users are in a unique custom group " SR-APP-EPM-Membre-équipe" and have email addresses that are unique in that we have had bugs in the past that have failed for an apostrophe in the email and or mixed case in the email address. I'm not sure if these items are a contributing factor or not. JoeV hasn't been able to reproduce. And the bug isn't as severe as originally reported.
Created attachment 1273088 [details] User list for 5.8.0.11-beta2
I was unable to reproduce the failure Matt is still seeing. It works fine for me. So Matt and I will need to sync up to try to narrow down what's causing the failure he is seeing but I agree, this is an edge case and not a blocker. JoeV
Additional info, same server with "get groups from ldap" checked, all users failing to log in. Something weird going on, not sure if it's reconfiguration that's causing it. Even tried new private browser window in case it's some weird browser tab/cache issue. So now users that could log in before can't
(In reply to Matt Pusateri from comment #11) > Additional info, same server with "get groups from ldap" checked, all users > failing to log in. Something weird going on, not sure if it's > reconfiguration that's causing it. Even tried new private browser window in > case it's some weird browser tab/cache issue. So now users that could log > in before can't That doesn't sound at all like a CFME issue. It sounds more like a possible environmental issue. When you see the failures what do you see in the logs. And it always works for me. I am not observing any sporadic failures. JoeV
OK I'll take another look Matt. Can you please PM me the credentials to the VM where you are observing this failure? Also, if I remember correctly, aren't your users ldapuser3 and ldapuser4 special in some way, accent marks in email addresses or something? Thank you. JoeV
Thank you Matt. The log you provided will be helpful. Looks like a possible edge case. I'll investigate. JoeV
The other thing I've noticed is that several failed attempts prevents a valid user from logging in. I've had to get a new browser session to get the valid user to log in. This was with Chrome. Which may have made it look like no users could log in, depending on what order of users were tried.
(In reply to Matt Pusateri from comment #20) > The other thing I've noticed is that several failed attempts prevents a > valid user from logging in. I've had to get a new browser session to get > the valid user to log in. This was with Chrome. Which may have made it look > like no users could log in, depending on what order of users were tried. I just noticed this also. Although I find a new browser "Tab" will resume successful logins for valid credentials. We should track this issue in a new BZ as it will likely not be an auth issue but quite possibly be a SUI issue. JoeV
Matt, I have just reproduced the edge case you reported in commnet 8 with a user that has a unique custom character in their group name: "joev-ldap-égroup". On to identifying the needed fix. JoeV
I think the other thing that we might be hitting is this bug here: https://bugzilla.redhat.com/show_bug.cgi?id=1437682 Which would explain the intermittent nature of things. The fact that the bug referenced lists external auth is probably irrelevant b/c SSUI authenticates via the API. Let's say you have a user who's a member of two groups group foo who has rights to the SSUI and group bar that doesn't. When a user logs into the classic ui and is under group foo, then logs out and his current group is still foo. He can log into SSUI as he's in a group that has SSUI perms. But when the user logs into the the classic UI, and switches to group bar and logs out. His current group then becomes Bar and when he tries to log into the SSUI he fails b/c the bar group doesn't have perms. I've just witnessed this with FreeIPA and 5.8.0.12-rc1 Also I'm writing up a bug on not being able to switch groups in SSUI, even with two valid groups. Seems to be related to me, but maybe it's not.
GH PR https://github.com/ManageIQ/manageiq-ui-service/pull/724
Moving to ON_QA per Shevta request in Gitter.
Setting the 'requires_doc_text' flag to '-' in accordance with a discussion with Chris Pelland.
Moving the 'requires_doc_text' flag back to '+' after subsequent comments, and after reviewing the draft doc text.
On 5.9.0.2 I'm still seeing this fail with: "[----] W, [2017-10-17T14:19:12.192812 #13034:3ee2a84] WARN -- : MIQ(Authenticator::Ldap#groups_for) User Object has no objectSID" Looks like the user is authenticated.
Dear customer, The CloudForms team is reviewing the current CloudForms Bug(defect) backlog in order to target engineering efforts. We are closing any bugs for versions that no longer have an active errata stream or that have hit their age limit. We are committing to better management of the backlog as we move forward. If you have an bug that you are still able to reproduce on a current version of CloudForms please open a new bug. If you have any concerns about this, please let us know. Thanks and regards!