[ldapext] Samba and the password policy draft

[Andrew Bartlett]

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.
>  
> 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.

Correct.

> 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

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? 
> 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. 

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).

> 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.

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

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/20040309/f676a4f6/attachment.bin