On Thu, 2003-06-19 at 20:45, Howard Chu wrote:
> > -----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.
Well, given how I got bitten by OpenLDAP 2.1, I can't blame them :-).
(I only got a stable install once I got OpenLDAP 2.0.27-2.8.0 from RH).
> re: a new SASL mech - that would work fine with OpenLDAP 2.1, there's no
> dependency on OpenLDAP 2.2.
But that would only work with a plaintext password?
> 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
> attribute.
>
> 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.)
Sure, but we don't have that luxury. If we ask people to do this, we
get back to people doing password sync. (Which I've already put a lot
of effort into allowing for exactly this reason).
> 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
> release.
Except that is modifying to client to satisfy the server - and I'm not
sure that solves our problem. If I wanted to modify the client, I would
run pam_winbind - that also works out of the box. But that's not the
solution I'm looking for, and for LDAP to use it, we have the mess I
described.
We need a solution that works for the simple bind. Then we can look at
'secure' alternatives.
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