Subject: Re: [ldapext] Samba and the password policy draft

From: "Jim Sermersheim" <[email-masked]>
Date: Mon, 08 Mar 2004 17:07:06 -0700

Andrew,
 
(speaking on behalf of the other LDAP password policy I-D authors) This
kind of integration is something we do want to consider.
 
Before we look at adding additional operations though, can we talk
about the reasons that prevent these applications from using existing
LDAP operations? Our guess is that it has to do with the fact that Samba
fetches either an NT or LM hashed password from the directory, and uses
that to perform the comparison. The NT/LM hash doesn't work with LDAP
simple bind because LDAP simple bind requires a clear text password.
 
I'm wondering if there's something preventing the use of an NT/LM SASL
mechanism to perform an LDAP SASL bind. Novell is beginning to look at
doing just that and will contribute to the code if it's seen as
beneficial. If this were available, the password policy could still be
enforced by the LDAP server
 
Then for password modifications, there is RFC 3602. Do you think this
is sufficient to update these kinds of passwords? 
Note that the new password is optional.
Also note that we *could* update the policy draft such that the
pwdSafeModify requires either the old password, or a trusted identity to
make the change. 
 
I know that for both of these to work, the server will need to support
the SASL mechanism, and allow itself to be configured to populate the
correct attributes when the password modify operation is used.
 
Let me know your thoughts on pushing in this direction.
 
Jim

>>> Andrew Bartlett <[email-masked]> 3/6/04 6:38:06 PM >>>
I have recently been made aware of the existence of 

draft-behera-ldap-password-policy-07.txt

and I would like to work with the ldapext group to make Samba suitable
for us with it, and the draft suitable for use with Samba (as well as
a
number of other tools in this class, being Cyrus-SASL and Heimdal's
hdb-ldap in particular).

These tools all have one thing in common, that is that they do not
generally ship cleartext passwords to LDAP when checking passwords. 
Instead, they use administrative rights to read the user's password
and
perform challenge-response on them. 

Similarly, these tools often do not have the original plaintext
password
for password changes, only the new plaintext. Again, this means that
these operations are performed as some administrative user.

However, I can see great value in ensuring that Samba complies with
the
password policies in force on the rest of the directory, and more
particularly, to allow Samba password policies (in some way derived
from
what MS does, as we match our NT4 semantics) to be set in the
directory,
using both NT and native LDAP tools.

What I am looking for is some additional control or operation that may
be used by Samba/Heimdal/etc to say 'a user just logged in, with the
right password', and 'a user just tried to log in with a wrong
password'. 

Likewise, some additional control to say 'this password change on
behalf
of a user', would fix my second concern. 

I realise that these could be considered to be 'not LDAP's problem'
(as
it regards password comparisons outside the directory), but in the
interests of seamless directory integration, I hope that some
accommodation can be made, particularly in the interests of
cross-protocol, cross-application consistency.

(Indeed Samba and some other tools may read the user's plaintext
password out of the userPassword attribute. It would be a pity to
defeat the max bad password checks while attempting to make an
administrator's live *easier*...)

Finally, I apologise if I have messed up some of the finer details of
LDAP here. While I have spent a lot of time (along with many others)
working of pdb_ldap in Samba, I am far from an LDAP guru...

Is this something the working group is willing to consider?

Andrew Bartlett
-- 
Andrew Bartlett [email-masked] 
Manager, Authentication Subsystems, Samba Team [email-masked] 
Student Network Administrator, Hawker College [email-masked] 
http://samba.org http://build.samba.org http://hawkerc.net

---

From: Andrew Bartlett <[email-masked]>
Date: Tue, 09 Mar 2004 11:43:38 +1100

On Tue, 2004-03-09 at 11:07, Jim Sermersheim wrote:
> Andrew,
>  
> (speaking on behalf of the other LDAP password policy I-D authors)
> This kind of integration is something we do want to consider.
>  
> LDAP operations? Our guess is that it has to do with the fact that
> Samba fetches either an NT or LM hashed password from the directory,
> and uses that to perform the comparison. The NT/LM hash doesn't work
> with LDAP simple bind because LDAP simple bind requires a clear text
> password.

Correct.

> enforced by the LDAP server

NO.  This is not suitable for a SASL mechanism, as this is a
challenge-response that is done by Samba, or a Samba client (being an NT
domain member server, for example).  We simply get the result of the
challenge-response, we can't specify the inputs.  

Even if you hacked a solution to that, consider Heimdal and Cyrus-SASL
(backed against an LDAP password store)...  

> Then for password modifications, there is RFC 3602. 

RFC 3602 - The AES-CBC Cipher Algorithm and Its Use with IPsec??

Ahh, you mean 3062 :-).  Samba already supports this, and indeed it is
my proposal that we use this to perform the password set, when we have
the plaintext password.  We currently still set the NT and LM passwords
manually, but it is my hope that in the future, the LDAP server will
know how to populate the required attributes itself.  A patch
implementing this for OpenLDAP is in the works.

Indeed it was my proposal to use exactly this (using our existing
pdb_ldap and 'ldap password sync = only' in the smb.conf) when Novell
expressed an interest in providing an eDirectory passdb backend for
Samba.

> Do you think this is sufficient to update these kinds of passwords? 
> pwdSafeModify requires either the old password, or a trusted identity
> to make the change. 

This would be good.  The only thing I need in addition is for the server
to support still considering this to be a 'user modify', so as to check
the 'quality' against user, not administrator rules (I presume the admin
is exempt from the rules).

> Let me know your thoughts on pushing in this direction.

The SASL stuff is a non-starter, but the password modify stuff is
exactly what I am thinking.

Andrew Bartlett

---

From: "Jim Sermersheim" <[email-masked]>
Date: Fri, 12 Mar 2004 01:06:31 -0700

>right password', and 'a user just tried to log in with a wrong

I'm toying with the notion of changing the draft such that it describes password policy decision points, and then refers to those decision points when talking about how to implement operations like bind and compare. Once this is done, it should be easy to create new operations (like those you mentioned) and specify which password policy decision points are invoked during those new operations.
 
The first thing I noticed when looking at doing this is that the current wording for bind (and compare) require server implementations to check for a locked account prior to performing the password comparison. I think we did this either as an optimization, or because we deemed it important to always check for the locked account condition. I think it'll be ok to just make a statement that this condition must be checked whether the password comparison succeeds or fails.
 
The only reason I bring this up is because the suggested operations above don't/can't follow the current pattern (unless there's also a 'this user is going to log in' precheck operation * yuk).
 
Jim