[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: [ldapext] Interaction of <draft-behera-ldap-password-policy> with authentication applications
Andrew,
without getting too much into the details of your message, what you
describe sounds quite close to what I mean. The point is that the
draft-behera-ldap-password-policy is essentially intended for a simple
client <-> server
relationship, and there seems to be no intention to broaden it to
generic password policy (which I understand, because if it needs to
account for all the different needs it could become obfuscate and nearly
unusable).
When speaking about application authentication, I mean something like
client <-> { application <-> DSA }
where the application authenticates the client using services stored on
the DSA server, including the password and the password policy. The
policy could still apply if you see the whole from the client's
perspective, but now the server doesn't get a simple bind but rather an
auxprop lookup, as in general we cannot turn generic password-based
authentications into simple binds. So if we still want to apply the
password policy, using the facilities provided by the DSA, the
responsibility has to move to the application. Technically, this has to
result in a code duplication which, IMHO, could be eliminated by
providing some cooperation means between the application and the server.
With OpenLDAP, for example, we can circumvent this by moving password
policy enforcement into the app (in this case Cyrus SASL, but I guess it
would be essentially the same with Samba 3, as far as I know of it).
Then, the administrative operations related to storing policy info into
the DSA would be performed as regular modify, with a privileged
identity, and with the manageDIT control (undocumented, I know; it's a
work in progress) to circumvent the NO-USER-MODIFICATION constraint.
Currently, I'm working at the Cyrus SASL side to allow backpropgtion of
errors during auxprop lookup; next step will be full (well, as much as
possible) password policy awareness in OpenLDAP internal and ldapdb
external auxprop lookup functionalities.
p.
On Mon, 2006-01-02 at 17:23 +1100, Andrew Bartlett wrote:
> 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
>
Ing. Pierangelo Masarati
Responsabile Open Solution
OpenLDAP Core Team
SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
------------------------------------------
Office: +39.02.23998309
Mobile: +39.333.4963172
Email: pierangelo.masarati@sys-net.it
------------------------------------------
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext