Matt, Can you PM me the creds were you are seeing this issue. Along with the creds for you AD. Thank you, JoeV
So test-user8 is not a member of user-group-ad which according to the logs is being evaluated. He's only a member of evmgroup-user So groups are not being retrieved or evaluated properly.
Works for me. I just successfully logged into <your appliance>/ui/service as test-user8
So in 5.7.2.1, test-user8 can't log into classic or SSUI, I'm guessing part of this is a problem with the users properties. Though that doesn't explain evaluating the wrong group.
I was just able to reproduce this on 5.8.0-14-rc3, the same box as above. I think the steps to reproduce are to log in with user who doesn't have perms. Then log in with a user who does Login with test-user5 same pwd as test-user8, test-user5 fails due to evmgroup-operator not have SSUI perms. Then test-user8 fails to login and has test-user5's group user-group-ad evaluated.
So I changed the title on this, test-user8 shouldn't be able to log in as evmgroup-user has no SSUI perms, But that authorization doesn't happen, as the wrong group is getting evaluated. Also I would argue that evmgroup-user should be allowed to log into SSU (RFE bug: https://bugzilla.redhat.com/show_bug.cgi?id=1452320)
Chris - Can you please take a look?
I think it is happening in prod, it just doesn't prevent users from logging in b/c SSUI has worked around it. I think it should be high, b/c it critical the way the API handles logins and is the basis for security. If the API is authorizing when it should be, that's a serious concern!
Tried to take a look at this. Tried https://10.8.199.225/ and the url didnt come up. Is there an environment I can look at this happening?
It'll have to be recreated, all our QE appliances are temporary.
Matt. Let me know if you get a appliance set up that this can be tested on.
I do not have an AD setup. It would be a lot easier if we had a environment or AD env set up that I could connect to in order to help diagnose .
Talk with your admins, there is most certainly a development AD environment for you to test against.
Setting priority / severity to "unspecified" to allow for this BZ to go back through triage.
Part of the reason it may not be hit in Prod, is that the SSUI team worked around this in code. If the backend is not evaluating authorization properly, I would argue that it is a high priority.
A Pivotal Tracker story has been created for this Bug: https://www.pivotaltracker.com/story/show/147234269
Chris Kacerguis deleted the linked story in Pivotal Tracker