On Sat, 2024-05-25 at 12:46 +0100, Sam Morris via FreeIPA-users wrote: > On Sat, 2024-05-25 at 11:01 +0300, Alexander Bokovoy via FreeIPA- > users > wrote: > > On Пят, 24 мая 2024, Sam Morris via FreeIPA-users wrote: > > > On 24/05/2024 15:52, Alexander Bokovoy via FreeIPA-users wrote: > > > > 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". > > > > > > > > [...] > > > > > > > > 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.> > > > > > > Thanks for that, I haven't used group merging yet. But, hmm, I'm > > > not > > > sure it will help here... > > > > > > My goals are: > > > > > > * Local user access to be controlled by group membership > > > * IPA user access to be controlled via IPA HBAC > > > * IPA user access to not be controlled by group membership > > > > I don't know how you would get that working. What I suggest instead > > is > > to have both local and IPA users access done via IPA HBAC. This is > > possible to achieve without modifying any PAM or SSH daemon setup. > > > > [...] > > > > Your IPA allow-ssh POSIX group will have no members in IPA. > > Your local allow-ssh POSIX group will have local users that need to > > be > > logged in on a specific host. > > > > Your HBAC rule for allow-ssh would include IPA allow-ssh group. > > That > > is > > enough -- the rest is done by SSSD on the specific system. > > Oh, I didn't know that HBAC rules could apply to local users! > > I've now got an HBAC rule that has sshd added to it as well as my > empty > IPA POSIX group. And it applies to all hosts. I've not yet added my > local user (id 1000) to it, but the local user can still log in. > > I'm on Fedora 40 and I've got the standard authselect sssd profile > selected and the "enable-with-files-access-provider" feature enabled. > This gives me the following PAM configuration: > > --- /etc/pam.d/sshd > account required pam_sepermit.so > account required pam_nologin.so > account include password-auth > > --- /etc/pam.d/password-auth > account required pam_unix.so > account sufficient pam_usertype.so issystem > account [default=bad success=ok user_unknown=ignore] pam_sss.so > #account required pam_deny.so > account required pam_permit.so > > By uncommenting and moving the pam_deny line around I can see that > it's > pam_sss that's letting my local user in, even though they are not a > member of any groups added to any HBAC rules. > > At debug_level 4 these messages are printed to sssd_pam.log: > > (2024-05-25 12:39:49): [pam] [pam_cmd_acct_mgmt] (0x0100): [CID#11] > entering pam_cmd_acct_mgmt > (2024-05-25 12:39:49): [pam] [pam_print_data] (0x0100): [CID#11] > command: SSS_PAM_ACCT_MGMT > (2024-05-25 12:39:49): [pam] [pam_print_data] (0x0100): [CID#11] > domain: not set > (2024-05-25 12:39:49): [pam] [pam_print_data] (0x0100): [CID#11] > user: local > (2024-05-25 12:39:49): [pam] [pam_print_data] (0x0100): [CID#11] > service: sshd > (2024-05-25 12:39:49): [pam] [pam_print_data] (0x0100): [CID#11] tty: > ssh > (2024-05-25 12:39:49): [pam] [pam_print_data] (0x0100): [CID#11] > ruser: not set > (2024-05-25 12:39:49): [pam] [pam_print_data] (0x0100): [CID#11] > rhost: ::1 > (2024-05-25 12:39:49): [pam] [pam_print_data] (0x0100): [CID#11] > authtok type: 0 (No authentication token available) > (2024-05-25 12:39:49): [pam] [pam_print_data] (0x0100): [CID#11] > newauthtok type: 0 (No authentication token available) > (2024-05-25 12:39:49): [pam] [pam_print_data] (0x0100): [CID#11] > priv: 1 > (2024-05-25 12:39:49): [pam] [pam_print_data] (0x0100): [CID#11] > cli_pid: 33797 > (2024-05-25 12:39:49): [pam] [pam_print_data] (0x0100): [CID#11] > child_pid: 0 > (2024-05-25 12:39:49): [pam] [pam_print_data] (0x0100): [CID#11] > logon name: local > (2024-05-25 12:39:49): [pam] [pam_print_data] (0x0100): [CID#11] > flags: 0
Aha, at debug_level = 5 this is logged just after the above: (2024-05-25 15:05:00): [pam] [sss_parse_name_for_domains] (0x0200): [CID#32] name 'local' matched without domain, user is local (2024-05-25 15:05:00): [pam] [sss_parse_name] (0x0200): [CID#32] Domain not provided! (2024-05-25 15:05:00): [pam] [sss_parse_name_for_domains] (0x0200): [CID#32] name 'local' matched without domain, user is local (2024-05-25 15:05:00): [pam] [pam_reply] (0x0200): [CID#32] blen: 8 (2024-05-25 15:05:00): [pam] [pam_reply] (0x0200): [CID#32] Returning [10]: User not known to the underlying authentication module to the client So it looks like pam_sss is returning 'user_unknown' rather than allow/deny. -- Sam Morris <s...@robots.org.uk> -- _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org 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/freeipa-users@lists.fedorahosted.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
