Red Hat Bugzilla – Bug 1447064
Auth - External Auth - FreeIPA - User can still log in if their group is removed from LDAP server and they've logged in before
Last modified: 2018-03-01 08:12:04 EST
Description of problem: Auth - External Auth - FreeIPA - User can still log in if their group is removed from LDAP server and they've logged in before. Version-Release number of selected component (if applicable): 5.8.0.12-rc1 How reproducible: Steps to Reproduce: 1. Configure External Auth and get groups from LDAP 2. Create a user give him a valid group 3. Let him log in/log out 4. Remove his valid group from LDAP 5. user can still log in. Actual results: user can still log in. Expected results: User's group is now invalid, he/she shouldn't be able to log in. Additional info: Invalidating the SSSD cache has no effect, so it's not a SSSD cache issue.
Matt, You report seeing this when using IPA (configuring ext auth with the appliance_console) Are you also able to reproduce this with MiqLdap (Mode: LDAP) or when using SSSD/LDAP configured manually as described here: http://manageiq.org/docs/reference/latest/auth/ldap ? or do both of these configurations work? Thanks, JoeV
(In reply to Matt Pusateri from comment #3) > I'm not sure at this point. I'll have to test. Matt Please PM me the credentials to the environment where you reproduce this. Thank you. JoeV
Matt, I was able to reproduce this. I no longer need the credentials to the environment where you reproduce this. JoeV
The default SSSD cache timeout is 90 minutes. The group membership changes made on the IPA server dashboard will be reflected after the default cache timeout. I am going to consult with the IdM team to determine what the negative ramifications could be of greatly reducing the cache timeout. Perhaps this issue could be solved by documenting the default behavior with instructions for how to customize the SSSD cache timeout for those so inclined. I will update this BZ once I hear back frm the IdM team. JoeV
(In reply to Joe Vlcek from comment #6) > The default SSSD cache timeout is 90 minutes. The group membership changes > made on the IPA server dashboard will be reflected after the default cache > timeout. > > I am going to consult with the IdM team to determine what the negative > ramifications could be of greatly reducing the cache timeout. > > Perhaps this issue could be solved by documenting the default behavior with > instructions for how to customize the SSSD cache timeout for those so > inclined. > > I will update this BZ once I hear back frm the IdM team. > > JoeV The IdM team replied with the following regarding the impact to MiQ of reducing entry_cache_timeout, from the default of of 90 minutes, to a few seconds, or few a minutes: "For Web applications, the performance impact should be really low since the user attributes and group membership gets consulted only during logon, not afterwards (unlike typical operations on the OS)." I will put together a PR to timeout the cache after 10 minutes, which seems very reasonable but not overkill and is consistent with what we document for external auth via manually configured SSSD/LDAP
Sounds good, should we add a doc note on this as well?
https://github.com/ManageIQ/manageiq-gems-pending/pull/202
New commit detected on ManageIQ/manageiq-gems-pending/master: https://github.com/ManageIQ/manageiq-gems-pending/commit/49587f73ab1ffe18b12539cf90f0bc09b03aa9aa commit 49587f73ab1ffe18b12539cf90f0bc09b03aa9aa Author: Joe VLcek <jvlcek@redhat.com> AuthorDate: Tue Jun 6 14:58:16 2017 -0400 Commit: Joe VLcek <jvlcek@redhat.com> CommitDate: Tue Jun 6 20:47:46 2017 -0400 Add 600 second cache timeout to pickup directory changes. https://bugzilla.redhat.com/show_bug.cgi?id=1447064 lib/gems/pending/appliance_console/external_httpd_configuration.rb | 3 +++ 1 file changed, 3 insertions(+)
Verified on 5.9.0.2 ExternalAuth FreeIPA
Reopening at I just recreated this in 5.9.0.16
Matt, Can you please PM me the credentials to your test bed and set them to not be auto-deleted? Thank you, JoeV
MattP, Can you please confirm that you waited the required 10minutes for the required 10minutes for the cache to timeout? Please see the description of the PR that addresses this issue: https://github.com/ManageIQ/manageiq-gems-pending/pull/202#issue-233994932 and please confirm that you waited over 10 minutes for the cache to timeout. Thank you. JoeV
Probably not, sorry. moving back to verified.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2018:0380