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