Re: [ldapext] draft-behera-ldap-password-policy - operational attrs

[Andrew Sciberras <andrew.sciberras@eB2Bcom.com>]

I suppose I should note that I have intentionally omitted pwdReset from 
the attributes that require NO-USER-MODIFICATION.
This is due to the fact that I believe an administrator should be able 
to modify this value at their discretion to force a user to change their 
password.

Andrew Sciberras.

Ludovic Poitou wrote:
> I also agree.
>
> Ludovic.
>
> Andrew Sciberras wrote:
>
> > Hi
> >
> > Jim Sermersheim wrote:
> >
> > > While I worry a bit about your implementation (though it's not really 
> > > my place to), I agree with your final assessment, we should change 
> > > these to NO-USER-MODIFICATION.
> > >  
> > > Anyone disagree?
> >
> >
> >
> > This sounds alright to me.
> > Since we're actually making some the the state attributes 
> > NO-USER-MODIFICATION, perhaps we should look at the others as well.
> > I'm thinking that pwdAccountLockedTime, pwdFailureTime and 
> > pwdPolicySubentry should also be included in this list.
> >
> > > Jim
> >
> >
> >
> > Andrew.
> >
> > >  >>> Howard Chu <hyc@highlandsun.com> 4/26/05 8:41 AM >>>
> > > I kept meaning to raise this question, but it seems to have fallen thru
> > > the cracks. For the OpenLDAP implementation, I needed to change these
> > > operational attributes to NO-USER-MODIFICATION:
> > > pwdChangedTime, pwdGraceUseTime, and pwdHistory
> > >
> > > We have a problem because of the way we process a password change - if a
> > > user is changing their own password, that Modify request is performed
> > > using the user's identity. To do bookkeeping on the above operational
> > > attributes, we internally append some modify operations to the user's
> > > Modify request, and then the augmented request is passed down to the
> > > usual Modify processing. One other factor in our implementation is that
> > > user-modifiable attributes are subject to ACL checks, non-modifiable
> > > attributes are not. So, userPassword is user-modifiable, and typically
> > > users are given permission to write their own password. But they
> > > shouldn't have permission to write the above three attributes, because
> > > then they can just bypass a lot of the policies that rely on those
> > > attributes.
> > >
> > > So with the default definitions, we have a problem because the user may
> > > have permission to update the userPassword attr, but no permissions to
> > > the other attrs.
> > >
> > > Alternatively we can break things up into two separate Modify
> > > operations, doing the user's original request and then using system
> > > privileges to handle the bookkeeping, but I'm not keen on that approach.
> > > It introduces some lag in a replication scenario, where the password
> > > change itself will get replicated separately from the bookkeeping 
> > > update.
> > >
> > > Fundamentally I believe NO-USER-MODIFICATION is appropriate for these
> > > attributes. Issues with our implementation can be worked around, but I'd
> > > rather clear this up regardless.
> > >
> > > --
> > > -- Howard Chu
> > > Chief Architect, Symas Corp. Director, Highland Sun
> > > _http://www.symas.com <http://www.symas.com/>_ 
> > > _http://highlandsun.com/hyc_
> > > Symas: Premier OpenSource Development and Support
> > >
> > > _______________________________________________
> > > Ldapext mailing list
> > > _Ldapext@ietf.org <mailto:Ldapext@ietf.org>_
> > > _https://www1.ietf.org/mailman/listinfo/ldapext_
> > >
> > >
> > > ------------------------------------------------------------------------
> > >
> > > _______________________________________________
> > > 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

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