3

I am currently trying to setup an FTP sever that authenticates through Active Directory using SSSD.

My config files are as follows:

/etc/vsftpd/vsftpd:

[root@StudentOrgFTP vsftpd]# cat vsftpd.conf
anonymous_enable=NO
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=YES
userlist_log=YES
tcp_wrappers=NO
chroot_local_user=YES
session_support=YES

/etc/sssd/sssd.conf

[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

ldap_id_mapping = True
override_shell = /bin/bash
override_homedir = /srv/student_ftp/%u

# Connection Properties
ldap_uri = ldaps://xxxxx.xxxxxxxx.xxx
# Temporary measure until I can get a hold of a proper certificate
ldap_tls_reqcert = never

ldap_search_base = dc=xxxxxxxx,dc=xxx
ldap_group_search_base = OU=students,dc=xxxxxxxx,dc=xxx
ldap_default_bind_dn = CN=<AD User>,OU=Users,OU=Labs,dc=xxxxxxxx,dc=xxx
ldap_default_authtok_type = password
ldap_default_authtok = <password>

ldap_access_filter = (&(objectClass=person)(ou=students,dc=xxxxxxxx,dc=xxx))

/etc/pam.d/vsftpd

auth required pam_env.so
auth sufficient pam_sss.so
ce with pam_winbind.so
account sufficient pam_sss.so
ce with pam_winbind.so
session required pam_loginuid.so
session optional pam_keyinit.so force revoke
auth required pam_listfile.so item=user sense=deny file=/etc/vsftpd/ftpuse
rs onerr=succeed
auth required pam_shells.so
auth include password-auth
account include password-auth
session required pam_loginuid.so
session include password-auth

I was able to get SSSD working with this config, I can run 'id username' or 'getent passwd username' and they both return with the correct info, but if I use the generic linux 'ftp' command vsftp can't seem to authenticate correctly.

EDIT: /var/log/secure output:

Jan 27 04:32:36 StudentOrgFTP vsftpd: vsftpd: PAM (vsftpd) illegal module type: ce
Jan 27 04:32:36 StudentOrgFTP vsftpd: PAM pam_parse: expecting return value; [...with]
Jan 27 04:32:36 StudentOrgFTP vsftpd: PAM (vsftpd) illegal module type: ce
Jan 27 04:32:36 StudentOrgFTP vsftpd: PAM pam_parse: expecting return value; [...with]
Jan 27 04:32:36 StudentOrgFTP vsftpd: PAM (vsftpd) illegal module type: rs
Jan 27 04:32:36 StudentOrgFTP vsftpd: PAM pam_parse: expecting return value; [...onerr=succeed]
Jan 27 04:32:36 StudentOrgFTP vsftpd: PAM (vsftpd) no module name supplied
Jan 27 04:32:36 StudentOrgFTP vsftpd: pam_sss(vsftpd:auth): authentication success; logname= uid=0 euid=0 tty=ftp ruser=some_username rhost=localhost user=some_username
Jan 27 04:32:36 StudentOrgFTP vsftpd: pam_sss(vsftpd:account): Access denied for user some_username: 6 (Permission denied)
Jan 27 04:32:36 StudentOrgFTP vsftpd: pam_sss(vsftpd:account): Access denied for user some_username: 6 (Permission denied)
1

I first checked the shell settings and added the following line to my /etc/sss/sssd.conf:

[domain/example.org]
override_shell = /sbin/rbash

but this didn't solve the problem.

After commenting out the line

account  [default=bad success=ok user_unknown=ignore]  pam_sss.so

in /etc/pam.d/common-auth active directory users can login with their AD account.

But this setting affects more login services than just vsftpd. So I removed the comment from that line (going back to the original version) and changed vsftpd'd pam configuration instead:

/etc/pam.d/vsftpd:

# Standard behaviour for ftpd(8).
auth  required   pam_listfile.so item=user sense=deny file=/etc/ftpusers onerr=succeed

# Note: vsftpd handles anonymous logins on its own. Do not enable pam_ftp.so.

# Standard pam includes

##@include common-account
account [success=1 new_authtok_reqd=done default=ignore]  pam_unix.so 
account requisite      pam_deny.so
account required       pam_permit.so
account sufficient     pam_localuser.so 

@include common-session
@include common-auth
auth    required       pam_shells.so
0

I doubt the missing shell is the problem, the config file specifies a local override for the shell using the override_shell directive.

Do you see any errors in /var/log/secure (or your distribution's equivalent) ? Can you turn on the debug_level for the [pam] and [domain] sections and see if there's anything of interest?

Checking whether the AD users are able to authenticate via another PAM service (su, perhaps) might also be helpful to pinpoint whether the problem lies in SSSD or vsftpd.

  • Thanks for the reply, I'll post more on Tuesday (long weekend), but I know the issue isn't SSSD because I can retrieve username's and info from AD with 'id' and 'getent passwd', so I am assuming the issue is in vsftpd or PAM. Once I get back in on Tuesday I will check the logs and trun on the debug levels and see what that brings out. – Jeremy Spencer Jan 18 '15 at 16:46
  • Sorry for the long wait. So initially nothing was being put in /var/log/secure, however after adding 'debug_level = 9' to both [pam] and [domain] in /etc/sssd/sssd.conf I tried used 'su other_username' and the system logged me in as that user; addtitionally /var/log/secure recorded it as well. After running 'ftp localhost' and putting in a correct username and password, I edited the question with /var/log/secure's output. – Jeremy Spencer Jan 27 '15 at 13:31
0

My guess is that the the problem is the

auth required pam_shells.so

line in your /etc/pam.d/vsftpd config file. This requires that all users have a default shell which is listed in /etc/shells and your AD authentication might not be providing that correctly.

I would test by simply commenting that line out and then if it works make a decision about whether the security provided by that test is required and if it is figure out how to make it work with AD and SSSD.

  • That did not work for me. I have commented this line and restarted the vsftpd service sudo systemctl restart vsftpd.service – Junior M Apr 2 '15 at 19:09
0

Check the user shell! If the shell is not listed (chsh -l), this is where the /etc/pam.d/vsftpd comes into play.
We changed the user from the default /usr/bin/ksh to /bin/ksh and no other changes were needed.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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