Linux – vsFTPd authenticating with SSSD

active-directoryftplinuxsssdvsftpd

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)

Best Answer

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

Related Solutions

How to Configure vsftpd to Work with Passive Mode – CentOS FTP

To configure passive mode for vsftpd you need to set some parameters in vsftpd.conf.

pasv_enable=Yes
pasv_max_port=10100
pasv_min_port=10090

This enables passive mode and restricts it to using the eleven ports for data connections. This is useful as you need to open these ports on your firewall.

iptables -I INPUT -p tcp --destination-port 10090:10100 -j ACCEPT

If after testing this all works then save the state of your firewall with

service iptables save

which will update the /etc/sysconfig/iptables file.

To do this is CentOS 7 you have to use the new firewalld, not iptables:

Find your zone:

# firewall-cmd --get-active-zones
public
  interfaces: eth0

My zone is 'public', so I set my zone to public, add the port range, and after that we reload:

# firewall-cmd --permanent --zone=public --add-port=10090-10100/tcp
# firewall-cmd --reload

What happens when you make a connection

Your client makes a connection to the vsftpd server on port 21.
The sever responds to the client telling it which port to connect to from the range specified above.
The client makes a data connection on the specified port and the session continues.

There is a great explanation of the different ftp modes here.

Linux (Ubuntu vs CentOS) LDAP Client for 389-ds – password policy

I have been playing around with 389-ds on Ubuntu for a work project and came across the exact same issue.

I'm not sure about copying the config over from CentOS - I didn't have a box handy.

But when I looked and read up on PAM, it turned out to all be in the file /etc/pam.d/common-account.

pam_unix.so was above pam_ldap.so, and it also had [success=2 default=ignore], which means if it succeeds skip the next two rules, and for anything else, ignore the line.

Now since LDAP accounts are valid UNIX accounts since we added ldap to /etc/nsswitch.conf, this rule will return success and the pam_ldap.so module will never get run.

To get around this, my /etc/pam.d/common-account now looks like this:

# here are the per-package modules (the "Primary" block)
account [success=1 default=bad]  pam_succeed_if.so user ingroup auth-access quiet
account [success=reset default=bad]  pam_succeed_if.so uid <= 500 quiet
account [success=2 user_unknown=ignore default=ok]      pam_ldap.so
account [success=1 new_authtok_reqd=done default=ignore]        pam_unix.so
# here's the fallback if no module succeeds
account requisite                       pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
account required                        pam_permit.so
# and here are more per-package modules (the "Additional" block)
# end of pam-auth-update config

As you can see, I've also added some rules in there to only allow users in either the LDAP group "auth-access", or system users with a UID below 500 to be seen as valid accounts.

And to explain a little:

We hit the first rule

account [success=1 default=bad]  pam_succeed_if.so user ingroup auth-access quiet

Which succeeds if the user is in that group and if so, we skip the next line as we know that'll fail (they're a valid LDAP user, so they won't have a system UID below 500) - if it doesn't succeed, return a fail (bad).

Then the next rule if it wasn't skipped

account [success=reset default=bad]  pam_succeed_if.so uid <= 500 quiet

So if this on succeeds (because the UID is below 500), reset the fail value set by the module above, because they won't be part of that LDAP group.

And the important part

account [success=2 user_unknown=ignore default=ok]      pam_ldap.so

Check the LDAP server for the account status - if it succeeds, we know an LDAP user is a valid UNIX user, so go ahead and skip the next two lines (to take us to pam_permit.so and let the user login). If the user is unknown to the LDAP server, ignore this line and move to the next one - and for all other statuses, "ok" means it's ok to pass those return codes as-is, which will pass things like password expired, etc.

And then:

account [success=1 new_authtok_reqd=done default=ignore]        pam_unix.so

We weren't a valid LDAP user if we hit this rule, so check if we're a valid system user - if succeed, skip next 1 line (takes us to pam_permit.so). Otherwise, ignore, which will take us to pam_deny.so.

Hope that helps explain a little more - the document that helped me if I wasn't very easy to understand was: http://uw714doc.sco.com/en/SEC_pam/pam-4.html

Regards, iamacarpet

Best Answer

Related Solutions

How to Configure vsftpd to Work with Passive Mode – CentOS FTP

Linux (Ubuntu vs CentOS) LDAP Client for 389-ds – password policy

Related Topic