[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: [ldapext] (no subject)

Neal-Joslin, Robert (HP-UX Lab R&D) wrote: 
While I understand the reasoning for the suggestions, I thought I should
bring out one point for discussion:

Is not one purpose of standardizing password/account policy to allow
other agents (aside from the DUA itself) to interact with this policy?
If so, then changing some of these attributes to NO-USER-MODIFICATION
limits the ability of these agents to interact with the policy.  What if
the agent wants to use this schema to manage the policy itself?

That's a good question. I hadn't considered the possibility of external agents interacting with and (in effect) implementing the policy from outside the DSA. With the passage of time, the specifics really aren't crucial to me any more; the OpenLDAP implementation has been fixed so the issue that originally prompted me is now gone. I'm also reminded now of Andrew Bartlett's inquiry into using the LDAP password policy inside Samba, so I guess this is something to think about more. 

Bob

================================================================= 

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://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support

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