Getting OpenLDAP to auth users against sambaNTPassword

Andrew Bartlett abartlet at
Thu Jun 19 07:46:45 GMT 2003

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 mailing list
> archives as well.

Dunno - I'm wondering if I'm being moderated on the 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

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 at
Manager, Authentication Subsystems, Samba Team  abartlet at
Student Network Administrator, Hawker College   abartlet at
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url :

More information about the samba-technical mailing list