On Fri, 24 May 2024, Sam Morris via FreeIPA-users wrote:
On 24/05/2024 13:07, Sam Morris via FreeIPA-users wrote:
On non-IPA clients I'm using AllowUsers/AllowGroups to restrict
which local users are able to SSH into a system.
On IPA clients I am using HBAC to control the same for IPA users.
But what's the best way to control which local users can SSH in to
an IPA client?
Sorry, I forgot to add "... without disrupting access to the IPA
client for IPA users".
It looks like I could modify the ipausers group to be a POSIX group,
and then put 'AllowGroups ipausers' into sshd_config. That way all
local users would be denied, and all IPA suers would be allowed,
with pam_sss.so later controlling access based on HBAC.
I found this in the FreeIPA 2.2.0 release notes:
"On new installations the default users group, ipausers, is now
non-POSIX to speed up user enumeration in SSSD. To make ipausers a
POSIX group run ipa group-mod –posix ipausers."
So it seems like this is a safe and normal thing to do. I wonder if
there are any references to the user enumeration performance issue in
SSSD? My own domain doesn't have many users, but I'm also considering
doing this at work, and I'd like to understand the sorts of issues it
might cause.
We made 'ipausers' group non-POSIX due to memberof computational
complexity. If you have several thousands users, every time you'd add a
new user, it gets added to ipausers group and then that group's
membership has to be re-calculated, leading to evaluation of data and
potential update of thousands entries. This slows down 'ipa user-add',
for example, substantially. For POSIX 'ipausers' group this also means
constant churn of querying LDAP and retrieving all user entries for each
SSSD client because they'd need to resolve this group on the client as
it is a POSIX one.
So we ended up with fixing the latter, making ipausers non-POSIX group
and solving 'all clients must chase all user data every time a new user
is added' worst case scenario.
I don't understand why you cannot handle the access control through HBAC
rules. These days glibc supports group merging feature (since glibc
2.24, around 2016), so you can have a group in IPA and a group in
/etc/group, then include local user into that local group. With
appropriate configuration, SSSD will add local user into that IPA group
membership locally and thus you can use that IPA group in HBAC rules.
See https://sourceware.org/glibc/wiki/Proposals/GroupMerging and man
page for nsswitch.conf(5), 'merge' ACTION for 'group' database.
--
/ 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]
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
