> 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 
> 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.  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.


Manage your subscription for the Freeipa-users mailing list:
Go to http://freeipa.org for more info on the project

Reply via email to