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
Summary: Auth - External Auth - FreeIPA - User can still log in if their group is remo...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: Appliance
Version: 5.8.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: GA
: 5.9.0
Assignee: Joe Vlcek
QA Contact: Matt Pusateri
URL:
Whiteboard: auth:externalauth:freeipa:security
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-05-01 14:27 UTC by Matt Pusateri
Modified: 2018-03-01 13:12 UTC (History)
7 users (show)

Fixed In Version: 5.9.0.1
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-03-01 13:12:04 UTC
Category: ---
Cloudforms Team: CFME Core
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2018:0380 0 normal SHIPPED_LIVE Moderate: Red Hat CloudForms security, bug fix, and enhancement update 2018-03-01 18:37:12 UTC

Description Matt Pusateri 2017-05-01 14:27:19 UTC
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.

Comment 2 Joe Vlcek 2017-05-16 21:34:18 UTC
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

Comment 4 Joe Vlcek 2017-05-17 14:03:21 UTC
(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

Comment 5 Joe Vlcek 2017-06-05 19:09:27 UTC
Matt,

I was able to reproduce this.

I no longer need the credentials to the environment where you reproduce this.

JoeV

Comment 6 Joe Vlcek 2017-06-05 21:16:22 UTC
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

Comment 7 Joe Vlcek 2017-06-06 19:20:10 UTC
(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

Comment 8 Matt Pusateri 2017-06-06 19:23:33 UTC
Sounds good, should we add a doc note on this as well?

Comment 10 CFME Bot 2017-06-07 13:23:10 UTC
New commit detected on ManageIQ/manageiq-gems-pending/master:
https://github.com/ManageIQ/manageiq-gems-pending/commit/49587f73ab1ffe18b12539cf90f0bc09b03aa9aa

commit 49587f73ab1ffe18b12539cf90f0bc09b03aa9aa
Author:     Joe VLcek <jvlcek>
AuthorDate: Tue Jun 6 14:58:16 2017 -0400
Commit:     Joe VLcek <jvlcek>
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(+)

Comment 11 Matt Pusateri 2017-10-24 18:19:27 UTC
Verified on 5.9.0.2 ExternalAuth FreeIPA

Comment 12 Matt Pusateri 2018-01-12 19:25:24 UTC
Reopening at I just recreated this in 5.9.0.16

Comment 13 Joe Vlcek 2018-01-12 20:14:38 UTC
Matt,

Can you please PM me the credentials to your test bed and set them to not be auto-deleted?

Thank you, JoeV

Comment 15 Joe Vlcek 2018-01-15 14:16:05 UTC
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

Comment 16 Matt Pusateri 2018-01-15 14:45:24 UTC
Probably not, sorry. moving back to verified.

Comment 19 errata-xmlrpc 2018-03-01 13:12:04 UTC
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


Note You need to log in before you can comment on or make changes to this bug.