Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

We are trying to give vsftpd access to some Active Directory users.

Here are some configuration file contents:

# egrep -v '^(#.*|)$' vsftpd.conf
anonymous_enable=YES
local_enable=YES
write_enable=YES
local_umask=022
dirmessage_enable=YES
xferlog_enable=YES
connect_from_port_20=YES
xferlog_std_format=YES
listen=YES
pam_service_name=vsftpd
userlist_enable=NO
tcp_wrappers=YES
dual_log_enable=YES
log_ftp_protocol=YES
local_root=/srv/ftp/users
chroot_local_user=YES

# egrep -v '^(#.*|)$' /etc/pam.d/vsftpd
auth     required    pam_ldap.so use_first_pass
account  required    pam_ldap.so
session  required    pam_limits.so

# egrep -v '^(#.*|)$' /etc/pam_ldap.conf
host ad.example.lan
base dc=example,dc=lan
binddn cn=ftp_auth,dc=example,dc=lan
bindpw password
nss_map_objectclass posixAccount user
nss_map_objectclass shadowAccount user
nss_map_attribute uid sAMAccountName
nss_map_attribute homeDirectory unixHomeDirectory
nss_map_attribute shadowLastChange pwdLastSet
nss_map_objectclass posixGroup group
nss_map_attribute uniqueMember member
pam_login_attribute sAMAccountName
pam_filter objectclass=User

However, when I try to login I get this response regardless of correct password or not:

# tail -f -n0 /var/log/messages /var/log/vsftpd.log
==> /var/log/messages <==

==> /var/log/vsftpd.log <==
Fri Feb 14 14:55:46 2014 [pid 3747] CONNECT: Client "192.168.1.49"
Fri Feb 14 14:55:46 2014 [pid 3747] FTP response: Client "192.168.1.49", "220 (vsFTPd 2.2.2)"
Fri Feb 14 14:55:46 2014 [pid 3747] FTP command: Client "192.168.1.49", "USER melbin"
Fri Feb 14 14:55:46 2014 [pid 3747] [melbin] FTP response: Client "192.168.1.49", "331 Please specify the password."
Fri Feb 14 14:55:46 2014 [pid 3747] [melbin] FTP command: Client "192.168.1.49", "PASS <password>"
Fri Feb 14 14:55:46 2014 [pid 3746] [melbin] FAIL LOGIN: Client "192.168.1.49"
Fri Feb 14 14:55:47 2014 [pid 3747] [melbin] FTP response: Client "192.168.1.49", "530 Login incorrect."

Can someone point us in the right direction? Perhaps help us get some more debug messages or explain what we are doing wrong in the PAM config.

share|improve this question

2 Answers 2

I haven't had the best of experiences with pam_ldap, so I started using SSSD for domain authentication. I installed VSFTPD on a test server and was able to successfully authenticate after outright copying your vsftpd.conf file. Are domain users able to authenticate to any other services on this server? I think that your users are not being found when they are trying to authenticate.

yum install sssd

In order to authenticate with SSSD, you need to use a secure connection (LDAP with TLS,LDAPS via TCP/636, or LDAPS via TCP/3269 for the Global Catalog).

Below is a redacted version of the configuration file I use at work to authenticate users against Active Directory on Centos 6. I have multiple domains in the same forest, so I went with LDAP lookups as opposed to joining the server to the domain via Kerberos to make my life a bit easier.

[sssd]

domains = WORK
services = nss, pam
config_file_version = 2

[pam]
offline_credentials_expiration = 5

[nss]

[domain/WORK]
description = Work domains

enumerate = false

id_provider = ldap
auth_provider = ldap
chpass_provider = none
access_provider = ldap

ldap_pwd_policy = none
ldap_schema = ad
ldap_user_name = sAMAccountName
ldap_user_object_class = person
ldap_group_object_class = group
ldap_id_mapping = True
case_sensitive = false

override_shell = /bin/bash
override_homedir = /home/%u

ldap_uri = ldaps://10.9.8.6:3269
ldap_tls_reqcert = never

ldap_search_base = dc=work,dc=local
ldap_default_bind_dn = CN=Shell Auth Lookup,OU=Service Accounts,DC=work,DC=local
ldap_default_authtok_type = password
ldap_default_authtok = password-for-the-proxy-user

ldap_access_filter = (&(objectClass=person)(|(memberOf:1.2.840.113556.1.4.1941:=CN=shell-admins,OU=Groups,DC=work,DC=local)(memberOf:1.2.840.113556.1.4.1941:=CN=shell-access,OU=Groups,DC=work,DC=local)))

After writing the configuration file, it must only be editable by root. SSSD will immediately exit out if the permissions are anything other than 600, with root ownership.

chmod 600 /etc/sssd/sssd.conf

Enabled SSSD authentication (in your case you could skip the switch for making home directories, as it is aimed at shell usage).

authconfig --enablesssd --enablesssdauth --enablemkhomedir --updateall

Start the service and enable it:

service sssd start && chkconfig enable sssd

See also: http://www.gadgeteering.ca/blogs/active-directory-authentication-linux-through-sssd

If you want to instead join the domain through Kerberos instead of using LDAP, this is the article I followed in my sandbox: http://theblitzbit.com/2013/04/08/make-red-hat-talk-to-windows/ .

share|improve this answer
up vote 1 down vote accepted

After doing some reading on PAM, I realized that using the account interface for pam_ldap wasn't necessary. Since all I wanted to do was check password configuration, I set the service file to this:

#%PAM-1.0
auth     required    pam_ldap.so
account  required    pam_permit.so
session  required    pam_limits.so

Worked like a charm.

share|improve this answer
    
Glad you've resolved this. Please be sure to mark your answer as accepted when you're able. –  jscott Feb 24 at 14:34

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.