RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1669407 - MAN: Document that PAM stack contains the systemd-user service in the account phase in RHEL-8
Summary: MAN: Document that PAM stack contains the systemd-user service in the account...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: sssd
Version: 8.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: 8.0
Assignee: SSSD Maintainers
QA Contact: sssd-qe
lmcgarry
URL:
Whiteboard:
Depends On: 1682305
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-01-25 07:17 UTC by Madhuri
Modified: 2020-05-02 19:05 UTC (History)
17 users (show)

Fixed In Version: sssd-2.2.0-13.el8
Doc Type: Bug Fix
Doc Text:
.The `ldap_user_authorized_service` description has been updated in the `sssd-ldap` man page The Pluggable authentication modules (PAM) stack has been changed in RHEL 8. For example, the `systemd` user session now starts a PAM conversation using the `systemd-user` PAM service. This service now recursively includes the `system-auth` PAM service, which may include the `pam_sss.so` interface. This means that the SSSD access control is always called. You should be aware of this change when designing access control rules for RHEL 8 systems. For example, you can add the `systemd-user` service to the allowed services list. Please note for some access control mechanisms, such as IPA HBAC or AD GPOs, the `systemd-user` service has been added to the allowed services list by default and you do not need to take any action. The `sssd-ldap` man page has been updated to include this information.
Clone Of:
Environment:
Last Closed: 2019-11-05 22:34:01 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github SSSD sssd issues 4912 0 None closed MAN: Document that PAM stack contains the systemd-user service in the account phase in recent distributions 2021-01-18 00:39:32 UTC
Red Hat Product Errata RHSA-2019:3651 0 None None None 2019-11-05 22:34:15 UTC

Description Madhuri 2019-01-25 07:17:35 UTC 
Description of problem: User authentication fails when ldap_access_order is set to authorized_service


Version-Release number of selected component (if applicable):
sssd-2.0.0-38.el8.x86_64

How reproducible:
Always

Steps to Reproduce:
1.Add a LDAP testuser with objectclass authorizedServiceObject and attribute authorizedService: sshd 
# testuser1, People, example.com
dn: uid=testuser1,ou=People,dc=example,dc=com
objectClass: posixAccount
objectClass: account
objectClass: authorizedServiceObject
objectClass: top
authorizedService: sshd
cn: testuser1
uid: testuser1
uidNumber: 10001
gidNumber: 10001
homeDirectory: /home/testuser1
loginShell: /bin/bash

2. Configure sssd.conf with ldap_access_order = authorized_service
[sssd]
config_file_version = 2
domains = LDAP
services = nss, pam
sbus_timeout = 30

[nss]
filter_groups = root
filter_users = root

[pam]
debug_level = 0xFFF0


[domain/LDAP]
ldap_search_base = dc=example,dc=com
debug_level = 9
id_provider = ldap
ldap_uri = ldaps://host-8-243-42.host.centralci.eng.rdu2.redhat.com:636
ldap_tls_cacert = /etc/openldap/certs/cacert.pem
access_provider = ldap
ldap_access_order = authorized_service
ldap_user_authorized_service = authorized_service

3. Clear the sssd cache.

4. Check the authetication of user,
[root@host-8-246-254 ~]# ssh -l testuser1 localhost
testuser1@localhost's password: 
Connection closed by ::1 port 22

Authentication failed.

5. From log,
Jan 25 01:41:10 client-4704 sshd[21932]: pam_sss(sshd:auth): authentication success; logname= uid=0 euid=0 tty=ssh ruser= rhost=::1 user=testuser1
Jan 25 01:41:10 client-4704 sshd[21932]: pam_sss(sshd:account): system info: [Authorized service attribute missing, access denied]
Jan 25 01:41:10 client-4704 sshd[21932]: pam_sss(sshd:account): Access denied for user testuser1: 6 (Permission denied)
Jan 25 01:41:10 client-4704 sshd[21932]: Failed password for testuser1 from ::1 port 40688 ssh2
Jan 25 01:41:10 client-4704 sshd[21932]: fatal: Access denied for user testuser1 by PAM account configuration [preauth]

From log also first getting authentication success and
later getting access denied for user

