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

From: "Jim Sermersheim" <[email-masked]>
Date: Wed, 27 Apr 2005 08:31:29 -0600

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?
 
Jim

>>> Howard Chu <[email-masked]> 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://highlandsun.com/hyc 
Symas: Premier OpenSource Development and Support

_______________________________________________
Ldapext mailing list
[email-masked] 
https://www1.ietf.org/mailman/listinfo/ldapext 

_______________________________________________
Ldapext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ldapext

---

From: Rich Megginson <[email-masked]>
Date: Wed, 27 Apr 2005 08:43:55 -0600

[email-masked] 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?

No.  Our implementation does not have these attributes as 
NO-USER-MODIFICATION but it shouldn't be a problem to change them.

> http://www.symas.com <http://www.symas.com/> http://highlandsun.com/hyc
> [email-masked] <mailto:[email-masked]>
>------------------------------------------------------------------------
>

---

From: Andrew Sciberras <[email-masked]>
Date: Thu, 28 Apr 2005 08:15:39 +1000

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.

> _http://www.symas.com <http://www.symas.com/>_ _http://highlandsun.com/hyc_
> [email-masked] <mailto:[email-masked]>_
> _https://www1.ietf.org/mailman/listinfo/ldapext_
> 
>

---

From: Ludovic Poitou <[email-masked]>
Date: Fri, 29 Apr 2005 17:32:14 +0200

I also agree.

Ludovic.

-- 
Ludovic Poitou                                    Sun Microsystems Inc.
Software Architect                               Directory Server Group
http://blogs.sun.com/Ludo/                             Grenoble, France

Sun Microsystems requires the following notice:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE:  This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---

From: Andrew Sciberras <[email-masked]>
Date: Sat, 30 Apr 2005 01:41:46 +1000

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.

---

From: Howard Chu <[email-masked]>
Date: Fri, 29 Apr 2005 08:56:22 -0700

> to modify this value at their discretion to force a user to change their 

Understood. I'm in agreement there too.

> 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?
>>>
>>>
>>>
>>>