Ticket #1097 (closed defect: invalid)

Opened 5 years ago

Last modified 5 years ago

Login as local (PAM) user does not work for ftpd when sssd is configured with LDAP-backend

Reported by: sgallagh Owned by: jzeleny
Priority: critical Milestone: SSSD 1.7.0
Component: PAM Version: 1.6.3
Keywords: Cc: pghmcfc
Blocked By: Blocking:
Sensitive: Tests Updated: no
Coverity Bug: Patch Submitted: no
Red Hat Bugzilla: 754170 Design link:
Feature Milestone:
Design review: Fedora test page:
Chosen: Candidate to push out:
Release Notes:
Temp mark:

Description (last modified by dpal) (diff)


Description of problem:
Login as local (PAM) user does not work when sssd is configured with

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Set up sssd to auth against ldap
2. Check that users can log in with ssh, pop3/imap (dovecot) and so on
3. Install pure-ftpd
4. Configure it to use PAM Auth

Actual results:
Local users can't log in

Expected results:
Local users should be able to log in

Additional info:

It is a hard to debug this problem
Sssd seems to auth the users fine:

Nov 14 14:01:22 poseidon pure-ftpd: pam_unix(pure-ftpd:auth): authentication
failure; logname= uid=0 euid=0 tty=pure-ftpd ruser=olen rhost=  user=olen
Nov 14 14:01:23 poseidon pure-ftpd: pam_sss(pure-ftpd:auth): authentication
success; logname= uid=0 euid=0 tty=pure-ftpd ruser=olen rhost= user=olen

But they still can't log in.
Client reports "login failed"

Fresh install of F16, so no old config-files should be present.

Auth is configured by authconfig.
Relevant PAM-files:


# Sample PAM configuration file for Pure-FTPd.
# Install it in /etc/pam.d/pure-ftpd or add to /etc/pam.conf

auth       required     pam_listfile.so item=user sense=deny file=/etc/ftpusers
auth       include      password-auth
auth       required     pam_shells.so
auth       required     pam_nologin.so

account    include      password-auth

password   include      password-auth

session    required     pam_loginuid.so
session    include      password-auth

/etc/pam.d/password-auth is a symlink to password-auth-ac

# 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 >= 500 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 < 500 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
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
session     required      pam_unix.so
session     optional      pam_sss.so

The weirdest thing is I have the exact same problem with both vsftpd AND
proftpd as well.

Changing pure-ftpd to auth directly to the LDAP-server works fine, and allows
users to log in.

Change History

comment:1 Changed 5 years ago by pghmcfc

  • Cc pghmcfc added
  • tests set to 0
  • upgrade set to 0
  • Tests Updated unset
  • Patch Submitted unset

comment:2 Changed 5 years ago by dpal

  • Owner changed from somebody to jzeleny
  • Description modified (diff)
  • Milestone changed from NEEDS_TRIAGE to SSSD 1.7.0

comment:3 Changed 5 years ago by dpal

  • Priority changed from major to critical

comment:4 Changed 5 years ago by jzeleny

  • Status changed from new to assigned

comment:5 Changed 5 years ago by jzeleny

I'm leaning towards closing this ticket, as it seems that it has nothing to do with SSSD. I tested this with ProFTP and it seems that the request for username never gets to SSSD (no mention about it in the log of NSS provider). I double checked the configuration, and everything else seems to be working fine - getent, sshd, su, ...

comment:6 Changed 5 years ago by jzeleny

  • Status changed from assigned to closed
  • Resolution set to invalid

comment:7 Changed 5 years ago by mkosek

  • Red Hat Bugzilla set to [https://bugzilla.redhat.com/show_bug.cgi?id=754170 754170]
Note: See TracTickets for help on using tickets.