Getting OpenLDAP to auth users against sambaNTPassword

Andrew Bartlett abartlet at
Thu Jun 19 09:01:54 GMT 2003

On Thu, 2003-06-19 at 17:46, Andrew Bartlett wrote:
> 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 looked at that code, and it's an NTLMSSP implementation, not a way to
do authentication against an NT hash.  Unfortunately NTLMSSP is much
more complex than is made out here...  (Dealing with things like NTLMv2,
and a lot more flags just to start with...)

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

Having looked again at the OpenLDAP archives I want to stress again that

 - Do not have access to the original passwords
 - Could not, even if we wanted to, store the plaintext (would rule us
out of most organizations).
 - We can't do an LDAP bind the authenticate the user, even to an
NTLMSSP aware server.

Furthermore, it would be *highly* advantageous if we could update the NT
and LM passwords on user password changes, but I'm not holding my

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

On the sanity point - what I really don't want is to write a doco that
tells our admins to do this:

 - Install (and configure Cyrus SASL)  
 - Configure it for PAM authentication.  
 - Configure PAM to use pam_winbind.  
 - Configure winbind with 'winbind use default domain = yes'.  
 - Configure Samba to use LDAP.  
 - Set the userPassword to '{SASL}x'.  
 - Hope the account Samba users doesn't ahve this set (loops).  
 - Pray that the chain doesn't fall apart....

It *has* to be easier than this...

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