samba - Sep 2016 - smbd to authenticate via pam modules

Hi,

I have a simple setup with pam modules to use kerberos authentication
(heimdal kdc) for various services, i.e. ssh/scp/sftp, ftp and others. I
would like to connect my standalone smbd (no AD membership) to this
system, but have problems to force smbd to use pam.

local smbpasswd works
spnego + kerberos works with a ticket
but
pam modules are not accessed at all

In my test setup, local samba password differs from the kerberos one, to
be sure, how I got authenticated. If I use
client use spnego = yes
realm = MY.REALM.REDACTED
kerberos method = dedicated keytab
dedicated keytab file = /etc/krb5.keytab
kerberos ticket is verified and I get logged in. After removing those 4
lines, giving the kerberos password ends up with

session setup failed: NT_STATUS_LOGON_FAILURE

and there is nothing logged by pam libraries, so I suppose they are not
called at all (other services are using it successfully and logging
without problems). But as long as I am using plaintext passwords, it
should be going to pam libraries, shouldn't it ? Pam configuration is
working for other services, so I suppose the problem is in my samba setup.

It is samba 4.2.10-Debian on Jessie (Debian 8).

Hopefully it would be obvious to someone here what I am doing wrong.

Thanks in advance,

David



smb.conf:
--------------

[global]

workgroup = WORKGROUP
dns proxy = no
log file = /var/log/samba/log.%m
max log size = 1000
syslog = 4
panic action = /usr/share/samba/panic-action %d
server role = standalone server

#with the following 4 lines, kerberos ticket is verified and kerberos
authentication works, but this is not through PAM
client use spnego = yes
realm = MY.REALM.REDACTED
kerberos method = dedicated keytab
dedicated keytab file = /etc/krb5.keytab

encrypt passwords = no
security = user
client plaintext auth = yes
client ntlmv2 auth = no
client lanman auth = yes

obey pam restrictions = no

unix password sync = yes
passwd program = /usr/bin/passwd %u
passwd chat = *Enter\snew\s*\spassword:* %n\n
*Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
pam password change = no
map to guest = bad user
usershare allow guests = yes


[homes]
   comment = Home Directories
   browseable = no
   read only = yes
   create mask = 0700
   directory mask = 0700
   valid users = %S

[printers]
   comment = All Printers
   browseable = no
   path = /var/spool/samba
   printable = yes
   guest ok = no
   read only = yes
   create mask = 0700

[print$]
   comment = Printer Drivers
   path = /var/lib/samba/printers
   browseable = yes
   read only = yes
   guest ok = no



/etc/pam.d/samba
---------------------------
@include common-auth
@include common-account
@include common-session-noninteractive

or alternatively

#%PAM-1.0
auth    include common-auth
account include common-account
session include common-session-noninteractive


common-auth
--------------------
auth    sufficient      pam_krb5.so debug use_first_pass forwardable
auth    required        pam_unix.so nullok_secure use_first_pass

common-account
-------------------------
account sufficient      pam_krb5.so
account required        pam_unix.so

common-session-noninteractive
---------------------------------------------
session required        pam_unix.so
session    required   pam_limits.so

On Thu, Sep 08, 2016 at 04:59:14PM +0200, David Komanek via samba
wrote:
> and there is nothing logged by pam libraries, so I suppose they are not
> called at all (other services are using it successfully and logging
> without problems). But as long as I am using plaintext passwords, it
> should be going to pam libraries, shouldn't it ? Pam configuration is
> working for other services, so I suppose the problem is in my samba setup.
You're not using plaintext anymore. Even if you type in your pw into
smbclient, it is using at least a challenge-response authentication.

Using PAM for authentication is not possible with SMB. PAM wants to
see the plain text password, which smbd never sees.

Regards,

Volker

On 09/08/2016 05:10 PM, Volker Lendecke wrote:
> On Thu, Sep 08, 2016 at 04:59:14PM +0200, David Komanek via samba wrote:
>> and there is nothing logged by pam libraries, so I suppose they are not
>> called at all (other services are using it successfully and logging
>> without problems). But as long as I am using plaintext passwords, it
>> should be going to pam libraries, shouldn't it ? Pam configuration
is
>> working for other services, so I suppose the problem is in my samba
setup.
> You're not using plaintext anymore. Even if you type in your pw into
> smbclient, it is using at least a challenge-response authentication.
>
> Using PAM for authentication is not possible with SMB. PAM wants to
> see the plain text password, which smbd never sees.
>
> Regards,
>
> Volker
Thanks for the quick response. The manpage for smb.conf of version
4.2.10 states that

obey pam restrictions (G)

           When Samba 3.0 is configured to enable PAM support (i.e.
--with-pam), this parameter will control whether or not Samba should
obey PAM's account and session management directives.
           The default behavior is to use PAM for clear text
authentication only and to ignore any account or session management.
Note that Samba always ignores PAM for authentication in the
           case of encrypt passwords = yes. The reason is that PAM
modules cannot support the challenge/response authentication mechanism
needed in the presence of SMB password encryption.

So was it just 3.0 version-specific and Samba 4 discontinued this
feature ? If so, what is the right way to authenticate against kerberos
or other external service at the backend (so that the user does not need
to issue a ticket in advance) ? I know there is a possibility to store
passwords in local database, but its just a duplication of information
and need for an extra orchestration in this case. Hopefuly there is some
simple way to achieve that without doing this or using the AD overhead.
I just spent whole day googling with no good solution at the end, so I
am probaly missing some terminology to produce well formulated questions.

Sincerely,

  David