[Date Prev][Date Next] [Chronological] [Thread] [Top]
Re: [ldapext] (no subject)

To: "Jim Sermersheim" <jimse@novell.com>
Subject: Re: [ldapext] (no subject)
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Date: Tue, 14 Jun 2005 16:38:34 -0700
Cc: ldapext@ietf.org, bob.joslin@hp.com
In-reply-to: <s2aeef9b.059@sinclair.provo.novell.com>
References: <s2aeef9b.059@sinclair.provo.novell.com>
At 01:53 PM 6/14/2005, Jim Sermersheim wrote:
>The problem as Andrew Tridgell explained it is that the external service needs to work with password policy, but it itself must act as part of the process.

I think what is referred to as "an external service" here should
be viewed as a "user application" of the directory or, possibly,
it could be viewed as acting a limited shadow DSA (that doesn't
actually talk LDAP or DAP).

In the former view, I think it unwise to mix user application
policies with directory service policy.  This policy is for the
directory service.  If user applications need a policy mechanism,
that's a different beast.

In the latter view, any policy variables the external service
might want to update should be DSA-specific, that is, specific to
the external service.

>It must perform the password equality check itself.

Is also going to verify all the other information necessary
to validate the user is authorized to access the directory?

>This step happens right in the middle of other policy checks and updates. I've made one pass at 'modularizing' the password policy in order to make this kind of thing feasable. Not sure if I hit the mark or not.

I think we need to focus on policies controlling
the directory services and ignore, for now, policies
controlling user applications or "external services".
Apples and oranges.


>>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 6/10/05 8:24 PM >>>
>At 09:24 AM 5/12/2005, 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?
>
>I think the agent shouldn't attempt to do so as that's not,
>or shouldn't be, the semantics. Policy should be administrated
>through the appropriate subentry.
>
>I think it is a mistake to allow multiple mechanisms to
>administrate policy. If nothing else, it makes evaluation of
>access controls kind of ambiguous. Does the user need write
>to the operational attribute, or write to the attribute in the
>subentry?
>
>I think it would be wise to stick with the general X.500/LDAP
>administrative model, policy is administrated via values of
>attributes in subentries.
>
>Kurt
>
>
>
>>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 < <mailto:hyc@highlandsun.com>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://www.symas.com/ >
>>< http://www.symas.com/ >_
>>>> _http://highlandsun.com/hyc_
>>>> Symas: Premier OpenSource Development and Support
>>>>
>>>> _______________________________________________
>>>> Ldapext mailing list
>>>> <mailto:_Ldapext@ietf.org>_Ldapext@ietf.org < <mailto:Ldapext@ietf.org>mailto:Ldapext@ietf.org >_
>>>> _https://www1.ietf.org/mailman/listinfo/ldapext_
>>>>
>>>>
>>>>
>>------------------------------------------------------------------------
>>>>
>>>> _______________________________________________
>>>> Ldapext mailing list
>>>> <mailto:Ldapext@ietf.org>Ldapext@ietf.org 
>>>> https://www1.ietf.org/mailman/listinfo/ldapext 
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Ldapext mailing list
>>> <mailto:Ldapext@ietf.org>Ldapext@ietf.org 
>>> https://www1.ietf.org/mailman/listinfo/ldapext 
>>
>>
>>--
>>Ludovic Poitou Sun Microsystems Inc.
>>Software Architect Directory Server Group
>> <http://blogs.sun.com/Ludo/>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.
>>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>>
>>_______________________________________________
>>Ldapext mailing list
>> <mailto:Ldapext@ietf.org>Ldapext@ietf.org 
>> https://www1.ietf.org/mailman/listinfo/ldapext 
>>
>>
>>
>>_______________________________________________
>>Ldapext mailing list
>> <mailto:Ldapext@ietf.org>Ldapext@ietf.org 
>> https://www1.ietf.org/mailman/listinfo/ldapext 
>
>
>_______________________________________________
>Ldapext mailing list
><mailto:Ldapext@ietf.org>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
References:
- Re: [ldapext] (no subject)
  - From: "Jim Sermersheim" <jimse@novell.com>
Prev by Date: Re: [ldapext] (no subject)
Next by Date: [ldapext] draft-zeilenga-ldap-dontusecopy-00.txt
Index(es):
- Chronological
- Thread