[Freeipa-users] HBAC access denied, all AD groups not detected

[Jakub Hrozek]

On Tue, Dec 08, 2015 at 04:10:42PM -0600, Sauls, Jeff wrote:
> > Jakub Hrozek wrote:
> > 
> > On Mon, Dec 07, 2015 at 02:04:26PM -0600, Sauls, Jeff wrote:
> > > > Jakub Hrozek wrote:
> > > >
> > > > On Fri, Dec 04, 2015 at 02:03:04PM -0600, Sauls, Jeff wrote:
> > > > > Hello,
> > > > >
> > > > > We are having a problem with HBAC that appears to be related to
> > > > > group membership lookup.  I am testing with a new install on RHEL
> > > > > 7.2 with a cross-forest trust with AD.  When an AD user attempts
> > > > > to log into a client (RH 6.7 or 7.2) the "hbac_eval_user_element"
> > > > > can report a different number of groups each time and never seems to
> > contain the full list.
> > > > > For the testing account, running the 'id' command returns 153 groups.
> > > > > The ipa group "ad_admin" has setup to be able to log in anywhere,
> > > > > everyone else is denied.  With the default allow_all rule enabled,
> > > > > everything works as expected.  Any ideas on where I can look next?
> > > >
> > > > I assume the group membership is OK on the server, but not the
> > > > client? Can you enable debugging and also include the full logs from
> > > > the client after doing sss_cache -E on the client?
> > >
> > > I've done some more testing and installed a RHEL 6.6 client, the issue doesn't
> > occur there since it is not pulling in AD groups, it only shows the single POSIX
> > group.  The server is running 7.2 and I get the same issue logging into it.
> > 
> > To make sure I understand -- the group you expect to be returned on the server
> > is not either? So there is a consistent failure on the server as well?
> > 
> > (It's important to see where the failure is, the server and the client use
> > different methods to obtain the group memberships. The server talks directly to
> > the AD, the clients talk to the server)
> > 
> > >
> > > This is the log section for a login that failed due to "Access denied
> > > by HBAC rules"  http://pastebin.com/paiBjG96 It shows it failing with 112
> > groups, but I've had it pass at 113 and fail on another user at 66.
> > >
> > >
> 
> The server and client show the same symptoms. 

Ah, OK, then it sounds different from the other cases we've seen recently
and we need to fix the server first, because the clients read data from
the server.

If you can catch the failure with logs that update the cache (so sss_cache
-E was run before the id attempt), please go ahead and file a bug against
sssd. It would also be nice to list what groups are not displayed but
should be (or which work intermittently) and describe the hierarchy if
possible, at least the part that includes the faulty groups, so we can
set a similar environment locally.

> If I clear the cache on both and log into each, the number of groups can change between cache clearings.  The only group used in the HBAC rule "admin-access" is a POSIX group "ad_admins".  Ad_admins contains an external group with the AD user account in it.  I can't consistently repeat it nor find a pattern to the failure.
> 
> After many cache clears and reboots testing with the server, I've managed to get it into a failure state.  After the reboot, I successfully logged in with the AD account.  It showed [113] groups in the log.  I logged out and logged back in with the same account a few minutes later and was denied by HABC rules, the group count shows [71] for this session.  Logging in 30 minutes later still fails, but show [112] groups now.  On the client system, I cleared the cache and rebooted it, I'm able to log into it with the AD account and it shows [72] groups in the log.
> 
> -Jeff
> 
> 
> -- 
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project