SOLVED: Vsftpd with system users and samba4 AD on different machine

NethServer Version: 7.3.1611
Module: ftp or sssd I would guess

GOAL:

I have two nethservers, both 7.3.1611. Server 1 (GR-100) is running the Samba4 domain, server 2 (GR-400) is used as file/ftp server. I want the file/ftp server to use the Samba4 AD accounts on Server 1.

The file/ftp server is already joined to the Samba4 domain, samba shares work fine with this configuration. I can use 'id ’ and I will get the proper info:

[root@gr-400 ~]# id someaccount
uid=1592401107(someaccount) gid=1592400513(domain users@domain.com) groups=1592400513(domain users@domain.com),1592401105(support@domain.com),1592401141(otrs_customers@domain.com),1592401120(otrs_agents@domain.com)

I used the documentation to alter the vsftpd config to be using system users by executing:

config setprop vsftpd UserType system
signal-event nethserver-vsftpd-save

I copied the /etc/pam.d/samba info into the /etc/pam.d/vsftpd file, which is the one referenced in the vsftpd.conf config file. This because no other config I could get my hands on, worked. Since the samba config should work, I would assume it would work for vsftpd too, but I am obviously making an error, as it doesnt work.

I also restored it to what it was, and played around, but no matter what I do, I can not get any results to show in the logs.

I have not yet touched the sssd.conf as the rest of the services seem to work fine with sssd.
Most general info I find, I can not make applicable for nethserver because I seem to miss some information that would make this gel.

Below are the relevant config files (I think).

/etc/pam.d/vsftpd
#%PAM-1.0
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 system-auth
account include system-auth
session required pam_loginuid.so
session include system-auth

/etc/sssd/sssd.conf
# ================= DO NOT MODIFY THIS FILE =================
#
# Manual changes will be lost when this file is regenerated.
#
# Please read the developer’s guide, which is available
# at ://dev.nethesis.it/projects/nethserver/wiki/NethServer
# original work from .contribs.org/development/
#
# Copyright © 2013 Nethesis S.r.l.
# ://www.nethesis.it - support@nethesis.it
#
[sssd]
domains = domain.com, legacy
config_file_version = 2
services = nss, pam
debug_level=7

[pam]
debug_level=7

[domain/domain.com]
use_fully_qualified_names = True
id_provider = ad
access_provider = ad
ad_domain = domain.com
krb5_realm = domain.COM
krb5_store_password_if_offline = True
ldap_user_name = sAMAccountName
ldap_user_object_class = person
ldap_group_object_class = group
ldap_id_mapping = True
ad_maximum_machine_account_password_age = 0
cache_credentials = True
override_homedir = /var/lib/nethserver/home/%u
default_shell = /usr/libexec/openssh/sftp-server
realmd_tags = manages-system joined-with-samba

debug_level=7

[domain/legacy]
use_fully_qualified_names = False
id_provider = ad
access_provider = ad
ad_domain = domain.com
krb5_realm = domain.COM
krb5_store_password_if_offline = True
ldap_user_name = sAMAccountName
ldap_user_object_class = person
ldap_group_object_class = group
ldap_id_mapping = True
ad_maximum_machine_account_password_age = 0
cache_credentials = True
override_homedir = /var/lib/nethserver/home/%u
default_shell = /usr/libexec/openssh/sftp-server

debug_level=7

[nss]
debug_level=7

/etc/vsftpd/vsftpd.conf
# ================= DO NOT MODIFY THIS FILE =================
#
# Manual changes will be lost when this file is regenerated.
#
# Please read the developer’s guide, which is available
# at ://dev.nethesis.it/projects/nethserver/wiki/NethServer
# original work from ://www.contribs.org/development/
#
# Copyright © 2013 Nethesis S.r.l.
# ://www.nethesis.it - support@nethesis.it
#
# Example config file /etc/vsftpd/vsftpd.conf
#
# The default compiled in settings are fairly paranoid. This sample file
# loosens things up a bit, to make the ftp daemon more usable.
# Please see vsftpd.conf.5 for all compiled in defaults.
#
# READ THIS: This example file is NOT an exhaustive list of vsftpd options.
# Please read the vsftpd.conf.5 manual page to get a full idea of vsftpd’s
# capabilities.
#
#
# Uncomment this to enable any form of FTP write command.
write_enable=YES
#
# Default umask for local users is 077. You may wish to change this to 022,
# if your users expect that (022 is used by most other ftpd’s)
local_umask=022
#
# Uncomment this to allow the anonymous FTP user to upload files. This only
# has an effect if the above global write enable is activated. Also, you will
# obviously need to create a directory writable by the FTP user.
anon_upload_enable=NO
#
# Uncomment this if you want the anonymous FTP user to be able to create
# new directories.
anon_mkdir_write_enable=NO
anon_other_write_enable=NO
# Allow anonymous FTP? (Beware - allowed by default if you comment this out).
anonymous_enable=NO

# Uncomment this to allow local users to log in.
local_enable=YES

# specifies a home directory for each virtual user
user_sub_token=$USER

# Enable system users
pam_service_name=vsftpd


# Enable per-user configuration
user_config_dir=/etc/vsftpd/users

# Chroot all users
chmod_enable=YES
chroot_local_user=YES
chroot_list_enable=YES
virtual_use_local_privs=YES

# Authentication
userlist_deny=NO
userlist_enable=YES
userlist_file=/etc/vsftpd/user_list
#
# Activate directory messages - messages given to remote users when they
# go into a certain directory.
dirmessage_enable=YES
#
# The target log file can be vsftpd_log_file or xferlog_file.
# This depends on setting xferlog_std_format parameter
xferlog_enable=YES
dual_log_enable=YES
log_ftp_protocol=NO
syslog_enable=NO
#
# Make sure PORT transfer connections originate from port 20 (ftp-data).
# connect_from_port_20=NO
#
# If you want, you can arrange for uploaded anonymous files to be owned by
# a different user. Note! Using "root" for uploaded files is not
# recommended!
#chown_uploads=YES
#chown_username=whoever
#
# The name of log file when xferlog_enable=YES and xferlog_std_format=YES
# WARNING - changing this filename affects /etc/logrotate.d/vsftpd.log
#xferlog_file=/var/log/xferlog
#
# Switches between logging into vsftpd_log_file and xferlog_file files.
# NO writes to vsftpd_log_file, YES to xferlog_file
xferlog_std_format=YES
#
# You may change the default value for timing out an idle session.
#idle_session_timeout=600
#
# You may change the default value for timing out a data connection.
#data_connection_timeout=120
#
# It is recommended that you define on your system a unique user which the
# ftp server can use as a totally isolated and unprivileged user.
nopriv_user=ftp

hide_ids=YES

# allow access to users with writable home dir
allow_writeable_chroot=YES
# When "listen" directive is enabled, vsftpd runs in standalone mode and
# listens on IPv4 sockets. This directive cannot be used in conjunction
# with the listen_ipv6 directive.
listen=YES
listen_port=21
pasv_min_port=5500
pasv_max_port=5700
#
# This directive enables listening on IPv6 sockets. To listen on IPv4 and IPv6
# sockets, you must run two copies of vsftpd with two configuration files.
# Make sure, that one of the listen options is commented !!
#listen_ipv6=YES

tcp_wrappers=NO

rsa_cert_file=/etc/ssl/ftps/vsftpd.pem
rsa_private_key_file=/etc/ssl/ftps/vsftpd.pem
ssl_enable=YES
allow_anon_ssl=NO
force_local_data_ssl=YES
force_local_logins_ssl=YES
ssl_tlsv1=YES
ssl_sslv2=NO
ssl_sslv3=NO
require_ssl_reuse=NO
ssl_ciphers=HIGH

All I see in the logs, is in the vsftpd log, and it tells me this:

Tue May 9 17:05:04 2017 [pid 1936] CONNECT: Client "192.168.50.38"
Tue May 9 17:05:05 2017 [pid 1936] DEBUG: Client “192.168.50.38”, “Connection terminated without SSL shutdown - buggy client?”

A ls -lrt on /var/log/sssd/ doesnt show any altered log files when I attempt to log on.

FileZilla shows this:
Status: Connecting to 172.16.1.50:21…
Status: Connection established, waiting for welcome message…
Response: 220 (vsFTPd 3.0.2)
Command: AUTH TLS
Response: 234 Proceed with negotiation.
Status: Initializing TLS…
Status: Verifying certificate…
Status: TLS connection established.
Command: USER user@domain.com
Response: 530 Permission denied.
Error: Could not connect to server

Any help would be greatly appreciated, I have been tearing my hair out for the last two days and about to give up and switch back to virtual users.

Wheeeeelp :stuck_out_tongue:

IIRC TLS is not available with our config. You could try to disable it!

Maybe @giacomo has more hints…

You are correct, it is not supported in the default config, but this worked like a charm prior to switching to system users, and I can not think of anything impacted by it, other then vsftpd. On top, it works, as indicated by FileZilla’s connection log.

I will disable it and see if that changes anything, but what mistifies me most, is that there does not seem to be anything directed to sssd or pam.d, going by thye logs.

I will report back in a bit, thanks for having taken a look.

1 Like

/etc/vsftpd/vsftpd.conf

# ================= DO NOT MODIFY THIS FILE =================
# 
# Manual changes will be lost when this file is regenerated.
#
# Please read the developer's guide, which is available
# at <removed for link restriction reasons>
# original work from <removed for link restriction reasons>
#
# Copyright (C) 2013 Nethesis S.r.l. 
# <removed for link restriction reasons> - support@nethesis.it
# 
# Example config file /etc/vsftpd/vsftpd.conf
#
# The default compiled in settings are fairly paranoid. This sample file
# loosens things up a bit, to make the ftp daemon more usable.
# Please see vsftpd.conf.5 for all compiled in defaults.
#
# READ THIS: This example file is NOT an exhaustive list of vsftpd options.
# Please read the vsftpd.conf.5 manual page to get a full idea of vsftpd's
# capabilities.
#
#
# Uncomment this to enable any form of FTP write command.
write_enable=YES
#
# Default umask for local users is 077. You may wish to change this to 022,
# if your users expect that (022 is used by most other ftpd's)
local_umask=022
#
# Uncomment this to allow the anonymous FTP user to upload files. This only
# has an effect if the above global write enable is activated. Also, you will
# obviously need to create a directory writable by the FTP user.
anon_upload_enable=NO
#
# Uncomment this if you want the anonymous FTP user to be able to create
# new directories.
anon_mkdir_write_enable=NO
anon_other_write_enable=NO
# Allow anonymous FTP? (Beware - allowed by default if you comment this out).
anonymous_enable=NO

# Uncomment this to allow local users to log in.
local_enable=YES

# specifies a home directory for each virtual user
user_sub_token=$USER

# Enable system users
pam_service_name=vsftpd


# Enable per-user configuration
user_config_dir=/etc/vsftpd/users

# Chroot all users
chmod_enable=YES
chroot_local_user=YES
chroot_list_enable=YES
virtual_use_local_privs=YES

# Authentication
userlist_deny=NO
userlist_enable=YES
userlist_file=/etc/vsftpd/user_list
#
# Activate directory messages - messages given to remote users when they
# go into a certain directory.
dirmessage_enable=YES
#
# The target log file can be vsftpd_log_file or xferlog_file.
# This depends on setting xferlog_std_format parameter
xferlog_enable=YES
dual_log_enable=YES
log_ftp_protocol=NO
syslog_enable=NO
#
# Make sure PORT transfer connections originate from port 20 (ftp-data).
# connect_from_port_20=NO
#
# If you want, you can arrange for uploaded anonymous files to be owned by
# a different user. Note! Using "root" for uploaded files is not
# recommended!
#chown_uploads=YES
#chown_username=whoever
#
# The name of log file when xferlog_enable=YES and xferlog_std_format=YES
# WARNING - changing this filename affects /etc/logrotate.d/vsftpd.log
#xferlog_file=/var/log/xferlog
#
# Switches between logging into vsftpd_log_file and xferlog_file files.
# NO writes to vsftpd_log_file, YES to xferlog_file
xferlog_std_format=YES
#
# You may change the default value for timing out an idle session.
#idle_session_timeout=600
#
# You may change the default value for timing out a data connection.
#data_connection_timeout=120
#
# It is recommended that you define on your system a unique user which the
# ftp server can use as a totally isolated and unprivileged user.
nopriv_user=ftp

hide_ids=YES

# allow access to users with writable home dir
allow_writeable_chroot=YES
# When "listen" directive is enabled, vsftpd runs in standalone mode and
# listens on IPv4 sockets. This directive cannot be used in conjunction
# with the listen_ipv6 directive.
listen=YES
listen_port=21
pasv_min_port=5500
pasv_max_port=5700
#
# This directive enables listening on IPv6 sockets. To listen on IPv4 and IPv6
# sockets, you must run two copies of vsftpd with two configuration files.
# Make sure, that one of the listen options is commented !!
#listen_ipv6=YES

