RE: Getting OpenLDAP to auth users against sambaNTPassword

["Howard Chu" <hyc@highlandsun.com>]

> -----Original Message-----
> From: Andrew Bartlett [mailto:abartlet@samba.org]

OK, first things first: I'm philosophically opposed to all of these
"{TAG}data" userPassword schemes. I think Kurt would say the same, though
possibly for different reasons. Their introduction in RFC2307 was bogus,
along with most of the other content of RFC2307. (But that's a topic for a
different conversation...)

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

This attitude strikes me as odd. You're unhappy about a password stored in
cleartext in a secure database file of your server, but you're perfectly
happy to send the password in the clear across a network to perform an LDAP
Simple Bind? SASL is far from perfect, but I think it's also far better than
the Simple Bind alternative.

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

I think perpetuating the "{SCHEME}data" approach is only going to cause more
headaches. For example, if you have an existing installation that's using
"{CRYPT}xxxxxx" for userPassword already, and you want to add "{NTLM}yyyyy"
then you have a synchronization problem. (userPassword is multivalued, and
the Simple Bind code will happily step through all the values of the
userPassword attribute until it gets a successful match.) You would need, in
addition to the {NTLM} scheme implementation, a plugin that updates all of
the schemes whenever any one is modified. (This plugin will only work
correctly when passwords are set using the ModifyPwd extended operation,
which is provided with the plaintext of the new password. A regular Modify of
the userPassword attribute will presumably be storing a pre-hashed value,
which obviously cannot be reversed to generate keys for the other schemes.)

The Cyrus SASL folks already went through the pain of generating and storing
multiple instances of a password's hash, for each of the supported
mechanisms. This  really becomes unmanageable in short order. The fact that
Cyrus 2.1 now relies on a single plaintext password in storage, and generates
the mech-specific hashes on the fly, is a testament to this fact.

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

OK.

> That's a side discussion - the real issue here is just the
> simple binds
> to the LDAP server, and sanity for our administrators.

While I would not strenuously oppose adding code that either fixes {LANMAN}
or introduces new schemes, I think "sanity" would best be served by avoiding
this whole mess in the first place. "Simple Bind" and "security" really don't
go together, and missing out on security won't help an admin's sanity...
Using ldaps or StartTLS are fine solutions to make Simple Bind less harmful,
but look at how many people can't even figure out how to get a usable server
certificate - the steps are straightforward and clearly documented, but
people still screw it up all the time. And of course, Simple Binds require
one to remember (or search for) their user DN, while SASL Binds accept the
username that users are already familiar with.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support