PAM & Samba [was Re: TODO list....]

[Gerald Carter]

Seth Vidal wrote:
> 
> pam_ldap with a laced in samba schema.
> pam talks to an ldap server and checks certain information.
> it would require modifying or rewriting the pam_ldap 
> module but its quite do-able.

Seth, couple of points here.

  o by settling on PAM we have automatically kicked 
    our selves out of non-PAM platforms.  I think 
    the compile time option is a good thing.  I do not know
    that status of the current PAM support.  Would someone
    be interested in taking a look and possibling 
    cleaning things up if necessary, that would be great.

  o I need to see the exact structure and function 
    declarations that would allow us to get this authorization
    data back for session management.  My current view of PAM
    is that it is linked very close to the standard /etc/passwd
    fields.

  o By providing a thin abstraction layer on top of PAM
    we can fill in the gaps with default information 
    that PAM cannot provide (i.e. authorization data).  
    This is basically what has to be done with smbpasswd
    file information now.

> maybe I'm lost but I was fairly sure that it made 
> little difference what you passed pam. while giving 
> it a plaintext pw is ideal it is not an option (b/c 
> of windows's LMhash passwords) - and if memory serves 
> lmhash's are plaintext equivalents (in that they are 
> replayable) then the lmhash can be treated identically 
> to a plaintext (excluding the fact that it is not 
> the ACTUAL password)

No.  Since is a PAM world you are describing, Samba 
would never know what the hash was.  Remember that 
in the challenge-response, the hash is never sent 
over the wire.  Either (a) the PAM module would have 
to generate the 8 byte challenge, or (b) Samba would 
have to generate it and then pass it and the client's 
response to PAM.

> I am not against this - I was just noting that I thought 
> a lot of it could be done via pam - and I think it can 
> - the stacking of modules would allow for some very 
> clever authentication modules for supporting A LOT of
> diverse users storing passwords in a variety of places.



> example - if you're running with plaintext passwords 
> enabled in windows:

Here'sthe rub though.  We have to be able to deal with
the ntlm password encryption/challenge-response thing.

> auth sufficient pam_krb5
> auth sufficient pam_ldap  use_first_pass
> auth sufficient pam_unix nis use_first_pass
> 
> (please excuse if my syntax is off - Its early in 
> the morning for me)

That's fine (and your syntax is close enough for me). :-)

> I'm not sure how one would go about doing the same in 
> the system your proposing but it seems like if you're 
> wanting krb5 auth'ing it would be handy.

The problem with moving from one authentication 
scheme to another (for example, Kerberos and NIS...
now there's a combination for you :) ) is the incompatible
encryption algorithms.  The only common point they have 
is plain text.  However, the need to support ntlm
is so overwhelming, that unless someone can show me 
an actual way to support all of the authentication 
and authorization information I need, PAM will have to remain
either a compile time option or a plugable backend.

At this point in the discussion, we need code to prove that
PAM is able to meet the requirements.  Currently I do not 
believe that it can, but am always willing to eat crow. :-)





Cheers, jerry
----------------------------------------------------------------------
   /\  Gerald (Jerry) Carter                     Professional Services
 \/    http://www.valinux.com  VA Linux Systems    gcarter at valinux.com
       http://www.samba.org       SAMBA Team           jerry at samba.org
       http://www.eng.auburn.edu/~cartegw

       "...a hundred billion castaways looking for a home."
                                - Sting "Message in a Bottle" ( 1979 )