[Samba] smbd to authenticate via pam modules

[David Komanek]

On 09/08/2016 07:48 PM, Volker Lendecke wrote:
> 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


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