This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 754170 - Login as local (PAM) user does not work when sssd is configured with LDAP-backend
Login as local (PAM) user does not work when sssd is configured with LDAP-bac...
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: sssd (Show other bugs)
16
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Jan Zeleny
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-11-15 10:27 EST by Ola Thoresen
Modified: 2011-12-06 10:50 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-12-06 10:50:03 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Ola Thoresen 2011-11-15 10:27:18 EST
Description of problem:
Login as local (PAM) user does not work when sssd is configured with LDAP-backend

Version-Release number of selected component (if applicable):
sssd-1.6.3-1.fc16.x86_64
pure-ftpd-1.0.32-2.fc16.x86_64


How reproducible:
Always

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:

/etc/pam.d/pure-ftpd
#%PAM-1.0

# 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 onerr=succeed
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


/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 >= 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 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



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.
Comment 1 Nalin Dahyabhai 2011-11-15 11:00:00 EST
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?
Comment 2 Ola Thoresen 2011-11-15 11:23:48 EST
/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
Comment 3 Tomas Mraz 2011-11-15 12:32:47 EST
Could it be that it is because you do not have /bin/bash in /etc/shells?
Comment 4 Ola Thoresen 2011-11-15 18:50:20 EST
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.
Comment 5 Paul Howarth 2011-11-20 06:29:59 EST
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
Comment 6 Tomas Mraz 2011-11-21 03:35:05 EST
Paul, what do you have in the /etc/shells?
Comment 7 Paul Howarth 2011-11-21 04:10:52 EST
(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.
Comment 8 Tomas Mraz 2011-11-21 04:56:27 EST
Do you see anything related in the /var/log/secure?
Is the user uid >= 1000?
Comment 9 Paul Howarth 2011-11-21 05:02:38 EST
(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)
Comment 10 Tomas Mraz 2011-11-21 05:25:27 EST
This looks like some bad interaction between nss_sss and the ftp daemons. Reassigning to sssd.
Comment 11 Stephen Gallagher 2011-11-23 10:17:33 EST
Upstream ticket:
https://fedorahosted.org/sssd/ticket/1097
Comment 12 Jan Zeleny 2011-12-05 10:54:02 EST
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?
Comment 13 Paul Howarth 2011-12-06 10:09:33 EST
(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
Comment 14 Jan Zeleny 2011-12-06 10:50:03 EST
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.

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