tcp_wrappers=NO

#rsa_cert_file=/etc/ssl/ftps/vsftpd.pem
#rsa_private_key_file=/etc/ssl/ftps/vsftpd.pem
#ssl_enable=YES
#allow_anon_ssl=NO
#force_local_data_ssl=YES
#force_local_logins_ssl=YES
#ssl_tlsv1=YES
#ssl_sslv2=NO
#ssl_sslv3=NO
#require_ssl_reuse=NO
#ssl_ciphers=HIGH

Restarted vsftpd using ‘service vsftpd restart’ and reconfigured FileZilla to not use TLS, output below:

Status:	Connecting to 172.16.1.50:21...
Status:	Connection established, waiting for welcome message...
Response:	220 (vsFTPd 3.0.2)
Command:	USER someuser@domain.com
Response:	530 Permission denied.
Error:	Could not connect to server

It seems this has no impact whatsoever.

I am new to sssd and pam. Given that anything I do through Samba, also triggers a log in sssd, I would expect the same behaviour for vsftpd, but nothing I do with ftp, ever makes it to sssd, or so it seems.

In the above config, the referenced file, to my understanding, would be /etc/pam.d/vsftpd
It’s content:

#%PAM-1.0
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	system-auth
account    include	system-auth
session    required     pam_loginuid.so
session    include	system-auth

Note that I altered this file a bit. Where it reads system-auth, it used to have password-auth. Neither scenario yields loglines. Is this the/a correct way to direct the authentication to pam, and thrue the configured authentication chain that should reach sssd, if configured. Right ?

Given that when I order my log files by date/time, I see no altered files after an attempted connect, barring the vsftpd.log, which contains useless information, how could I go about diagnosing this further ?

For completeness, and including the pre-system-user scenario, /var/log/vsftpd.log

Mon May  8 11:38:37 2017 [pid 9418] CONNECT: Client "192.168.50.38"
Mon May  8 11:38:37 2017 [pid 9417] [someuser] OK LOGIN: Client "192.168.50.38"
Mon May  8 11:38:51 2017 [pid 9419] [someuser] OK UPLOAD: Client "192.168.50.38", "/somefolder/test", 0.00Kbyte/sec
//
Wed May 10 09:46:06 2017 [pid 3308] CONNECT: Client "192.168.50.38"
Wed May 10 09:46:12 2017 [pid 3310] CONNECT: Client "192.168.50.38"