5. After commenting 'ldap_access_order = authorized_service and ldap_user_authorized_service = authorized_service' and
adding ldap_access_filter = (authorizedService=sshd) in sssd.conf, user authetication is successful.
[sssd]
config_file_version = 2
domains = LDAP
services = nss, pam
sbus_timeout = 30

[nss]
filter_groups = root
filter_users = root

[pam]
debug_level = 0xFFF0


[domain/LDAP]
ldap_search_base = dc=example,dc=com
debug_level = 9
id_provider = ldap
ldap_uri = ldaps://host-8-243-42.host.centralci.eng.rdu2.redhat.com:636
ldap_tls_cacert = /etc/openldap/certs/cacert.pem
access_provider = ldap
#ldap_access_order = authorized_service
#ldap_user_authorized_service = authorized_service
ldap_access_filter = (authorizedService=sshd)

[root@host-8-246-254 ~]# ssh -l testuser1 localhost
testuser1@localhost's password: 
Activate the web console with: systemctl enable --now cockpit.socket

Last failed login: Fri Jan 25 01:41:10 EST 2019 from ::1 on ssh:notty
There were 3 failed login attempts since the last successful login.
Last login: Fri Jan 25 01:07:37 2019 from ::1
Could not chdir to home directory /home/testuser1: No such file or directory
id: cannot find name for group ID 10001
[testuser1@host-8-246-254 /]$ exit
logout
Connection to localhost closed.


Actual results:
Authentication failing with ldap_access_order and successful with ldap_access_filter.

