On Tue, 2005-12-27 at 13:58 +0100, Pierangelo Masarati wrote:
> Dear all,
>
> Howard Chu and I, of the OpenLDAP Project, and Alexey Melnikov of Cyrus
> SASL have been chatting about the issues of making password-based SASL
> mechs aware and respectful of any Password Policy mechanism implemented
> at the DSA that contains the passwords, and used by the SASL mechanisms
> by way of auxprop lookup. I'll briefly summarize the private discussion
> we had, and then expose my suggestions for a possible evolution of
> draft-behera-ldap-password-policy.
> This message should be considered a notification of the problem we're
> addressing; we're open to suggestions for different solutions. We think
> it would be important to include this further lookup-based mechanism
> into those accounted for by the LDAP password policy I.D., because it
> would broaden its application to authentication mechanisms that are
> closely related to those currently addressed.
I'm very interested in this space, due to the poor history that Samba
has achieved in solving exactly these problems in the past. As I
develop Samba4 and it's LDAP server, I would like to move to better and
more standards-based solutions.
In particular, I have an aim that Samba4 (an implementation of many of
the AD protocols for windows domain control, amongst other things) may
back onto an arbitrary LDAP server. This places Samba4 in the same
situation as Cyrus-SASL above. Similarly, Samba3 is already in that
situation, and performs poorly in this area.
Firstly, I fail to see the distinction between directory authentication
and application authentication, in a well-managed solution. This will
show in the remainder of my response.
As a history: Traditionally, Samba3 used LDAP simply as a data store,
with no reference to it for password policy, or even synchronisation.
Before the Samba3 release, I added support to set passwords into LDAP
using the openldap password set exop (but would only read it's own
password values). Samba3 eventually gained support for reading the
Novell eDirectory universal password, and this is where the hacks really
started:
The password is obtained with a custom exop, and to perform the second
stage (the notification of the authentication results), a *simple bind*
was returned to the server. The bind would be with the plaintext
password to indicate success (and the result checked to indicate if the
policy would allow the login), or with a random password to indicate
failure.
While I don't expect changes in this area for Samba3 (however anything
is possible), I would really like to see a better and standards-based
way to handle this over LDAP in Samba4. I would like Cyrus-SASL (and
RADIUS servers etc) to operate in a Samba4 environment, and correctly
honour our password policy, in a standard manner. A standard policy
here would also simplify the creation of alternate KDC implementations
(which would back onto Samba4 via LDAP).
I would also like Samba4 to use the directory policy, when it is simply
a front-end to the larger directory.
So, I'm glad to hear that this area is being thought about by others.
One particular comment I have is that for a password change, I need to
be able to trigger what is considered by the directory to be a 'user
change' operation, but with administrative credentials. This is because
we do not get the old plaintext in the kpassswd and NTLM password change
systems. I also need to be able to return the following values
(samr.idl in samba4):
/* password properties flags */
const uint32 DOMAIN_PASSWORD_COMPLEX = 0x00000001;
const uint32 DOMAIN_PASSWORD_NO_ANON_CHANGE = 0x00000002;
const uint32 DOMAIN_PASSWORD_NO_CLEAR_CHANGE = 0x00000004;
const uint32 DOMAIN_PASSWORD_STORE_CLEARTEXT = 0x00000010;
const uint32 DOMAIN_REFUSE_PASSWORD_CHANGE = 0x00000020;
typedef struct {
uint16 min_password_length;
uint16 password_history_length;
uint32 password_properties;
/* yes, these are signed. They are in negative 100ns */
dlong max_password_age;
dlong min_password_age;
} samr_DomInfo1;
Andrew Bartlett
--
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Student Network Administrator, Hawker College http://hawkerc.net
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext