Re: [ldapext] Interaction of <draft-behera-ldap-password-policy> with authentication applications

[John McMeeking <jmcmeek@us.ibm.com>]

Setting aside the question of what draft
might address this, it looks like there are two things (at least) to address:

1.  Proxied binds, where the server
provides a password but doesn't receive a bind request (or even compare).
 An application performs authentication after using search to retreive
the password.
2.  Proxied password changes, where
the server stores the password but an application changes the password
on behalf of a user.

I assume the password is shared with
other applications or LDAP clients, otherwise there's really no need to
have LDAP password policy at all; you just need a schema.

For the proxied bind case, I think an
extended request would be appropriate.  There was some mention of
changes to search.  Unless I missed the point, it seems like that
would require two searches - one to retrieve the password and account status,
a second to somehow indicate bind success or failure.  That seems
like inappropiate use of a search control.  The extended request value
could contain an entry DN and an indication of whether the bind was successful
or not.  The server would update the password policy state accordingly.
 I agree that items like clients IP address would be outside the scope
of this discussion.

For the proxied password change, I think
you'd want a control attached to the modify request (or the password change
extended request).  As I read it, the existing password policy acknowledges
a two kinds of password changes:
1.  changing your own password
2.  changing someone else's password

As you suggested, one could define a
control to cover the first case. I don't think the control needs any value,
just the presence of the control to tell the server to act like this is
a password change from the client.  At that, the LDAP Proxied Authorization
Control (draft-weltman-ldapv3-proxy-xx) might also work, though it carries
a lot more function with it unless the server implementation is restricted
to just this use.

For the second case, I don't think we
need to define anything extra.  It seems to me this falls cleanly
into the category of changing someone else's password and should be covered
by the password policy draft.  Your note suggests there might be some
holes in password policy draft - different flavors of administrative password
changes - and I don't know if the existing draft meets your needs there.


John  McMeeking


ldapext-bounces@ietf.org wrote on 01/06/2006 03:09:56
PM:

> On Wed, 2006-01-04 at 19:50 -0800, Howard Chu wrote:
> 
> > Where the two situations overlap, it makes sense to me to unify
them. I 
> > think there is sufficient overlap in the Cyrus SASL case. Where
the two 
> > situations differ, it makes sense to isolate the differences.
The 
> > password policy specification only talks about password management.
A 
> > user's IP address may figure into authentication policy or more
> > generally into access control, but that's outside the scope of
a 
> > password discussion.
> 
> I've been looking at the spec again, from the password management
angle.
> I understand the intent to limit the scope here.
> 
> What I'm worried about is again an application proxy issue, but more
> limited:  Strictly within the password management space, I want
to
> communicate to the back end the difference between:
> 
>  - user changes their password 
>  - administrator changes a user's password (but must follow some
> restrictions)
>  - big hammer (I am going to set 'cat' and you shouldn't stop
me...)
> 
> I need that in Samba4 (and indeed the first 2 in Samba3), if we are
to
> have the directory enforce the password policies.  However, in
all cases
> the bind occurs as an administrative user, as we never get the user's
> cleartext in these protocols.
> 
> I presume the big hammer matches up with ManageDIT?  Could we
add a
> control to advise the backend of the other details?
>  
> 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" deleted by John McMeeking/Rochester/IBM]
> _______________________________________________
> Ldapext mailing list
> Ldapext@ietf.org
> https://www1.ietf.org/mailman/listinfo/ldapext

_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext