[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: Getting OpenLDAP to auth users against sambaNTPassword

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

> > I should note that OpenLDAP 2.2 also provides an entry
> point for registering
> > new password mechanisms. So you can code up whatever
> "{SCHEME}data" mech you
> > want and dynamically load it into slapd. You can also
> dynamically load a
> > plugin to take care of the synchronization aspects, as Luke already
> > mentioned. OpenLDAP 2.2 will also have a native (non-SLAPI)
> plugin mechanism
> > that can do this job.
> >
> > I think it would be worthwhile to implement a proper NTLM
> challenge-response
> > mechanism for SASL though, which operates from the hashes
> that are available
> > to you, and provides a sasl_setpassword entry point.
> There's nothing that
> > requires a SASL mechanism to use the userPassword
> attribute; the mech can
> > operate on any attribute it wants.
> This certainly sounds like a good long-term solution.
> However, what can
> we do short-term?  Being able to use pam_ldap/mod_auth_ldap et al - no
> matter how bad in theory - is a very valuable thing in current Linux
> deployments.
> Being able to use existing LDAP tools on the directory, being able to
> 'tack on' Linux workstations into your newly migrated Samba
> installations is the kind of thing I want people to be able
> to do.  (And
> not need to run pam_winbind on each client...)
> With the release of Samba 3.0, we will be getting a lot more people
> trying to get Samba/OpenLDAP working as a corporate directory
> solution.
> I'm hoping that will bring a lot more people to Linux/Samba/OpenLDAP
> directory services installations.
> What I'm wondering is what we can do to make their life sane?
> If the SASL mechanism doesn't need to use userPassword, could a
> {NT}sambaNTpassword password scheme also do the same job?  Or is this
> only in OpenLDAP 2.2?
> Yes, I'm probably asking for short-term, Samba-specific hacks, in
> whatever version of OpenLDAP will reach users the soonest.  I also
> realize that this is a problem.  That said, our users and admins will
> greatly appreciate any effort we can make here...

"whatever version of OpenLDAP will reach users the soonest" - that's an
interesting question, considering that 2.1 has been out for so long, but we
still see people doing fresh installs of (old!) 2.0 releases. If you want to
do *whatever you can* I think beating on the 2.2(alpha,beta), exposing as
many of its bugs as possible, so that 2.2.0 can be released, would be the
best thing.

re: a new SASL mech - that would work fine with OpenLDAP 2.1, there's no
dependency on OpenLDAP 2.2.

re: {NT}sambaNTpassword - not feasible in 2.1, for reasons I outlined in a
previous message. It would probably be OK to backport the lutil_passwd_add()
support from CVS into 2.1, so you could add {NT} to the userPassword

re: pam_ldap/mod_auth_ldap - I would replace these with code that
authenticates using LDAP SASL Bind. The size of the source code would be
drastically reduced, since you wouldn't have to repeatedly configure search
bases and other such nonsense any more, which would greatly improve their
reliability and maintainability. (nss_ldap is still a mess, unfortunately.)

Let's see...
	Install Cyrus SASL + NT mech
	Configure PAM to use pam_ldap, pam_ldap implicitly using SASL.
	Configure Samba to use LDAP

Not so bad. A new SASL mech would be trivial, as would a SASL-based pam_ldap
and mod_auth_ldap. All of these would work with the current OpenLDAP 2.1

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