On Fri, 2003-06-20 at 03:38, Howard Chu wrote: > > -----Original Message----- > > From: owner-openldap-devel@OpenLDAP.org > > [mailto:owner-openldap-devel@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@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