For about two weeks its no possible to login with a local user by a ftp client.
the ftp server tries to authenticate the local user against the active directory.
have a look at the configuration files in /etc/pam.d, especially /etc/pam.d/vsftpd and /etc/pam.d/common-auth. Were these files recently changed, which might explain the change in behavior?
(it is possible to change the PAM service name in /etc/vsftpd.conf, see pam_service_name option there.)
By changing /etc/pam.d/vsftpd, you may configure to use a different authentication path for vsftpd than the general default. Or was the server configured the other way around, using local auth as a default and having a differing config for sshd? Anyhow, that’s where you can change to match your requirements…
the date of last change is 7th April (vsftp) and 15th Mai (common-auth-pc).
The pam_service_name is vsftp.
I didn’t change something in /etc/pam.d/vsftp or /etc/vsftp.conf.
In /etc/security/pam_winbind I configured the require_membership_of to limit access to the server.
does the current PAM configuration suggest that vsftpd should use locla users, while sshd should verify the credentials against the domain? Because the log message from you initial post clearly shows that PAM is validating the vsftp login against the domain, which I understood is not what you intended.
Start with /etc/pam.d/vsftpd and follow the chain of “auth” entries. One of the modules will be “pam_winbind” (as per your initial message) to authenticate against your AD domain, while checks against the local users in /etc/passwd is done via pam_unix. See “man pam_unix” and “man pam_winbind” for details on these modules, and “man 8 pam” and the various sources on the net for a general description of PAM.
#auth sufficient pam_ftp.so
auth required pam_shells.so
auth include common-auth
account include common-account
password include common-password
session required pam_loginuid.so
session include common-session[/CODE][/QUOTE]
Since you wrote that common-auth was last modified many weeks ago and the problem surfaced only recently, I’m rather curious how this did work at all. Maybe it wasn’t local users that were checked, but some AD account nevertheless? Introducing the group filter may then have broken that path to these accounts?
between a SLES12 SP2 plain installation with a SLES12 SP2 current updates installation
are both servers “AD-enabled”? Because the differences you show look like the result of activating AD integration (pam_winbind) and allowing creation of home dir on login (pam_mkhomedir).
pam_localuser, OTOH, looks like a manual addition. It will only check for the presence of a user in /etc/passwd and not by itself allow local users to log in.
How’s the actual authentication set up? Do you see pam_unix as a sufficient module in there, before winbind is invoked?
between a SLES12 SP2 plain installation with a SLES12 SP2 current updates installation
are both servers “AD-enabled”? Because the differences you show look like the result of activating AD integration (pam_winbind) and allowing creation of home dir on login (pam_mkhomedir).
pam_localuser, OTOH, looks like a manual addition. It will only check for the presence of a user in /etc/passwd and not by itself allow local users to log in.
How’s the actual authentication set up? Do you see pam_unix as a sufficient module in there, before winbind is invoked?
Regards,
J[/QUOTE]
The reason why local users can’t login, is the “require_membership_of” setting in /etc/security/pam_winbind.conf
Only these users/groups can login via ftp.
Is it possible to add a local user to this setting?
