On Mon, 2006-01-02 at 09:03 +0100, Pierangelo Masarati wrote:
> 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.
The other reason we should consider this area as closely tied to the
client <-> server exchange is the number of applications that still do
'ldap authentication' by 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.
I'm unclear why we are doing modifies here. While a complete hack, the
Novell eDirectory with Samba3 approach is I believe instructive. I just
want a standards-based way to do it.
For logins:
The password should be fetched, and a password compare done.
A message should be sent to the server indicating:
- success/failure
- source IP
- other details (such as the NTLM 'workstation name')
The server should handle all the modifies, I think.
For password changes:
The existing password change exop, but with clear info on failures.
This should set all hash types etc.
I don't actually see where the manageDIT modify would come into it. The
other point to consider is that any change should easily hook into the
code for the server-only policy
> 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.
If the hooks do look like what I suggest above, then we might even get
Samba3 along for this, because the internal APIs already exist for the
eDirectory case.
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