Getting OpenLDAP to auth users against sambaNTPassword

[Andrew Bartlett]

On Fri, 2003-06-20 at 03:38, Howard Chu wrote:
> > -----Original Message-----
> > From: owner-openldap-devel at OpenLDAP.org
> > [mailto:owner-openldap-devel at OpenLDAP.org]On Behalf Of Andrew Bartlett
> 
> > 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.
> 
> You're not seeing the whole picture I just outlined.
> 
> 1) You can add your own passwd mech for Simple Bind that works with whatever
> values you want. These can be NT or LM hashes. To do this, you need to use
> the userPassword attribute with a scheme identifier.

Except you made a very good argument why we should not be using
userPassword for this - I don't want to push samba into this game when
everybody else is leaving it...

> 2) You can add a SASL mech that works with whatever values you want. Again,
> these can be NT or LM hashes, it doesn't need to be cleartext. If you do (1)
> you can write your SASL mech to use the same attribute values.

And we can tell OpenLDAP 2.1 to use this SASL mech for our simple binds?

> But for your last comment - if you leave security as an afterthought, you
> create the same kind of mess as Microsoft. Leaving aside the fact that you
> don't have plaintext passwords to start from, any site that would veto an
> implementation because it stores plaintext passwords *should* logically also
> veto an implementation that transmits plaintext passwords over a network.

You don't know our sites :-).  They will veto anything and everything,
and we don't have the option anyway...  

We have almost-plaintext passwords flying around everywhere anyway, and
the takeup rate of NTLMv2 shows that people don't care about it *that*
much.

> Don't think of it as modifying the client to satisfy the server - it's
> modifying the client to satisfy *administration needs*, which is exactly what
> you said originally - to get sanity for the admins.

Still not getting it - we can't modify the clients to satisfy this
requirement.  We *need* to be able to run the de-facto clients,
including things like mod_auth_ldap/pam_ldap, or else people will just
move back to 'password sync' operations.

I want to avoid people needing to setup 'password sync' operations
because they get out of sync, and it's extra data we don't need to
manage.  (I have no problem with 'password sync' when we do need to
manage the extra data - like for other hash types - but when it's just
to get around stuff like this, it just gets silly...)

If *we* determine that we know what's best for sites, then we just make
an admin's life hell.  Of course, admins should be clearly told what
security risks they are taking in all directions, but constructing
solutions with seemingly the sole purpose of making life harder from
them doesn't help, in my mind...

Instead, we should accept the reality the administrators need to work
with, make it easier to deploy their sites, and make it easier to tack
things like kerberos on for those that need it, and easier to use things
like NTLMSSP or some other NT-hash derived security mechanism.

(I have worked on a patch to Heimdal kerberos that makes it read the
sambaNTpassword for the type 23 encryption key for exactly this reason).

Andrew Bartlett

-- 
Andrew Bartlett                                 abartlet at pcug.org.au
Manager, Authentication Subsystems, Samba Team  abartlet at samba.org
Student Network Administrator, Hawker College   abartlet at hawkerc.net
http://samba.org     http://build.samba.org     http://hawkerc.net
-------------- 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 : http://lists.samba.org/archive/samba-technical/attachments/20030619/5a733943/attachment.bin