[Samba] smbd to authenticate via pam modules

[David Komanek via samba]

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




--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba

[Volker Lendecke via samba]

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

[David Komanek via samba]

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

[Volker Lendecke via samba]

On Thu, Sep 08, 2016 at 05:25:44PM +0200, David Komanek wrote:
> 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.

This is for everything but password checks. We have removed "encrypt
passwords = no", so you can't do password checks against PAM anymore.

> 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.

Kerberos is just the right thing to do. If you don't want AD, set up a
classic Samba domain with "domain logons = yes" and a normal join by
the member. The DC needs the NT hashes in smbpasswd or passdb.tdb
though.

Volker

[David Komanek via samba]

Hello,

so simple drive mapping with just the knowledge of UNC path and SSO
login+password without further management seems not possible in my
particular setup. But thanks anyway for clarifying this to me.

Best regards,

David