PAM & Samba [was Re: TODO list....]
gcarter at valinux.com
Mon Oct 2 14:12:02 GMT 2000
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
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. :-)
/\ 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
"...a hundred billion castaways looking for a home."
- Sting "Message in a Bottle" ( 1979 )
More information about the samba-technical