On Thu, 2003-06-19 at 17:23, Howard Chu wrote:
> This thread seems to be arriving out-of-order, so I'm a bit confused on the
> context. The thread appears out of order on the samba.org mailing list
> archives as well.
Dunno - I'm wondering if I'm being moderated on the openldap.org side...
(not got back my post there).
> Since there's already plenty to do, first I'd like to understand why using
> the SASL NTLM mechanism won't work. In looking at cyrus/sasl/plugins/ntlm.c,
> this appears to use a plaintext userPassword, like most of the other SASL
I'm not looking at SASL logins here - that's a different kettle of
fish. What I'm looking for is for a simple bind to an OpenLDAP server
to use the ntPassword stored on that DN.
(and the issue of plaintext password storage is one reason I would
probably never use that mechanism).
> Using a scheme like '{NTPASSWORD}sambaNTpassword' isn't really practical with
> the current password check/hash mechanism; the password functions aren't
> given any context about the DN or entry being authenticated. As such, there
> isn't enough info to specify which entry's sambaNTpassword to retrieve. And
> also, the passwd library has no API to perform the retrieval, short of
> issuing its own ldapsearch().
OK. What would you required to be able to implement a password scheme
that can use the same values? I'm not so sure about making Samba read
the userPassword attribute - I don't want to get in the way of yet other
applications using that attribute, and we need to store *both* the NT
and LM passwords in a consistent manner, and not step on toes in the
process.
Samba 3.0 went to particular effort to avoid stepping on toes with
attributes names, so I'm a little worried about using userPassword...
I'm also unsure of the reasons behind the original decision.
> If it were just a matter of fixing the case sensitivity issue in the {LANMAN}
> mech, that would be OK. But Andrew mentioned something about needing to
> extract a session key from the handshake - it would seem that none of these
> simple password mechs would accomodate this requirement.
What I'm meaning here is that Samba cannot pass it's authentication
routines off to some other party to complete. It needs the
sambaNTpassword itself.
That's a side discussion - the real issue here is just the simple binds
to the LDAP server, and sanity for our administrators.
Andrew Bartlett
--
Andrew Bartlett abartlet@pcug.org.au
Manager, Authentication Subsystems, Samba Team abartlet@samba.org
Student Network Administrator, Hawker College abartlet@hawkerc.net
http://samba.org http://build.samba.org http://hawkerc.net
Attachment:
signature.asc
Description: This is a digitally signed message part