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.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland