On Thu, 2003-06-19 at 19:25, Howard Chu wrote:
> > -----Original Message-----
> > From: Andrew Bartlett [mailto:abartlet@samba.org]
> > 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
> > breath...
>
> Let's assume that you have {NT} and {LANMAN} hashes stored in the entry. You
> could explicitly store new hashes with LDAPModify, or you could write a
> ModifyPwd plugin that takes a plaintext password and generates hashes for all
> of the userPassword values. This would keep your Unix {CRYPT} users happy
> too, I think.
>
> > 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...
>
> Right.
>
> 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...
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