(reopening here after mis-posting to the devel list) Hello,
I am using SSSD with NIS via the proxy id_provider and auth_provider (full conf below). I hoped that SSSD's cache would work around the sandboxing of systemd's logind that won't, by default, allow outgoing connections to the provider (see https://github.com/systemd/systemd/issues/7074).
User and credential lookup works fine and I can log in remotely via ssh. However, immediately after auth, at session setup-time, pam_systemd.so calls logind, which calls getpwuid(), which in turn causes a NIS lookup that hangs because of the sandbox. Failure of pam_systemd.so also means I can't login via the GUI.
I was hoping that SSSD's cache, which is up-to-date because of the immediately preceding auth, would be used instead of the NIS lookup. My alternative right now is to specifically disable that sandbox, as described in the link above, but I'd rather understand this completely and perhaps avoid that.
I'm on Ubuntu 18.04, with sssd 1.16.1.
sssd.conf: [sssd] services = nss, pam config_file_version = 2 domains = my.domain.name
[nss] filter_groups = root filter_users = root reconnection_retries = 3 cache_first = true
[pam] reconnection_retries = 3 pam_verbosity = 3 offline_failed_login_attempts = 3 offline_failed_login_delay = 1 # increased this in hopes of fixing the issue. Nope... pam_id_timeout = 35 cache_first = true
[domain/my.domain.name] id_provider = proxy auth_provider = proxy proxy_lib_name = nis proxy_pam_target = none cache_credentials = true # increased this in hopes of fixing the issue. Nope... cached_auth_timeout = 30 # Tried with and without enumeration. No difference. enumerate = true
The relevant PAM file -- /etc/pam.d/common-session. In my tests via ssh was included via /etc/pam.d/sshd: session [default=1] pam_permit.so session requisite pam_deny.so session required pam_permit.so session optional pam_umask.so session required pam_unix.so session optional pam_sss.so # if I comment or skip the next line I get clean ssh logins, but still failing GUI logins. session optional pam_systemd.so
nsswitch.conf: passwd: compat systemd sss group: compat systemd sss shadow: compat sss gshadow: files hosts: files mdns4_minimal [NOTFOUND=return] dns myhostname networks: files protocols: db files services: db files ethers: db files rpc: db files sudoers: files
getent output getent passwd testuser: testuser:$6$salted_hashed_password.:1100:100::/home/testuser:/bin/bash
getent -s sss passwd testuser: testuser:*:1100:100::/home/testuser:/bin/bash
getent -s sss shadow testuser: <no output>
On Tue, Jun 04, 2019 at 12:21:43PM -0000, manuel.nuno.melo@gmail.com wrote:
(reopening here after mis-posting to the devel list) Hello,
I am using SSSD with NIS via the proxy id_provider and auth_provider (full conf below). I hoped that SSSD's cache would work around the sandboxing of systemd's logind that won't, by default, allow outgoing connections to the provider (see https://github.com/systemd/systemd/issues/7074).
User and credential lookup works fine and I can log in remotely via ssh. However, immediately after auth, at session setup-time, pam_systemd.so calls logind, which calls getpwuid(), which in turn causes a NIS lookup that hangs because of the sandbox. Failure of pam_systemd.so also means I can't login via the GUI.
I was hoping that SSSD's cache, which is up-to-date because of the immediately preceding auth, would be used instead of the NIS lookup. My alternative right now is to specifically disable that sandbox, as described in the link above, but I'd rather understand this completely and perhaps avoid that.
I'm on Ubuntu 18.04, with sssd 1.16.1.
sssd.conf: [sssd] services = nss, pam config_file_version = 2 domains = my.domain.name
[nss] filter_groups = root filter_users = root reconnection_retries = 3 cache_first = true
[pam] reconnection_retries = 3 pam_verbosity = 3 offline_failed_login_attempts = 3 offline_failed_login_delay = 1 # increased this in hopes of fixing the issue. Nope... pam_id_timeout = 35 cache_first = true
[domain/my.domain.name] id_provider = proxy auth_provider = proxy proxy_lib_name = nis proxy_pam_target = none cache_credentials = true # increased this in hopes of fixing the issue. Nope... cached_auth_timeout = 30 # Tried with and without enumeration. No difference. enumerate = true
The relevant PAM file -- /etc/pam.d/common-session. In my tests via ssh was included via /etc/pam.d/sshd: session [default=1] pam_permit.so session requisite pam_deny.so session required pam_permit.so session optional pam_umask.so session required pam_unix.so session optional pam_sss.so # if I comment or skip the next line I get clean ssh logins, but still failing GUI logins. session optional pam_systemd.so
nsswitch.conf: passwd: compat systemd sss group: compat systemd sss shadow: compat sss
Since nis is handled by SSSD I think you can replace 'compat' with 'files' here. To be on the safe side I would also put 'sss' before 'systemd' so that it reads:
passwd: files sss systemd group: files sss systemd shadow: files
If you have any 'compat' specific entries like +/-(user|group) in /etc/passwd or /etc/group this of course won't work anymore. In this case you can try to put 'sss' first.
HTH
bye, Sumit
gshadow: files hosts: files mdns4_minimal [NOTFOUND=return] dns myhostname networks: files protocols: db files services: db files ethers: db files rpc: db files sudoers: files
getent output getent passwd testuser: testuser:$6$salted_hashed_password.:1100:100::/home/testuser:/bin/bash
getent -s sss passwd testuser: testuser:*:1100:100::/home/testuser:/bin/bash
getent -s sss shadow testuser:
<no output> _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Thanks so much for the input, Sumit. I still can't login, but I think I'm getting closer to the root cause. I now see that with my configuration I wasn't really using SSSD yet, as resolution was being done by 'compat' -- which would itself query NIS.
As you suggested, I replaced 'compat' with 'files' in nsswitch.conf, and bumped the sss priority.
But now I believe my problem lies with 'proxy_pam_target': I had set it to 'none' following my initial reading of the configuration posted in https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o... (apparently, the only other attempt at doing SSSD+NIS described online). But, as also stated there, 'none' is no real keyword and PAM was looking for an /etc/pam.d/none target.
Correct me if I'm wrong, but I think I'll need to create a PAM target that calls something like auth required pam_nis.so ... only that Ubuntu doesn't ship a pam_nis.so and I may have to compile one myself.
Is there any other way to get a NIS authentication from SSSD? My NIS server provides all the required info -- user info + hashed password -- in the passwd database (see the getent result above), so it seems possible.
Thanks once more.
I finally got it (almost) working! Instead of finding a pam_nis.so to do the authentication I decided to rely on pam_unix.so, which already knows how to do it. However, in order for this to work, I had to somehow provide the passwords to pam_unix.so. SSSD can't do it as it clobbers the password field (with an asterisk, by default). So I configured: 1- the NIS server to send the passwd and shadow maps separately; 2- nsswitch.conf to load the passwd and group maps via SSSD but the shadow via nis; 3- SSSD to replace the password field in passwd with 'x' instead of '*' (the pwfield option), so that pam_unix.so interprets it as 'look in the shadow map'; 4- proxy_pam_target to point to a custom target 'sssd-nis' with contents: auth requisite pam_unix.so nullok_secure
SSSD can now cache the id lookups and the auth attempts. Communication with the NIS server only happens at auth time.
The only thing not working: if I block communication to the NIS server (by iptables) and then try to ssh into the NIS client machine I get: testuser@machine password: Authenticated with cached credentials. Authentication failed.
It seems the cache works, but then something breaks... I added some logs below over the relevant 2-second auth failure period. Thanks for the help!
# syslog: sssd[12810]: do_ypcall: clnt_call: RPC: Unable to send; errno = Operation not permitted sssd[12810]: YPBINDPROC_DOMAIN: Domain not bound
# auth.log: sshd[13434]: pam_sss(sshd:auth): User info message: Authenticated with cached credentials. sshd[13434]: pam_sss(sshd:auth): authentication success; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.xxx.xxx user=testuser Failed password for testuser from 192.168.xxx.xxx port 50400 ssh2 sshd[13434]: fatal: Access denied for user testuser by PAM account configuration [preauth]
# sssd_pam.log [sss_cmd_get_version] (0x0200): Received client version [3]. [sss_cmd_get_version] (0x0200): Offered version [3]. [sss_parse_name_for_domains] (0x0200): name 'testuser' matched without domain, user is testuser [sss_parse_name_for_domains] (0x0200): name 'testuser' matched without domain, user is testuser [sss_dp_get_reply] (0x0010): The Data Provider returned an error [org.freedesktop.sssd.Error.DataProvider.Offline] [cache_req_common_dp_recv] (0x0040): CR #13: Data Provider Error: 3, 5, Failed to get reply from Data Provider [pam_dp_process_reply] (0x0200): received: [9 (Authentication service cannot retrieve authentication info)][my.domain.name] [pam_reply] (0x0200): pam_reply called with result [9]: Authentication service cannot retrieve authentication info. [sysdb_set_entry_attr] (0x0200): Entry [name=testuser@my.domain.name,cn=users,cn=my.domain.name,cn=sysdb] has set [cache, ts_cache] attrs. [pam_reply] (0x0200): pam_reply called with result [0]: Success. [pam_reply] (0x0200): blen: 48 [client_recv] (0x0200): Client disconnected!
# sssd_my.domain.name.log: [dp_get_account_info_handler] (0x0200): Got request for [0x3][BE_REQ_INITGROUPS][name=testuser@my.domain.name] [get_initgr] (0x0040): getpwnam failed [6]: No such device or address [proxy_account_info] (0x0040): proxy returned UNAVAIL error, going offline! [dp_get_account_info_handler] (0x0200): Got request for [0x3][BE_REQ_INITGROUPS][name=testuser@my.domain.name] [sbus_server_init_new_connection] (0x0200): Entering. [sbus_server_init_new_connection] (0x0200): Adding connection 0x55aadbd89ab0. [sbus_server_init_new_connection] (0x0200): Got a connection [proxy_client_register] (0x0200): Proxy client [5] connected
And it's done! All I had to do was to fix my common-account to bypass pam_unix if pam_sss was successful. In my case pam_sss was already in there, only further down the stack. Just had to move it up and adapt the return behavior. This is my final common-account:
# moved to here account [success=2 default=ignore] pam_sss.so account [success=1 new_authtok_reqd=done default=ignore] pam_unix.so account requisite pam_deny.so account required pam_permit.so account sufficient pam_localuser.so # was here # account [default=bad success=ok user_unknown=ignore] pam_sss.so
I hope this helps someone. But beware: a proper solution like LDAP+Kerberos IS the right way to go.
sssd-users@lists.fedorahosted.org
-
Manuel Melo -
manuel.nuno.melo＠gmail.com
-
Sumit Bose