Is there a way to make the logging more verbose on either sssd or pam or vsftpd ? (given I already have debug_level = 7 in sssd.conf ?

(Given the 530 permission denied error, I would expect a log somewhere. I also checked the actual domain controller for logging, but nothing there either. The only log that shows something when I attempt to log in, is the /var/log/vsftpd log. Based on that I would assume an error in my vsftpd.conf, but I can not figure out what could be wrong there. Based on my understanding, the line

# Enable system users
pam_service_name=vsftpd

…would tell vsftpd to use the /etc/pam.d/vsftpd file, and even when I reduce that down to

#%PAM-1.0
session    include	system-auth

…I get nothing in the logs beside the 530 error in /var/log/vsftpd.log

Any pointer would be greatly appreciated, thanks!

Hi Jeron, you don’t need to manually change vsftp or pam connection, proceed as following (just tested):

  • Create a user test inside your AD (eg. ad.nethserver.org), make sure shell access is enabled
  • On the member server (eg. member.ad.nethserver.org), install nethserver-vsftpd and enable it
  • On the member server, configure vsftp:
config setprop vsftpd UserType system
db accounts set test user FTPAccess enabled
signal-event nethserver-vsftpd-save
  • Access at least once the member server with user using SSH (this step will create the user home dir):
ssh test@member.ad.nethserver.org

Hope this helps :slight_smile:

2 Likes

Hello giacomo,

This somewhat solves the issue, but one last issue remains … you said:
make sure shell access is enabled

I can not for the life of me figure out how and where to do that, as the users page of the nethserver webinterface shows this option, but I can not check the box.

I DO get valid authentication log entries now, but filezilla is still returning 530, but iirc this is due the shell not being properly configured, and given that I can not find a way to change it, this seems to be the last issue that I do not fully grasp.

Thanks a ton for helping so fast and so adequate. Much appreciated.

If I use RSAT from a windows machine, this option is greyed out.

AFAIK you can’t change the shell access in AD after the user has been created, you need to do it when creating.
I think it’s a limitation of the AD schema, but I’m not an expert of it (and I don’t want to be :stuck_out_tongue: ).

Even with samba-tool you can’t change the flag after creation.

So, I created a new test user, and made sure the checkbox for SSH was active. I can log in using test@domain.com on the member server, using SSH. It will give me a propper shell, and I can work like normal.

If I enter the same credentials in vsftpd, after executing ‘db accounts set test user FTPAccess enabled’, I still get the 530 error.

I seem to have been sloppy as well, as I reported I do get valid login messages in the log now. This not the case … it was a samba initiated login, and that already worked fine.

I have restored a vanilla snapshot and used the original vsftpd for /etc/pam.d/vsftpd … but nothing gets logged, in either var/log/* or var/log/sssd/* regarding vsftpd logins, regardless of me editing that file to either use system-auth or password-auth.

I have also left out the TLS part, but that doesnt change a thing either.

Could someone post a working /etc/pam.d/vsftpd just for reference and for my sanity (I might have altered it previously without remembering, making my vanilla not so vanilla …)

What could I change to deffinately produce an error log when I press connect in my ftp client, barring the useless notes in my vsftpd.log ?

You can obtain the original version like this:

rpm -e --nodeps vsftpd
yum install vsftpd

This is becomming quite the headache …

I just entered the commands you suggested, and was able to verify that I actually managed to preserve the original configuration file. However, at that point my test user could connect. I then added the TLS info, and couldnt connect any longer. I then commented out the TLS info, and cant connect any longer.

I used signal-event nethserver-vsftpd-save to get the altered e-smith file with TLS info active … I begin to suspect my templates are busted somehow.

After this I re-reinstalled the vanilla vsftpd files … and lo and behold, it worked again. used signal-event, stopped working again. At least I know where to start looking now … I will update this once I figured out why I have been wasting your time.

Thanks again for helping out!

2 Likes

So, installing vsftpd thru yum does NOT give me the default configuration.

EDIT: I left the default config out, but just pasted what is different between the two files. It is irrelevant anyway, see end of post.

Default Nethserver config file:

# Enable virtual users
guest_enable=YES
pam_service_name=vsftpd-virtual
local_root=/var/lib/nethserver/ftp/$USER

VS my system-user enabled, pasv port altered and TLS added one:

# Enable system users
pam_service_name=vsftpd
//
pasv_min_port=5500
pasv_max_port=5700
//
#rsa_cert_file=/etc/ssl/ftps/vsftpd.pem
#rsa_private_key_file=/etc/ssl/ftps/vsftpd.pem
#ssl_enable=YES
#allow_anon_ssl=NO
#force_local_data_ssl=YES
#force_local_logins_ssl=YES
#ssl_tlsv1=YES
#ssl_sslv2=NO
#ssl_sslv3=NO
#require_ssl_reuse=NO
#ssl_ciphers=HIGH

This is what I get when I install thru yum:

# Example config file /etc/vsftpd/vsftpd.conf
#
# The default compiled in settings are fairly paranoid. This sample file
# loosens things up a bit, to make the ftp daemon more usable.
# Please see vsftpd.conf.5 for all compiled in defaults.
#
# READ THIS: This example file is NOT an exhaustive list of vsftpd options.
# Please read the vsftpd.conf.5 manual page to get a full idea of vsftpd's
# capabilities.
#
# Allow anonymous FTP? (Beware - allowed by default if you comment this out).
anonymous_enable=YES
#
# Uncomment this to allow local users to log in.
# When SELinux is enforcing check for SE bool ftp_home_dir
local_enable=YES
#
# Uncomment this to enable any form of FTP write command.
write_enable=YES
#
# Default umask for local users is 077. You may wish to change this to 022,
# if your users expect that (022 is used by most other ftpd's)
local_umask=022
#
# Uncomment this to allow the anonymous FTP user to upload files. This only
# has an effect if the above global write enable is activated. Also, you will
# obviously need to create a directory writable by the FTP user.
# When SELinux is enforcing check for SE bool allow_ftpd_anon_write, allow_ftpd_full_access
#anon_upload_enable=YES
#
# Uncomment this if you want the anonymous FTP user to be able to create
# new directories.
#anon_mkdir_write_enable=YES
#
# Activate directory messages - messages given to remote users when they
# go into a certain directory.
dirmessage_enable=YES
#
# Activate logging of uploads/downloads.
xferlog_enable=YES
#
# Make sure PORT transfer connections originate from port 20 (ftp-data).
connect_from_port_20=YES
#
# If you want, you can arrange for uploaded anonymous files to be owned by
# a different user. Note! Using "root" for uploaded files is not
# recommended!
#chown_uploads=YES
#chown_username=whoever
#
# You may override where the log file goes if you like. The default is shown
# below.
#xferlog_file=/var/log/xferlog
#
# If you want, you can have your log file in standard ftpd xferlog format.
# Note that the default log file location is /var/log/xferlog in this case.
xferlog_std_format=YES
#
# You may change the default value for timing out an idle session.
#idle_session_timeout=600
#
# You may change the default value for timing out a data connection.
#data_connection_timeout=120
#
# It is recommended that you define on your system a unique user which the
# ftp server can use as a totally isolated and unprivileged user.
#nopriv_user=ftpsecure
#
# Enable this and the server will recognise asynchronous ABOR requests. Not
# recommended for security (the code is non-trivial). Not enabling it,
# however, may confuse older FTP clients.
#async_abor_enable=YES
#
# By default the server will pretend to allow ASCII mode but in fact ignore
# the request. Turn on the below options to have the server actually do ASCII
# mangling on files when in ASCII mode.
# Beware that on some FTP servers, ASCII support allows a denial of service
# attack (DoS) via the command "SIZE /big/file" in ASCII mode. vsftpd
# predicted this attack and has always been safe, reporting the size of the
# raw file.
# ASCII mangling is a horrible feature of the protocol.
#ascii_upload_enable=YES
#ascii_download_enable=YES
#
# You may fully customise the login banner string:
#ftpd_banner=Welcome to blah FTP service.
#
# You may specify a file of disallowed anonymous e-mail addresses. Apparently
# useful for combatting certain DoS attacks.
#deny_email_enable=YES
# (default follows)
#banned_email_file=/etc/vsftpd/banned_emails
#
# You may specify an explicit list of local users to chroot() to their home
# directory. If chroot_local_user is YES, then this list becomes a list of
# users to NOT chroot().
# (Warning! chroot'ing can be very dangerous. If using chroot, make sure that
# the user does not have write access to the top level directory within the
# chroot)
#chroot_local_user=YES
#chroot_list_enable=YES
# (default follows)
#chroot_list_file=/etc/vsftpd/chroot_list
#
# You may activate the "-R" option to the builtin ls. This is disabled by
# default to avoid remote users being able to cause excessive I/O on large
# sites. However, some broken FTP clients such as "ncftp" and "mirror" assume
# the presence of the "-R" option, so there is a strong case for enabling it.
#ls_recurse_enable=YES
#
# When "listen" directive is enabled, vsftpd runs in standalone mode and
# listens on IPv4 sockets. This directive cannot be used in conjunction
# with the listen_ipv6 directive.
listen=NO
#
# This directive enables listening on IPv6 sockets. By default, listening
# on the IPv6 "any" address (::) will accept connections from both IPv6
# and IPv4 clients. It is not necessary to listen on *both* IPv4 and IPv6
# sockets. If you want that (perhaps because you want to listen on specific
# addresses) then you must run two copies of vsftpd with two configuration
# files.
# Make sure, that one of the listen options is commented !!
listen_ipv6=YES

pam_service_name=vsftpd
userlist_enable=YES
tcp_wrappers=YES

So it seems there is more at play here.

After install thru yum, and starting vsftpd, authentication works like expected (it seems):

Status:	Connecting to 172.16.1.50:21...
Status:	Connection established, waiting for welcome message...
Status:	Logged in
Status:	Retrieving directory listing...
Status:	Directory listing of "/var/lib/nethserver/home/test" successful

So, I finally decided to go hardcore, and fired up vi. Lo and behold, my dumb text editor neglected to place EOL’s … which Linux doesnt really fancy all that much.

Kill me now please.

The combined problems in this configuration boil down to my text editor not placing EOL’s and my regular users not having shell access. The only remaining issue seems to get this to work with previously created users, which have no shell access.

Eureka. If you open the mcc.exe snapin Active Directory Users and Computers, and turn on Advanced Features, you will have an ‘Attribute Editor’ tab on which you can set the logon shell attribute. This can be used to properly set the logon shell.

Thanks again for all the help and so sorry that I didnt check if the fileformat was ok … should have checked that sooner. Sorry.

4 Likes