Samba and PAM [ Re: VFS Implementation and user authentication ]

[Steve Langasek]

On Thu, 21 Sep 2000, David Lee wrote:

> Suppose (and this is more than hypothetical) one has a UNIX (Solaris) 
> system using typical UNIX authentication within itself.  One then adds
> lots of client PCs onto which users wish to map their UNIX home directory,
> using their UNIX identifier and password.  (That is, there is logically a
> single id/pw combination across UNIX and the PCs.)

> As described, this requires that plaintext passwords be enabled on the
> PC, to allow use (via Samba) of the UNIX crypt(3) against the UNIX
> password/shadow file.  The whole of the world, quite rightly, is moving
> away from plaintext-over-the-wire, but the above requirements run counter
> to this, forcing us back to plaintext.

> My idea is to set up, and use PAM to maintain, a parallel file (probably
> very similar to "smbpasswd"!).  That is, the user's password is stored
> twice: once in the traditional UNIX password/shadow/crypt(3) model, the
> other in smbpasswd.  This way, both UNIX and the PCs can, from the user's
> perspective, operate with a single logical password (which is maintained 
> behind the scenes in two parallel locations, in two parallel encryptions,
> from two PAM modules).

> [ Theoretically, I suppose, one could take it a stage further: ditch
> pam_unix, and have UNIX doing its own authentication and password
> management via NT-style encryption!  But let's not let that distract us. ]

Oh, I agree with you that it would be useful to have a PAM module that can
handle NTLM hashed passwords.  In fact, I agree so much that I've already
written a PAM module that does this. ;D  pam_smbpass is a bear to build (it
exists only as a patch against Samba right now), but it does everything you've
asked for here.  It includes password changing, authentication, and
authorization (account expiry checking) functionality, and I'm also working on
a 'migrate' option for the authentication component, equivalent to Samba's
'update encrypted' option.

> It still seems to me that it would be useful for Samba to be able to use 
> PAM to authenticate NT clients.

How do you foresee this being useful?  There are two main benefits of
PAMifying an application, as I understand it:  the first is to be able to
reuse the authentication code across applications without modification; the
second is to be able to administratively reconfigure an application's
authentication mechanism without recompiling.  But the first is not relevant
because a PAM module designed to do NTLM challenge-response would not be
useful for any other existing Unix apps, because no other apps use Samba's
specialized protocol, and the second is not relevant because NTLM
challenge-response is the only real auth option we have in Samba.  Of
course, there may be other advantages that I'm not seeing, and if so I'd be
happy to be enlightened.

> (A completely different alternative: does anyone know whether such
> authentication ("lanman challenge/response"?) is possible against an LDAP
> server?  That is, PC maps drive from UNIX, which itself uses pam_ldap;
> could LDAP (e.g. OpenLDAP) handle lanman challege/response?

Samba's own support for storing password entries in LDAP is done using a
different schema than the one used by pam_ldap.  If compiled against Samba
configured with LDAP support, pam_smbpass could use LDAP the same way Samba
does, but this would still involve sending the password from the LDAP server
to Samba for authentication.  I'm not sure if that's what you have in mind
here or not.

Steve Langasek
postmodern programmer