On Суб, 25 мая 2024, Sam Morris wrote:
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.
Yeah, the issue here is not HBAC rules but rather the fact that SSSD
does not consider this user at all and thus escapes early.
Ok, so this might be solved then by Match?
Match
AllowGroups allow-ssh
Since it is a conditional keyword, it would not apply to all conditions,
so IPA users would not match by it but local ones would instead.
--
Sam Morris <[email protected]>
--
/ 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
