[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: [ldapext] draft-behera-ldap-password-policy - operational attrs
- To: ldapext@ietf.org
- Subject: Re: [ldapext] draft-behera-ldap-password-policy - operational attrs
- From: Howard Chu <hyc@highlandsun.com>
- Date: Tue, 26 Apr 2005 07:41:49 -0700
- In-reply-to: <s21e2f9e.035@sinclair.provo.novell.com>
- References: <s21e2f9e.035@sinclair.provo.novell.com>
- User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050419
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
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext