Bug 708657

using workaround until we find the problem

session    optional     pam_keyinit.so    force revoke
auth       required     pam_listfile.so item=user sense=deny
file=/etc/vsftpd/ftpusers onerr=succeed
auth       required     pam_shells.so
auth       sufficient   pam_ldap.so
auth       required     pam_unix.so
auth       required     pam_shells.so
account    sufficient   pam_ldap.so
account    required     pam_unix.so
password   sufficient   pam_ldap.so
password   required     pam_unix.so
session    include      system-auth
session optional pam_console.so

example of user entry in ldap, used migrationtools to import users in ldap

dn: uid=ftppruebas,ou=People,dc=example,dc=com
cn: ftppruebas
gecos: ftppruebas
gidnumber: 1000
homedirectory: /srv/www/ftppruebas/
loginshell: /bin/bash
objectclass: account
objectclass: posixAccount
objectclass: top
objectclass: shadowAccount
shadowlastchange: 15110
shadowmax: 99999
shadowmin: 0
shadowwarning: 7
uid: ftppruebas
uidnumber: 1000
userpassword: {CRYPT}X1p/yyTjahbwQ

If we disable pam_succeed_if.so fragments in pam.d password-auth vsftpd starts login ok on ldap

#%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_ldap.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_ldap.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_ldap.so use_authtok
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
#session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so
session     optional      pam_ldap.so


maybe is related to not finding a numeric uid in ldap??

What 'getent passwd ftppruebas' prints?

What's in your /etc/nsswitch.conf?

[root@cl01-07 ~]# getent passwd ftppruebas
ftppruebas:x:1000:1000:ftppruebas:/srv/www/ftppruebas/:/sbin/nologin

/etc/nsswitch.conf

passwd:     files ldap
shadow:     files ldap
group:      files ldap

#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 ldap

publickey:  nisplus

automount:  files ldap
aliases:    files nisplus

Could it be a SELinux issue? Does it happen if you put SELinux to permissive mode with 'setenforce 0'? By the way the first pam_succeed_if call can be removed by 'authconfig --enablesysnetauth --update' call.

Tested same configuration on a system running rhel 6.0 with this set of packages versions and works as expected:

[root@cl01-mysql2 ~]# rpm -qa|grep ldap
pam_ldap-185-5.el6.x86_64
openldap-2.4.19-15.el6.x86_64
python-ldap-2.3.10-1.el6.x86_64
nss-pam-ldapd-0.7.5-3.el6.x86_64
[root@cl01-mysql2 ~]#

[root@cl01-mysql2 ~]# rpm -q pam
pam-1.1.1-4.el6_0.1.x86_64
[root@cl01-mysql2 ~]#

[root@cl01-mysql2 ~]# rpm -q vsftpd
vsftpd-2.2.2-6.el6_0.1.x86_64
[root@cl01-mysql2 ~]#

we use in both systems nslcd

Unfortunately this does not answer my question.

I have tested both systems with selinux in permissive mode.

Also tested authconfig --enablesysnetauth --update with no results, any occurrence of pam_succeed_if call in pam.d/password-auth brokes vsftpd ldap auth

Hmm, that does not make any sense apart from some very weird caching issue in nslcd. I do not think it is related to PAM itself. Perhaps for some (weird) reason the user lookup in pam_succeed_if fails and then the result is getting cached for future calls making the authentication to fail.

Will you please try downgrading particular components to find out right one that is source of the issue? You could start with nss-pam-ldapd then vsftpd.

Thanks, Jiri

No problem with that, next monday I will test with version:

nss-pam-ldapd-0.7.5-3.el6.x86_64

wich worked fine on rhel 6.0

(In reply to comment #13)
> No problem with that, next monday I will test with version:
> 
> nss-pam-ldapd-0.7.5-3.el6.x86_64
> 
> wich worked fine on rhel 6.0

Did you make tests described in comment #12 or the #13 is a conclusion?

I have encountered the same issue with a customer. I have also been able to reproduce this in house in my testing. ssh connections with the same ldap users would work but vsftp sessions would not. We were using the same versions mentioned above.  Selinux was disabled or in permissive mode.

pam_ldap-185-8.el6.x86_64
nss-pam-ldapd-0.7.5-7.el6.x86_64
openldap-2.4.23-15.el6.x86_64

/etc/nslcd.conf
uri ldap://jagee-rhel5-openldap.usersys.redhat.com
base dc=example,dc=com
ssl no
tls_cacertdir /etc/openldap/cacerts

/etc/pam_ldap.conf
base dc=example,dc=com
uri ldap://jagee-rhel5-openldap.usersys.redhat.com
ssl no
tls_cacertdir /etc/openldap/cacerts

example.com.ldif
dn: dc=example,dc=com
objectClass: dcObject
objectClass: organization
description: example domain
o: example
dc: example

dn: ou=Group,dc=example,dc=com
objectClass: top
objectClass: organizationalUnit
ou: Group

dn: cn=test,ou=Group,dc=example,dc=com
objectClass: posixGroup
objectClass: top
cn: test
userPassword: {crypt}x
gidNumber: 1000
memberUid: test

dn: ou=People,dc=example,dc=com
objectClass: top
objectClass: organizationalUnit
ou: People

dn: uid=test,ou=People,dc=example,dc=com
uid: test
cn: test
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
shadowLastChange: 12102
shadowMax: 99999
shadowWarning: 7
loginShell: /bin/bash
uidNumber: 1000
gidNumber: 1000
userPassword: {crypt}$1$gZddl90v$YJFih6/ftT3IcnCsdVmHs1
homeDirectory: /home/test


[jagee@colossus ~]$ ssh test.52.80
test.52.80's password: 
Last login: Wed Jun 29 14:14:45 2011 from 10.12.52.55
-bash-4.1$ exit
logout
Connection to 10.12.52.80 closed.

[jagee@colossus ~]$ lftp test.52.80
Password: 
lftp test.52.80:~> ls -la /
ls: Login failed: 530 Login incorrect.                
lftp test.52.80:~> exit

Jun 29 14:25:12 rhel6-server1 sshd[1557]: Accepted password for test from 10.12.52.55 port 40055 ssh2
Jun 29 14:25:13 rhel6-server1 sshd[1557]: pam_unix(sshd:session): session opened for user test by (uid=0)
Jun 29 14:25:15 rhel6-server1 sshd[1562]: Received disconnect from 10.12.52.55: 11: disconnected by user
Jun 29 14:25:15 rhel6-server1 sshd[1557]: pam_unix(sshd:session): session closed for user test
Jun 29 14:25:22 rhel6-server1 vsftpd[1578]: PAM unable to dlopen(/lib64/security/pam_mkhomedir.so): /lib64/security/pam_mkhomedir.so: failed to map segment from shared object: Cannot allocate memory
Jun 29 14:25:22 rhel6-server1 vsftpd[1578]: PAM adding faulty module: /lib64/security/pam_mkhomedir.so
Jun 29 14:25:22 rhel6-server1 vsftpd[1578]: pam_unix(vsftpd:auth): check pass; user unknown
Jun 29 14:25:22 rhel6-server1 vsftpd[1578]: pam_unix(vsftpd:auth): authentication failure; logname= uid=0 euid=0 tty=ftp ruser=test rhost=10.12.52.55 
Jun 29 14:25:22 rhel6-server1 vsftpd[1578]: pam_succeed_if(vsftpd:auth): error retrieving information about user test

After downgrading the openldap package to the 6.0 release the vsftp issued was fixed.  Also the "Cannot allocate memory" error from pam_mkhomedir was resolved.
openldap-2.4.19-15.el6_0.2.x86_64

Also when i moved the pam_ldap module above pam_unix and I saw some bind errors in the messages file.  This would not happen with the module in place below pam_unix from the authconfig-tui run.  /etc/pam.d/vsftpd was the stock file.
/etc/pam.d/password-auth
auth        required      pam_env.so
auth        sufficient    pam_ldap.so debug use_first_pass
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 500 quiet
auth        required      pam_deny.so

Jun 29 16:37:22 rhel6-server1 vsftpd[1286]: pam_ldap: ldap_simple_bind Can't contact LDAP server
Jun 29 16:37:22 rhel6-server1 vsftpd[1286]: pam_ldap: reconnecting to LDAP server...
Jun 29 16:37:22 rhel6-server1 vsftpd[1286]: pam_ldap: ldap_simple_bind Can't contact LDAP server

This appears to be a regression?

This looks like a regression perhaps from moving openldap from openssl TLS backend to NSS TLS backend?

Perhaps there is some symbol or other conflict between vsftpd and NSS?

Tentatively reassigning to OpenLDAP as this is the source of the regression.

I'm unable to reproduce the bug. I used example data and nslcd.conf/pam_ldap.conf configuration from comment 15. And all PAM configurations described in this bug. I didn't encounter the problem. But maybe I'm missing something.

Please, can you provide complete /etc/{nslcd.conf,pam_ldap.conf,pam.d}? Also add one testing account to your directory server, check that this account is affected by this bug (ssh login works, ftp login does not), export that account in LDIF format and tell us the password. Maybe there is something wrong with userPassword attribute format. Of course you can obfuscate any sensitive data.

(In reply to comment #8)
> Tested same configuration on a system running rhel 6.0 with this set of
> packages versions and works as expected:
> 
> [root@cl01-mysql2 ~]# rpm -qa|grep ldap
> pam_ldap-185-5.el6.x86_64
> openldap-2.4.19-15.el6.x86_64
> python-ldap-2.3.10-1.el6.x86_64
> nss-pam-ldapd-0.7.5-3.el6.x86_64

Based on this information, I don't suppose openldap is the cause.

Jan, when i initially set this up it worked for me too.  After this it started failing like the customer case.  Ill keep digging as i can not explain exactly how i got it to break after the initial success?

Jeremy, OK. Thanks. It would be great, if we could reproduce it safely.

Ok looks like i was able to recreate this again.  Here are my steps and config.

Fresh install of RHLE6.0.
Fully update to all latest packages.

/etc/nslcd.conf
uid nslcd
gid ldap
# This comment prevents repeated auto-migration of settings.
uri ldap://jagee-rhel5-openldap.usersys.redhat.com/
base dc=example,dc=com
ssl no
tls_cacertdir /etc/openldap/cacerts

/etc/pam_ldap.conf
base dc=example,dc=com
uri ldap://jagee-rhel5-openldap.usersys.redhat.com/
ssl no
tls_cacertdir /etc/openldap/cacerts
pam_password md5

sestatus: enforcing
[root@dhcp52-189 ~]# getsebool ftp_home_dir
ftp_home_dir --> on

ldap user above
username: test
password: test


All stock pam files generated with authconfig-tui

/etc/pam.d/password-auth and /etc/pam.d/system-auth

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_ldap.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_ldap.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_ldap.so use_authtok
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so
session     optional      pam_ldap.so

/etc/pam.d/sshd 
auth	   required	pam_sepermit.so
auth       include      password-auth
account    required     pam_nologin.so
account    include      password-auth
password   include      password-auth
# pam_selinux.so close should be the first session rule
session    required     pam_selinux.so close
session    required     pam_loginuid.so
# pam_selinux.so open should only be followed by sessions to be executed in the user context
session    required     pam_selinux.so open env_params
session    optional     pam_keyinit.so force revoke
session    include      password-auth

/etc/pam.d/vsftpd 
session    optional     pam_keyinit.so    force revoke
auth       required	pam_listfile.so item=user sense=deny file=/etc/vsftpd/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

Downgrade openldap with yum.
yum downgrade openldap -y

pam_ldap-185-8.el6.x86_64
nss-pam-ldapd-0.7.5-7.el6.x86_64
openldap-2.4.19-15.el6_0.2.x86_64
vsftpd-2.2.2-6.el6_0.1.x86_64
openssh-server-5.3p1-52.el6_1.2.x86_64

Able to ssh and ftp in:
[jagee@colossus 00506441]$ ssh test.52.189
test.52.189's password: 
Last login: Tue Jul 19 17:43:32 2011 from dhcp52-55.gsslab.rdu.redhat.com
-bash-4.1$ ls -la
total 12
drwxr-xr-x. 2 test test 4096 Jul 19 17:42 .
drwxr-xr-x. 3 root root 4096 Jul 19 17:50 ..
-rw-------. 1 test test    5 Jul 19 17:42 .bash_history

[jagee@colossus 00506441]$ lftp test.52.189
Password: 
lftp test.52.189:~> ls -la     
drwxr-xr-x    2 1000     1000         4096 Jul 19 21:42 .
drwxr-xr-x    3 0        0            4096 Jul 19 21:50 ..
-rw-------    1 1000     1000            5 Jul 19 21:42 .bash_history

[root@dhcp52-189 ~]# yum update openldap -y
[root@dhcp52-189 ~]# rpm -q openldap
openldap-2.4.23-15.el6.x86_64
[root@dhcp52-189 ~]# /etc/init.d/vsftpd restart

[jagee@colossus 00506441]$ lftp test.52.189
Password: 
lftp test.52.189:~> ls -la     
ls: Login failed: 530 Login incorrect.

[jagee@colossus 00506441]$ ssh test.52.189
test.52.189's password: 
Last login: Tue Jul 19 17:58:42 2011 from dhcp52-55.gsslab.rdu.redhat.com
-bash-4.1$ ls -la
total 12
drwxr-xr-x. 2 test test 4096 Jul 19 17:42 .
drwxr-xr-x. 3 root root 4096 Jul 19 17:50 ..
-rw-------. 1 test test   17 Jul 19 17:59 .bash_history

[root@dhcp52-189 ~]# tail -n0 -f /var/log/secure 
Jul 19 18:01:12 dhcp52-189 sshd[1756]: Received disconnect from 10.12.52.55: 11: disconnected by user
Jul 19 18:01:12 dhcp52-189 sshd[1751]: pam_unix(sshd:session): session closed for user test
Jul 19 18:01:16 dhcp52-189 vsftpd[1788]: pam_unix(vsftpd:auth): check pass; user unknown
Jul 19 18:01:16 dhcp52-189 vsftpd[1788]: pam_unix(vsftpd:auth): authentication failure; logname= uid=0 euid=0 tty=ftp ruser=test rhost=10.12.52.55 
Jul 19 18:01:16 dhcp52-189 vsftpd[1788]: pam_succeed_if(vsftpd:auth): error retrieving information about user test
Jul 19 18:02:00 dhcp52-189 sshd[1790]: Accepted password for test from 10.12.52.55 port 45956 ssh2
Jul 19 18:02:00 dhcp52-189 sshd[1790]: pam_unix(sshd:session): session opened for user test by (uid=0)

Also tried a sha512 hash and got the same result
password: test
userPassword: $6$izupz4Xq$5nGzwj4NS1I0TU41K4LVh45hB9Olu3ZCrk.a3SPnUUukifmj2DcknuvmsYwFM2ZCc51AdqzDNe6cCncZLNuu11

After downgrading openldap again. it works just as it did the first time. Hope that clears this up.

The customer case im working reported the latest openldap update did not resolve the issue.  I updated to 2.4.23-15.el6_1.1.x86_64 on my test vm and had teh same results. The login's failed for vsftp on ldap accounts.

Downgrading with "yum downgrade openldap-2.4.19-15.el6_0.2" resulted in the test ldap user successful login into vsftp.  If you would like, I can leave the test vm instance up so you can take a look?  This latest setup was the same one from my last post.

Jeremy, I'm currently working on it. I managed to reproduce it after following comment #20. It is definitely strange, because it works correctly after fresh RHEL-6.1 and the same configuration.

So here are the results of my investigation.

After installing RHEL-6.0, setting up the configuration and upgrading to RHEL-6.1 the bug can be reproduced. In fact, pam_ldap is not used, but pam_unix.

# getent passwd test
test:x:1000:1000:test:/home/test:/bin/bash
# getent shadow test
test:$1$gZddl90v$YJFih6/ftT3IcnCsdVmHs1:12102::99999:7:::0

But from some reason, during authentication to FTP server, the resolution is  done only through nscd daemon. And I believe that nslcd is used as a replacement for it. But nslcd is not queried at all:

# strace -f -p `pidof vsftpd` 2>&1 | grep -E nscd\|nslcd
[pid 11886] connect(3, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
[pid 11886] connect(3, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
[pid 11886] connect(5, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
[pid 11886] connect(5, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)

On fresh RHEL-6.1 installation, with the same configuration, the situation is different. It works. And here is the strace:

# strace -f -p `pidof vsftpd` 2>&1 | grep -E nscd\|nslcd
[pid  1477] connect(4, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
[pid  1477] connect(4, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
[pid  1476] connect(5, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
[pid  1476] connect(5, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
[pid  1476] connect(5, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
[pid  1476] connect(5, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
[pid  1476] connect(5, {sa_family=AF_FILE, path="/var/run/nslcd/socket"}, 110) = 0
[pid  1478] connect(4, {sa_family=AF_FILE, path="/var/run/nslcd/socket"}, 110) = 0
[pid  1478] connect(4, {sa_family=AF_FILE, path="/var/run/nslcd/socket"}, 110) = 0
[pid  1478] connect(4, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
[pid  1478] connect(4, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
[pid  1478] connect(4, {sa_family=AF_FILE, path="/var/run/nslcd/socket"}, 110) = 0

I do not know how nscd/nslcd resolution process is controlled. But it works on both installations with ssh.

Commenting out following lines in vsftpd resolved the problem as well:
#auth       required    pam_listfile.so item=user sense=deny file=/etc/vsftpd/ftpusers onerr=succeed
#auth       required    pam_shells.so

I do not think this is libldap fault. I'm adding pam-nss-ldap maintainer. Nalin do you have any idea, why this happens?

It looks like vsftpd is setting a value for RLIMIT_AS which is now too low for the set of modules, and their dependencies, that it loads, as doubling VSFTP_AS_LIMIT prevents my test system from hitting this problem when it would otherwise.

(In reply to comment #24)
> It looks like vsftpd is setting a value for RLIMIT_AS which is now too low for
> the set of modules, and their dependencies, that it loads, as doubling
> VSFTP_AS_LIMIT prevents my test system from hitting this problem when it would
> otherwise.

I can confirm that this change fixed that for me.

Created attachment 520797 [details]
This patch increases VSFTPD_AS_LIMIT

Thanks for info. It's verified attached patch fixes this issue.

This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unfortunately unable to
address this request at this time. Red Hat invites you to
ask your support representative to propose this request, if
appropriate and relevant, in the next release of Red Hat
Enterprise Linux. If you would like it considered as an
exception in the current release, please ask your support
representative.

I'm using pam_smbpass.so to authenticate by Samba and I have the same problem with the message:

Dec 12 21:05:29 opteron vsftpd[8335]: PAM unable to dlopen(/lib64/security/pam_loginuid.so): /lib64/security/pam_loginuid.so: failed to map segment from shared object: Cannot allocate memory
Dec 12 21:05:29 opteron vsftpd[8335]: PAM adding faulty module: /lib64/security/pam_loginuid.so
Dec 12 21:05:29 opteron vsftpd[8335]: PAM unable to dlopen(/lib64/security/pam_limits.so): /lib64/security/pam_limits.so: failed to map segment from shared object: Cannot allocate memory
Dec 12 21:05:29 opteron vsftpd[8335]: PAM adding faulty module: /lib64/security/pam_limits.so
Dec 12 21:05:29 opteron vsftpd[8335]: PAM unable to dlopen(/lib64/security/pam_unix.so): /lib64/security/pam_unix.so: failed to map segment from shared object: Cannot allocate memory
Dec 12 21:05:29 opteron vsftpd[8335]: PAM adding faulty module: /lib64/security/pam_unix.so
Dec 12 21:05:29 opteron vsftpd[8335]: pam_succeed_if(vsftpd:auth): error retrieving information about user xyz

I tried to downgrade to vsftpd from 6.0 release, but it does not solve the problem. I tried to comment out lines in vsftpd's PAM file (comment #23), but it does not work too. It seems that there could be another problem...??? I'm able to authenticate through dovecot though. I did not tried to recompile vsftpd with the patch above yet.

> I tried to downgrade to vsftpd from 6.0 release, but it does not solve the
> problem. I tried to comment out lines in vsftpd's PAM file (comment #23), but
> it does not work too. It seems that there could be another problem...??? I'm
> able to authenticate through dovecot though. I did not tried to recompile
> vsftpd with the patch above yet.

Please, would you test the patch attached in the comment #26. I'd like to know if your issue is covered by this fix or not. If not I'll open another bug.

Thank you, Jiri

It works :-) Thank you. The package vsftpd-2.2.2-6.el6.1.ker could be downloaded here:

http://koji.fedoraproject.org/koji/taskinfo?taskID=3585942
http://ftp.pslib.cz/pub/users/Milan.Kerslager/RHEL-6/stable/

    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
The vsftpd daemon sets a value of the RLIMIT_AS variable during its initialization phase. With Red Hat Enterprise Linux 6.1, the RLIMIT_AS value (100 MB) became insufficient which restricted LDAP users from authentication to the system using vsftpd. With this update, the initial RLIMIT_AS value has been increased to 200 MB, and vsftpd now can be used for LDAP authentication as expected.

I am on SL 6.2 and am still experiencing this issue.

Jun  7 19:47:41 files vsftpd[623]: pam_unix(vsftpd:auth): check pass; user unknown
Jun  7 19:47:41 files vsftpd[623]: pam_unix(vsftpd:auth): authentication failure; logname= uid=0 euid=0 tty=ftp ruser=USER rhost=IP
Jun  7 19:47:41 files vsftpd[623]: pam_succeed_if(vsftpd:auth): error retrieving information about user USER

ldap setup with (i.e. authconfig generated pam.d files):
authconfig --enableldap --enableldapauth --disableldaptls --enablemkhomedir --enableforcelegacy --ldapserver=URI --ldapbasedn=DN --update

pam-1.1.1-10.el6.x86_64
pam_ldap-185-11.el6.x86_64
nss-pam-ldapd-0.7.5-14.el6.x86_64
vsftpd-2.2.2-6.el6_0.1.x86_64

I am also using OpenVZ.

vzkernel-2.6.32-042stab049.6.x86_64

(In reply to comment #45)
> I am on SL 6.2 and am still experiencing this issue.
> 
> Jun  7 19:47:41 files vsftpd[623]: pam_unix(vsftpd:auth): check pass; user
> unknown
> Jun  7 19:47:41 files vsftpd[623]: pam_unix(vsftpd:auth): authentication
> failure; logname= uid=0 euid=0 tty=ftp ruser=USER rhost=IP
> Jun  7 19:47:41 files vsftpd[623]: pam_succeed_if(vsftpd:auth): error
> retrieving information about user USER
> 
> ldap setup with (i.e. authconfig generated pam.d files):
> authconfig --enableldap --enableldapauth --disableldaptls --enablemkhomedir
> --enableforcelegacy --ldapserver=URI --ldapbasedn=DN --update
> 
> pam-1.1.1-10.el6.x86_64
> pam_ldap-185-11.el6.x86_64
> nss-pam-ldapd-0.7.5-14.el6.x86_64
> vsftpd-2.2.2-6.el6_0.1.x86_64

This issue should be fixed in vsftpd-2.2.2-6.el6_2.1 for RHEL-6.2, see https://bugzilla.redhat.com/show_bug.cgi?id=767108.

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.

http://rhn.redhat.com/errata/RHBA-2012-0790.html