On Fri, Nov 01, 2019 at 10:57:50AM +0200, Alexander Bokovoy wrote: > On pe, 01 marras 2019, Kimmo Rantala via FreeIPA-users wrote: > > Hello all. > > We encountered a situation where ID views broke authentication... or at > > least we think so. > > The situation was as follows: > > Customer insisted that they have to have a "hardened" SSH config like > > this: AllowGroups staff. This staff (GID 500) group was/is a local > > group in 100+ machines. They did this "to control who can login" > > despite me and a couple of my colleagues trying to tell them > > (sometimes with strong words attached) that FreeIPA's HBAC rules will > > handle this very thing but to no avail. Of course this resulted into > > situation where the IPA users could not login because sshd prevented > > it. > CentOS 7.6 should have support for group merging already. So you can > make 'staff' group in IPA and have membership for it merged at a client > side. > > From nsswitch.conf(5): > merge [SUCCESS=merge] is used between two database entries. When a > group is located in the first of the two group entries, > processing will continue on to the next one. If the group is > also found in the next entry (and the group name and GID are > an exact match), the member list of the second entry will be > added to the group object to be returned. Available since glibc > 2.24. Note that merging will not be done for getgrent(3) nor > will duplicate members be pruned when they occur in both > entries being merged. > > RHEL 7's glibc has it since 2.17-168. > > > > We came up with a solution where we would create this ID-view: > > Anchor to override: res_staff > > Group name: staff > > GID: 500 > > and apply that to those 100+ clients. We didn't like the idea to abuse > > ID-views like this especially after the client insisted that the > > res_staff group should be a nested group like this: > > > dev-team -> res_staff + <insert a bunch of other groups> > > ops-team -> res_staff + <insert a bunch of other groups> > > . > > . > > . > > (I have to admit that after seeing and hearing about this, I considered > > telling my bosses to outright fire this customer) > I think all this can work with group merging instead of overrides. > > > For a while everything worked but then logins started to fail. Upon > > examining, it turned out that id command would no longer return the > > full list of groups of a user and the "hardened" sshd config killed the > > login. After we cleared the SSSD caches and restarted SSSD, the logins > > would work for a while and id command would return all the groups where > > user belonged to. It is also worth mentioning that this client has a > > fetish for nested groups so it is not uncommon to see groups 4-5 "deep" > > and it is a general mess. > > > > Also: No AD trust here. Just ye olde IPA domain. The good thing is that > > the environment is extremely homogeneous. All the IPA servers CentOS > > 7.6 and the clients CentOS 7.x. > > > > We have the logs with debug level 6 but before I'll send them for > > examination, I would like to ask that is there a limitation/bug in the > > ID-views functionality where it fails when the anchor group is nested? > It might be something that SSSD doesn't implement here. I think > overrides are applied at the last stage when all POSIX groups are > already collected. Though, I'd let Sumit to comment -- it is SSSD > specifics, not FreeIPA here.
Hi, nesting is important when evaluation the group memberships of a user, but the override are applied to the groups itself, so both are independent. I agree with Alexander the group merging should be used for local groups. bye, Sumit > > > -- > / Alexander Bokovoy > Sr. Principal Software Engineer > Security / Identity Management Engineering > Red Hat Limited, Finland _______________________________________________ FreeIPA-users mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/[email protected]
