Subject: RE: [ldapext] password policy: pwdAllowUserChange

From: "Jim Sermersheim" <[email-masked]>
Date: Thu, 13 May 2004 23:36:04 -0600

Yeah, I guess I could see a point in leaving it for the reason you point
out, but for the same reason, I could see adding another attribute which
grants rights to some 'pwdAdministrator" to change other people's
passwords (and maybe even various password policy attributes). In fact,
to align more closely with some existing implementations, the
pwdSafeModify would allow this pwdAdministrator to make modifications
without providing the old password. Section 2.1 currently lets us sleaze
out of this rathole.

I hope I'm not getting myself into more trouble.

Jim

>>> [email-masked] 5/13/04 10:56:04 PM >>>
Hi Jim,

I tend to agree with your here. I think that this an Access Control
issue
and therefore should not be part of the policy.

I do not have any issues with its removal. Our directory can
adequately
control access to attributes and their values using our local access
control
and X.500 Basic Access Control implementations.

Removing the pwdAllowUserChange attribute may become a problem for
Directory
implementations whose access control scheme cannot provide this
functionality. If this attribute stay's within the draft then I think
that
text should be added to clearly indicate that the pwdAllowUserChange
attribute is intended to be used in absence of any access controls.

Cheers,
..........................
Andrew Sciberras
http://view500.adacel.com 

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]On 
>Behalf Of
>Jim Sermersheim
>Sent: Friday, 14 May 2004 13:43
>To: [email-masked] 
>Subject: [ldapext] password policy: pwdAllowUserChange
>
>
><in reference to draft-behera-ldap-password-policy-xx>
>
>I'm not sure why we need this attribute. It's there to grant a user
the
>rights to change his own attribute. Are there implementations that
need
>this? It seems that local access control mechanisms should suffice.
>
>I'd like to remove it unless there's a compelling reason to leave it.
>
>Jim
>
>_______________________________________________
>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: Chris Ridd <[email-masked]>
Date: Fri, 14 May 2004 07:26:28 +0100

> I hope I'm not getting myself into more trouble.

We asked Ludovic about this attribute a while ago. Essentially it is
intended to be used by the server *after* access control evaluation has
occurred - this enables an administrator to fine tune the user's access to
the attribute without having to mess around with setting entryACI or the
local equivalent.

Apparently the Netscape/Sun implementation automatically sets its local ACLs
when the pwdAllowUserChange attribute is changed, so on that server they're
always the same.

Being able to tweak stuff without messing with access controls seems like a
fine goal which permits password management clients with having to have
knowledge of the local access control implementation.

It does need clarifying in the draft though.

Cheers,

Chris

---

From: Chris Ridd <[email-masked]>
Date: Fri, 14 May 2004 08:21:19 +0100

> knowledge of the local access control implementation.

That makes more sense with "prevents" instead of "permits" :-)

Cheers,

Chris