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

[Andrew Bartlett]

This is worth looking into, see below:

Steve Langasek wrote:
> 
> 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.

I think it it excellent, and I use it to automatically update a users
smbpasswd file when they change their password via pam, forcing them to
use cracklib in the process.

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

One thing this would make easier is stacking other PAM modules with
samba, using for example the traditional password files to check for
account expiry, using session modules and using the numerous other
features of PAM.  (I am thinking time-based etc.)

I might be wrong, but I understand that some other NT applications can
use NTLM challenge-response, like telnet i think.  (It was mentioned on
bugtraq that W2K's telnet.exe was attempting NTLM authentication against
telnet servers and this could compromise security.  It is however better
than plain-text, and could be used with this kind of pam module).

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

The only issue I see with this whole arrangement is the security of
passwords, the NTLM password is unsalted, and while the rest of unix is
moving towards MD5 and Blowfish password hashes we have to keep
plain-text equivalent weak hashes lying around.  I think that root
should at least be kept out of this file, but that rules out
administrator access.  Just my .02c worth.

-- 
Andrew Bartlett
abartlet at pcug.org.au