Expected results:
Authentication should successful with ldap_access_order also.
Comment 2 Sumit Bose 2019-01-25 07:24:24 UTC 
(In reply to Madhuri from comment #0)
...
> 
> 5. After commenting 'ldap_access_order = authorized_service and
> ldap_user_authorized_service = authorized_service' and
> adding ldap_access_filter = (authorizedService=sshd) in sssd.conf, user
> authetication is successful.

Since according to the working filter rule the LDAP attribute is called 'authorizedService' I'd like to suggest to try with

    ldap_access_order = authorized_service
    ldap_user_authorized_service = authorizedService

HTH

bye,
Sumit
Comment 3 Madhuri 2019-01-25 08:42:43 UTC 
I tried with the above changes,
still, authentications failing,

for log, 
Jan 25 03:40:09 client-4704 sshd[22169]: pam_sss(sshd:auth): authentication success; logname= uid=0 euid=0 tty=ssh ruser= rhost=::1 user=testuser1
Jan 25 03:40:09 client-4704 sshd[22169]: Accepted password for testuser1 from ::1 port 40724 ssh2
Jan 25 03:40:09 client-4704 systemd[22172]: pam_sss(systemd-user:account): system info: [Authorized service attribute has no matching rule, access denied]
Jan 25 03:40:09 client-4704 systemd[22172]: pam_sss(systemd-user:account): Access denied for user testuser1: 6 (Permission denied)
Jan 25 03:40:09 client-4704 sshd[22169]: pam_systemd(sshd:session): Failed to create session: Start job for unit user failed with 'failed'
Jan 25 03:40:09 client-4704 sshd[22169]: pam_unix(sshd:session): session opened for user testuser1 by (uid=0)
Jan 25 03:40:09 client-4704 sshd[22169]: error: PAM: pam_open_session(): System error
Jan 25 03:40:09 client-4704 sshd[22177]: Received disconnect from ::1 port 40724:11: disconnected by user
Jan 25 03:40:09 client-4704 sshd[22177]: Disconnected from user testuser1 ::1 port 40724
Comment 4 Sumit Bose 2019-01-25 08:56:18 UTC 
Hi,

can you try to add another value 'systemd-user' to the authorizedService attribute.

HTH

bye,
Sumit
Comment 5 Madhuri 2019-01-25 09:13:16 UTC 
Added new user,
# testuser2, People, example.com
dn: uid=testuser2,ou=People,dc=example,dc=com
objectClass: posixAccount
objectClass: account
objectClass: authorizedServiceObject
objectClass: top
authorizedService: systemd-user
cn: testuser2
uid: testuser2
uidNumber: 100012
gidNumber: 100012
homeDirectory: /home/testuser2
loginShell: /bin/bash

Tried to authenticate with that user after clearing sssd cache,
but authentication failed,

from log,
Jan 25 04:11:07 client-4704 sshd[22323]: pam_sss(sshd:auth): authentication success; logname= uid=0 euid=0 tty=ssh ruser= rhost=::1 user=testuser2
Jan 25 04:11:07 client-4704 sshd[22323]: pam_sss(sshd:account): system info: [Authorized service attribute has no matching rule, access denied]
Jan 25 04:11:07 client-4704 sshd[22323]: pam_sss(sshd:account): Access denied for user testuser2: 6 (Permission denied)
Jan 25 04:11:07 client-4704 sshd[22323]: Failed password for testuser2 from ::1 port 40752 ssh2
Jan 25 04:11:07 client-4704 sshd[22323]: fatal: Access denied for user testuser2 by PAM account configuration [preauth]
Comment 7 Sumit Bose 2019-01-25 09:51:18 UTC 
(In reply to Madhuri from comment #5)
> Added new user,
> # testuser2, People, example.com
> dn: uid=testuser2,ou=People,dc=example,dc=com
> objectClass: posixAccount
> objectClass: account
> objectClass: authorizedServiceObject
> objectClass: top
> authorizedService: systemd-user

I meant to add another value not replace it, it should look like:

    authorizedService: systemd-user
    authorizedService: sshd

HTH

bye,
Sumit

> cn: testuser2
> uid: testuser2
> uidNumber: 100012
> gidNumber: 100012
> homeDirectory: /home/testuser2
> loginShell: /bin/bash
> 
> Tried to authenticate with that user after clearing sssd cache,
> but authentication failed,
> 
> from log,
> Jan 25 04:11:07 client-4704 sshd[22323]: pam_sss(sshd:auth): authentication
> success; logname= uid=0 euid=0 tty=ssh ruser= rhost=::1 user=testuser2
> Jan 25 04:11:07 client-4704 sshd[22323]: pam_sss(sshd:account): system info:
> [Authorized service attribute has no matching rule, access denied]
> Jan 25 04:11:07 client-4704 sshd[22323]: pam_sss(sshd:account): Access
> denied for user testuser2: 6 (Permission denied)
> Jan 25 04:11:07 client-4704 sshd[22323]: Failed password for testuser2 from
> ::1 port 40752 ssh2
> Jan 25 04:11:07 client-4704 sshd[22323]: fatal: Access denied for user
> testuser2 by PAM account configuration [preauth]
Comment 8 Jakub Hrozek 2019-01-25 10:12:15 UTC 
I thought we've been over this on IRC. This is a sort of a systematic change in RHEL-8 as requested in https://bugzilla.redhat.com/show_bug.cgi?id=1643928. IPA added the systemd-user PAM service to the HBAC list by default in https://pagure.io/freeipa/issue/7831
Comment 9 Jakub Hrozek 2019-01-25 10:15:38 UTC 
(Sorry, I hit save changes too soon)

I'm not sure we should do anything on the deamon side. Permitting the service or adding it to the filter unconditionally might work, but seems like a hack, because unlike with HBAC (or GPOs) we can't presume much about the structure of the server-side rules.

At least for the time being, we could ask our docs writers to add a note about this for the RHEL-8 documentation and maybe add a note to the man page?
Comment 10 Jakub Hrozek 2019-01-25 10:20:47 UTC 
Also maybe some leapp content for the sake of the upgrades might be nice..
Comment 11 Madhuri 2019-01-25 13:00:41 UTC 
(In reply to Sumit Bose from comment #7)
> (In reply to Madhuri from comment #5)
> > Added new user,
> > # testuser2, People, example.com
> > dn: uid=testuser2,ou=People,dc=example,dc=com
> > objectClass: posixAccount
> > objectClass: account
> > objectClass: authorizedServiceObject
> > objectClass: top
> > authorizedService: systemd-user
> 
> I meant to add another value not replace it, it should look like:
> 
>     authorizedService: systemd-user
>     authorizedService: sshd
> 
> HTH
> 
> bye,
> Sumit
> 
> > cn: testuser2
> > uid: testuser2
> > uidNumber: 100012
> > gidNumber: 100012
> > homeDirectory: /home/testuser2
> > loginShell: /bin/bash
> > 
> > Tried to authenticate with that user after clearing sssd cache,
> > but authentication failed,
> > 
> > from log,
> > Jan 25 04:11:07 client-4704 sshd[22323]: pam_sss(sshd:auth): authentication
> > success; logname= uid=0 euid=0 tty=ssh ruser= rhost=::1 user=testuser2
> > Jan 25 04:11:07 client-4704 sshd[22323]: pam_sss(sshd:account): system info:
> > [Authorized service attribute has no matching rule, access denied]
> > Jan 25 04:11:07 client-4704 sshd[22323]: pam_sss(sshd:account): Access
> > denied for user testuser2: 6 (Permission denied)
> > Jan 25 04:11:07 client-4704 sshd[22323]: Failed password for testuser2 from
> > ::1 port 40752 ssh2
> > Jan 25 04:11:07 client-4704 sshd[22323]: fatal: Access denied for user
> > testuser2 by PAM account configuration [preauth]

With this change authentication is successful.
Comment 12 Madhuri 2019-01-25 13:03:39 UTC 
(In reply to Jakub Hrozek from comment #8)

sorry for not reading carefully,
After getting the successful run with beaker,
will update the bug and close it.
Comment 13 Jakub Hrozek 2019-01-28 08:15:50 UTC 
(In reply to Madhuri from comment #12)
> (In reply to Jakub Hrozek from comment #8)
> 
> sorry for not reading carefully,
> After getting the successful run with beaker,
> will update the bug and close it.

Thank you for the test run, do you think it would made sense to open a documentation request and/or a ticket about amending the man page?
Comment 14 Amith 2019-01-28 08:59:56 UTC 
(In reply to Jakub Hrozek from comment #13)
> (In reply to Madhuri from comment #12)
> > (In reply to Jakub Hrozek from comment #8)
> > 
> > sorry for not reading carefully,
> > After getting the successful run with beaker,
> > will update the bug and close it.
> 
> Thank you for the test run, do you think it would made sense to open a
> documentation request and/or a ticket about amending the man page?

Yes.. it makes perfect sense.
Comment 18 Jakub Hrozek 2019-01-28 20:20:14 UTC 
Upstream ticket:
https://pagure.io/SSSD/sssd/issue/3932
Comment 26 Michal Zidek 2019-08-18 21:20:27 UTC 
master: 820151f3813f08c704cb87a99988fe39f9f48a8d
Comment 28 Madhuri 2019-08-22 10:43:52 UTC 
Verified with

[root@ci-vm-10-0-146-233 ~]# rpm -qa sssd
sssd-2.2.0-16.el8.x86_64

From man page of sssd-ldap

       ldap_user_authorized_service (string)
           If access_provider=ldap and ldap_access_order=authorized_service, SSSD will use the presence of the
           authorizedService attribute in the user's LDAP entry to determine access privilege.

           An explicit deny (!svc) is resolved first. Second, SSSD searches for explicit allow (svc) and finally for
           allow_all (*).

           Please note that the ldap_access_order configuration option must include “authorized_service” in order for the
           ldap_user_authorized_service option to work.

           Some distributions (such as Fedora-29+ or RHEL-8) always include the “systemd-user” PAM service as part of the
           login process. Therefore when using service-based access control, the “systemd-user” service might need to be
           added to the list of allowed services.

           Default: authorizedService


from above, marking this bug as Verified.
Comment 30 errata-xmlrpc 2019-11-05 22:34:01 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2019:3651
Comment 33 lmcgarry 2020-04-17 15:07:02 UTC 
Hi Tomas,

I have changed the text to a bug fix and indicated what was changed.

Can you confirm this is ok?

Thanks
Louise
Comment 34 Tomas Halman 2020-04-22 10:34:04 UTC 
(In reply to lmcgarry from comment #33)
> Hi Tomas,
> 
> I have changed the text to a bug fix and indicated what was changed.
> 
> Can you confirm this is ok?
> 
> Thanks
> Louise

The text looks good to me. I just fixed one small typo (The doc text started with "." so I moved it to the end of the sentence).
Thank you.

Tom
Note You need to log in before you can comment on or make changes to this bug.