Bug 754170
Summary: | Login as local (PAM) user does not work when sssd is configured with LDAP-backend | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Ola Thoresen <redhat> |
Component: | sssd | Assignee: | Jan Zeleny <jzeleny> |
Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 16 | CC: | jhrozek, jzeleny, mi, nalin, paul, sbose, sgallagh, ssorce, tmraz |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2011-12-06 15:50:03 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Ola Thoresen
2011-11-15 15:27:18 UTC
Your configuration's also using pam_shells.so. Just to eliminate it as a factor, can you paste in the output of "getent passwd $username" for an affected user, and the contents of your /etc/shells file? /etc/shells only contains: /sbin/nologin /bin/dash # getent passwd olen olen:*:500:500:Ola Thoresen:/home/nytt.no/olen:/bin/bash Commenting out auth required pam_shells.so from /etc/pam.d/pure-ftpd does not help Could it be that it is because you do not have /bin/bash in /etc/shells? No idea Will try to add that tomorrow. This is a server, completely re-installed with F16, so if /etc/shells is wrong, that is a problem with anaconda (or F16). I'll try to add /bin/bash to /etc/shells tomorrow, but as I said comment #2, commenting out that line from the pam-file does not help. I'm the proftpd maintainer and I'm seeing the same symptoms with proftpd. PAM config: #%PAM-1.0 session optional pam_keyinit.so force revoke auth required pam_listfile.so item=user sense=deny file=/etc/ftpusers onerr=succeed auth required pam_shells.so auth include password-auth account include password-auth session required pam_loginuid.so session include password-auth /etc/pam.d/password-auth: #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required pam_env.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 1000 quiet auth sufficient pam_sss.so use_first_pass auth required pam_deny.so account required pam_unix.so broken_shadow account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 1000 quiet account [default=bad success=ok user_unknown=ignore] pam_sss.so account required pam_permit.so password requisite pam_cracklib.so try_first_pass retry=3 type= password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok password sufficient pam_sss.so use_authtok password required pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so -session optional pam_systemd.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_sss.so Paul, what do you have in the /etc/shells? (In reply to comment #6) > Paul, what do you have in the /etc/shells? # cat /etc/shells /bin/sh /bin/bash /bin/dash /sbin/nologin Strangely, when I first tried this, /bin/sh and /bin/bash were missing - no idea how that happened as this was pretty much a clean install from the F16 DVD. I added back those two but it didn't make any difference. I've also tried running with SELinux in permissive mode and that didn't help either. Do you see anything related in the /var/log/secure? Is the user uid >= 1000? (In reply to comment #8) > Do you see anything related in the /var/log/secure? ==> /var/log/messages <== Nov 21 10:00:33 roary proftpd[23623]: 10.9.2.1 (10.9.2.1[10.9.2.1]) - FTP session opened. ==> /var/log/secure <== Nov 21 10:00:37 roary proftpd[23623]: 10.9.2.1 (10.9.2.1[10.9.2.1]) - USER phowarth: no such user found from 10.9.2.1 [10.9.2.1] to ::ffff:10.9.2.1:21 ==> /var/log/messages <== Nov 21 10:00:39 roary proftpd[23623]: 10.9.2.1 (10.9.2.1[10.9.2.1]) - FTP session closed. > Is the user uid >= 1000? $ getent passwd phowarth phowarth:*:1012:1012:Paul Howarth,,,,:/nis-home/phowarth:/bin/bash (don't be confused by /nis-home/ - we're using LDAP but not kerberos) This looks like some bad interaction between nss_sss and the ftp daemons. Reassigning to sssd. Upstream ticket: https://fedorahosted.org/sssd/ticket/1097 I made some investigation and my preliminary result is that this has nothing to do with SSSD. What happens is that SSSD correctly returns information about the user, but FTP server (tested with proftpd) doesn't receive it or something and auth fails with "user not found". No PAM communication was started. I will investigate this issue further and let you know what is going on. Paul, is proftpd using standard getpwnam() or similar glibc call to get user information from nsswitch? (In reply to comment #12) > I made some investigation and my preliminary result is that this has nothing to > do with SSSD. What happens is that SSSD correctly returns information about the > user, but FTP server (tested with proftpd) doesn't receive it or something and > auth fails with "user not found". No PAM communication was started. I will > investigate this issue further and let you know what is going on. > > Paul, is proftpd using standard getpwnam() or similar glibc call to get user > information from nsswitch? There are a bunch of different auth backends in proftpd and they all do their own thing, so there are calls to getpwnam() but it may not be the PAM backend that calls it. Anyway, I now have two F16 boxes with PAM/LDAP working with proftpd. I'm not completely sure what's fixed it but I suggest trying the following: In /etc/proftpd.conf: # If you use NIS/YP/LDAP you may need to disable PersistentPasswd PersistentPasswd off To debug PAM auth, also add: TraceLog /var/log/proftpd/trace.log Trace auth:10 pam:10 SELinux: I'm using selinux-policy-3.10.0-65.fc16 fresh out of koji; I'm pretty sure this isn't the fix for the problem, but it does fix some other systemd-related AVCs that were occurring on ftp login. Make sure the ftp_home_dir boolean is set. My sssd.conf (domain name changed to EXAMPLE.COM): [domain/default] ldap_id_use_start_tls = True cache_credentials = True ldap_search_base = dc=EXAMPLE,dc=COM krb5_realm = EXAMPLE.COM krb5_server = kerberos.example.com id_provider = ldap auth_provider = ldap chpass_provider = ldap ldap_uri = ldap://ldap.EXAMPLE.COM/ ldap_tls_cacertdir = /etc/openldap/cacerts [sssd] services = nss, pam config_file_version = 2 domains = default [nss] [pam] /etc/pam.d/password-auth: #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required pam_env.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 1000 quiet auth sufficient pam_sss.so use_first_pass auth required pam_deny.so account required pam_unix.so broken_shadow account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 1000 quiet account [default=bad success=ok user_unknown=ignore] pam_sss.so account required pam_permit.so password requisite pam_cracklib.so try_first_pass retry=3 type= password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok password sufficient pam_sss.so use_authtok password required pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so -session optional pam_systemd.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_sss.so (my UID is 1012) /etc/shells: /sbin/nologin /bin/dash /bin/bash /bin/sh /etc/nsswitch.conf: # # /etc/nsswitch.conf # # An example Name Service Switch config file. This file should be # sorted with the most-used services at the beginning. # # The entry '[NOTFOUND=return]' means that the search for an # entry should stop if the search in the previous entry turned # up nothing. Note that if the search failed due to some other reason # (like no NIS server responding) then the search continues with the # next entry. # # Valid entries include: # # nisplus Use NIS+ (NIS version 3) # nis Use NIS (NIS version 2), also called YP # dns Use DNS (Domain Name Service) # files Use the local files # db Use the local database (.db) files # compat Use NIS on compat mode # hesiod Use Hesiod for user lookups # [NOTFOUND=return] Stop searching if not found so far # # To use db, put the "db" in front of "files" for entries you want to be # looked up first in the databases # # Example: #passwd: db files nisplus nis #shadow: db files nisplus nis #group: db files nisplus nis passwd: files sss shadow: files sss group: files sss #hosts: db files nisplus nis dns hosts: files dns # Example - obey only what nisplus tells us... #services: nisplus [NOTFOUND=return] files #networks: nisplus [NOTFOUND=return] files #protocols: nisplus [NOTFOUND=return] files #rpc: nisplus [NOTFOUND=return] files #ethers: nisplus [NOTFOUND=return] files #netmasks: nisplus [NOTFOUND=return] files bootparams: nisplus [NOTFOUND=return] files ethers: files netmasks: files networks: files protocols: files rpc: files services: files netgroup: files sss publickey: nisplus automount: files ldap aliases: files nisplus I did some digging and in case of proftpd, the issue is most likely caused by PersistentPasswd not being off. If this option is left as default (on), the proftpd never asks nsswitch for the user information. As for vsftpd (and very likely pure-ftpd as well), the issue is caused by the shell not being available in /etc/shells. https://fedoraproject.org/wiki/Common_F16_bugs#bash-etc-shells Because there is no issue with SSSD or any other component, I'm closing this bug. |