From ldapext-bounces@ietf.org Fri Jun 10 19:30:11 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24594 for ; Fri, 10 Jun 2005 19:30:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgtIq-0002fc-Gh for ldapext-archive@ietf.org; Fri, 10 Jun 2005 19:52:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dgsva-0007eu-H5; Fri, 10 Jun 2005 19:28:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgsvY-0007em-Bf for ldapext@megatron.ietf.org; Fri, 10 Jun 2005 19:28:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24493 for ; Fri, 10 Jun 2005 19:28:36 -0400 (EDT) Received: from highlandsun.propagation.net ([66.221.212.168]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgtHI-0002Zp-6a for ldapext@ietf.org; Fri, 10 Jun 2005 19:51:09 -0400 Received: from [127.0.0.1] (highlandsun.com [66.221.212.169]) by highlandsun.propagation.net (8.13.3/8.13.3) with ESMTP id j5ANSDRa031858; Fri, 10 Jun 2005 18:28:13 -0500 Message-ID: <42AA2210.6040201@highlandsun.com> Date: Fri, 10 Jun 2005 16:28:16 -0700 From: Howard Chu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050606 MIME-Version: 1.0 To: "Neal-Joslin, Robert (HP-UX Lab R&D)" Subject: Re: [ldapext] (no subject) References: <632116003944094FB495E72A6EDB90B201269406@cacexc10.americas.cpqcorp.net> In-Reply-To: <632116003944094FB495E72A6EDB90B201269406@cacexc10.americas.cpqcorp.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: 7bit Cc: Duane Buss , ldapext@ietf.org, Tammy Green , Ludovic Poitou , andrew.sciberras@eB2Bcom.com, Zhanna Tsitkova , Jim Sermersheim X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Content-Transfer-Encoding: 7bit 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 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 From ldapext-bounces@ietf.org Fri Jun 10 22:30:24 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05147 for ; Fri, 10 Jun 2005 22:30:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dgw7F-0005sV-Ml for ldapext-archive@ietf.org; Fri, 10 Jun 2005 22:52:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dgvi6-0002qA-Nd; Fri, 10 Jun 2005 22:26:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dgvi5-0002q5-IJ for ldapext@megatron.ietf.org; Fri, 10 Jun 2005 22:26:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05044 for ; Fri, 10 Jun 2005 22:26:54 -0400 (EDT) Received: from boole.openldap.org ([204.152.186.50] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dgw3q-0005np-4O for ldapext@ietf.org; Fri, 10 Jun 2005 22:49:28 -0400 Received: from gyspy.OpenLDAP.org (24-205-218-53.cs-cres.charterpipeline.net [24.205.218.53]) (authenticated bits=0) by boole.openldap.org (8.13.1/8.13.1) with ESMTP id j5B2PMuA056282 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Jun 2005 02:25:27 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.2.1.2.0.20050610191948.0838ed20@mail.openldap.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 10 Jun 2005 19:24:53 -0700 To: "Neal-Joslin, Robert (HP-UX Lab R&D)" From: "Kurt D. Zeilenga" Subject: Re: [ldapext] (no subject) In-Reply-To: <632116003944094FB495E72A6EDB90B201269406@cacexc10.americas .cpqcorp.net> References: <632116003944094FB495E72A6EDB90B201269406@cacexc10.americas.cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.1 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 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 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_ >>> >>> >>> >------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> 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 > > >-- >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. >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > >_______________________________________________ >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 _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Tue Jun 14 16:54:52 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05687 for ; Tue, 14 Jun 2005 16:54:51 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiInU-0001Kw-AS for ldapext-archive@ietf.org; Tue, 14 Jun 2005 17:18:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiIQe-0002MY-V3; Tue, 14 Jun 2005 16:54:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiIQc-0002LX-AZ for ldapext@megatron.ietf.org; Tue, 14 Jun 2005 16:54:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05667 for ; Tue, 14 Jun 2005 16:54:31 -0400 (EDT) Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiInA-0001KI-3D for ldapext@ietf.org; Tue, 14 Jun 2005 17:17:52 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Tue, 14 Jun 2005 14:54:19 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.4 Date: Tue, 14 Jun 2005 14:53:52 -0600 From: "Jim Sermersheim" To: , Subject: Re: [ldapext] (no subject) Mime-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9f79b8e383fd3af2b1b5b1d0910f6094 Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2114521603==" Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bc102ac530ba955ef81f1f75b8bebe44 This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --===============2114521603== Content-Type: multipart/alternative; boundary="=__Part3615D6F0.1__=" This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part3615D6F0.1__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable 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. It must perform the password equality check itself. 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. >>> "Kurt D. Zeilenga" 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 > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 > >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. >>>=20 >>> 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://www.symas.com/ > >< http://www.symas.com/ >_ >>> _http://highlandsun.com/hyc_ >>> Symas: Premier OpenSource Development and Support >>> >>> _______________________________________________ >>> Ldapext mailing list >>> _Ldapext@ietf.org < mailto:Ldapext@ietf.org >_ >>> _https://www1.ietf.org/mailman/listinfo/ldapext_ >>> >>> >>> >------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Ldapext mailing list >>> Ldapext@ietf.org=20 >>> https://www1.ietf.org/mailman/listinfo/ldapext=20 >> >> >> >> >> _______________________________________________ >> Ldapext mailing list >> Ldapext@ietf.org=20 >> https://www1.ietf.org/mailman/listinfo/ldapext=20 > > >-- >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. >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > >_______________________________________________ >Ldapext mailing list > Ldapext@ietf.org=20 > https://www1.ietf.org/mailman/listinfo/ldapext=20 > > > >_______________________________________________ >Ldapext mailing list > Ldapext@ietf.org=20 > https://www1.ietf.org/mailman/listinfo/ldapext=20 _______________________________________________ Ldapext mailing list Ldapext@ietf.org=20 https://www1.ietf.org/mailman/listinfo/ldapext=20 --=__Part3615D6F0.1__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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. It = must perform the password equality check itself. 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.

>>> "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:
>W= hile 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
>limit= s the ability of these agents to interact with the policy. What if
>t= he 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 appropriat= e subentry.

I think it is a mistake to allow multiple mechanisms = to
administrate policy. If nothing else, it makes evaluation of
acces= s controls kind of ambiguous. Does the user need write
to the operationa= l 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
>
>=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D
>
>I also agree.
>
>Ludovic.=
>
>Andrew Sciberras wrote:
>
>> Hi
>><= BR>>> Jim Sermersheim wrote:
>>
>>> While I = worry a bit about your implementation (though it's not really
>>&g= t; my place to), I agree with your final assessment, we should change
&g= t;>> 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
>>
>>
&g= t;> Andrew.
>>
>>>
>>> >>> = Howard Chu < hyc@highlandsun.c= om > 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
>&g= t;>
>>> 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
&= gt;>> 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
>>&= gt; 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.
>&g= t;> 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
&g= t;>> attributes. Issues with our implementation can be worked = around, but
>I'd
>>> rather clear this up regardless.
= >>>
>>> --
>>> -- Howard Chu
>>&g= t; Chief Architect, Symas Corp. Director, Highland Sun
>>> = _http://www.symas.com < http://www.= symas.com/ >
>< ht= tp://www.symas.com/ >_
>>> _http://highlandsun.com/h= yc_
>>> Symas: Premier OpenSource Development and Support
&g= t;>>
>>> _______________________________________________<= BR>>>> Ldapext mailing list
>>> _Ldapext@ietf.org < mailto: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
>
>
>--
>= ;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.
>~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
>____= ___________________________________________
>Ldapext mailing = list
> Ldapext@ietf.org
> ht= tps://www1.ietf.org/mailman/listinfo/ldapext
>
>
&g= t;
>_______________________________________________
>Ldapext = mailing list
> Ldapext@ietf.or= g
> https://www1.ietf.org/mailman/listinfo/ldapext


__= _____________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.o= rg/mailman/listinfo/ldapext
--=__Part3615D6F0.1__=-- --===============2114521603== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext --===============2114521603==-- From ldapext-bounces@ietf.org Tue Jun 14 19:41:47 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18950 for ; Tue, 14 Jun 2005 19:41:47 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiLP4-0003hW-KV for ldapext-archive@ietf.org; Tue, 14 Jun 2005 20:05:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiL0F-0007nA-IV; Tue, 14 Jun 2005 19:39:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiL0D-0007n2-1W for ldapext@megatron.ietf.org; Tue, 14 Jun 2005 19:39:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18869 for ; Tue, 14 Jun 2005 19:39:25 -0400 (EDT) Received: from boole.openldap.org ([204.152.186.50] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiLMm-0003X0-Q0 for ldapext@ietf.org; Tue, 14 Jun 2005 20:02:49 -0400 Received: from gyspy.OpenLDAP.org (24-205-218-53.cs-cres.charterpipeline.net [24.205.218.53]) (authenticated bits=0) by boole.openldap.org (8.13.1/8.13.1) with ESMTP id j5ENdETC072918 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Jun 2005 23:39:15 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.2.1.2.0.20050614162049.08cac8e8@mail.openldap.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 14 Jun 2005 16:38:34 -0700 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: [ldapext] (no subject) In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.1 (/) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 Cc: ldapext@ietf.org, bob.joslin@hp.com X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: a0534e6179a1e260079328e8b03c7901 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" 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 < 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://highlandsun.com/hyc_ >>>> Symas: Premier OpenSource Development and Support >>>> >>>> _______________________________________________ >>>> Ldapext mailing list >>>> _Ldapext@ietf.org < mailto: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 >> >> >>-- >>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. >>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> >> >>_______________________________________________ >>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 > > >_______________________________________________ >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 _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Thu Jun 23 15:26:39 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19211 for ; Thu, 23 Jun 2005 15:26:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlXjs-0005H5-Q8 for ldapext-archive@ietf.org; Thu, 23 Jun 2005 15:51:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlXLH-0008Mg-Lt; Thu, 23 Jun 2005 15:26:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlXLG-0008Mb-2K for ldapext@megatron.ietf.org; Thu, 23 Jun 2005 15:26:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19202 for ; Thu, 23 Jun 2005 15:26:24 -0400 (EDT) Received: from sinclair.provo.novell.com ([137.65.81.169]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlXje-0005Ge-0u for ldapext@ietf.org; Thu, 23 Jun 2005 15:51:38 -0400 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Thu, 23 Jun 2005 13:26:08 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.4 Date: Thu, 23 Jun 2005 13:25:47 -0600 From: "Jim Sermersheim" To: Mime-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Subject: [ldapext] draft-zeilenga-ldap-dontusecopy-00.txt X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1862456860==" Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --===============1862456860== Content-Type: multipart/alternative; boundary="=__Part3615C2AB.0__=" This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part3615C2AB.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable I'm struggling to understand what is meant by the terms "copy" and = "authoritative". I don't see one as the antithesis of the other. =20 How is a "copy" distinguished from an "original"?=20 How does the term "copy" relate to the term "shadow"? How do these terms relate to the term "read-only"? =20 To me, the term "authoritative" is completely orthogonal to most of this. = While an authoritative entry is probably never read-only, the determination= of the placement of an authoritative entry may be completely arbitrary or = application specific. For example, an address book application may = consider a group of entries held on DSA1 to be authoritative, while a = provisioning application may consider many of those same entries to be = authoritative only when accessed on another DSA. Other applications may = wish to share the notion of where an entry is said to be authoritative. =20 In my experience, the need for a control which specifies an operation take = place on the authoritative copy typically has to do with update operations.= One DSA is said to be authoritative for an entry, and thus update = operations may be asked to be directed at that authoritative copy. This is = obviously especially true in multi-master systems. =20 If this is what the I-D seeks to provide, I suggest it rename the control = to "useAuthoritative", and allow it to be applied to all operations = (rather than interrogation only). The problem is in defining how to = determine whether a given entry is authoritative. =20 If, on the other hand, it seeks to force an interrogation operation to be = directed to a non-read-only, or non-shadow copy of an entry, it should not = introduce the term "authoritative". Rather it should follow X.500 and = replace that word with "non-shadow" =20 =20 Jim --=__Part3615C2AB.0__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I'm struggling to understand what is meant by the terms "copy" and = "authoritative". I don't see one as the antithesis of the other.
 
How is a "copy" distinguished from an "original"?
How does the term "copy" relate to the term "shadow"?
How do these terms relate to the term "read-only"?
 
To me, the term "authoritative" is completely orthogonal to most of = this. While an authoritative entry is probably never read-only, the = determination of the placement of an authoritative entry may be completely = arbitrary or application specific. For example, an address book a= pplication may consider a group of entries held on DSA1 to be authoritative= , while a provisioning application may consider many of those same entries = to be authoritative only when accessed on another DSA. Other applications = may wish to share the notion of where an entry is said to be authoritative.=
 
In my experience, the need for a control which specifies an operation = take place on the authoritative copy typically has to do with update = operations. One DSA is said to be authoritative for an entry,  and = thus update operations may be asked to be directed at that authoritative = copy. This is obviously especially true in multi-master systems.
 
If this is what the I-D seeks to provide, I suggest it rename the = control to "useAuthoritative", and allow it to be applied to all operations= (rather than interrogation only). The problem is in defining how to = determine whether a given entry is authoritative.
 
If, on the other hand, it seeks to force an interrogation operation = to be directed to a non-read-only, or non-shadow copy of an entry, it = should not introduce the term "authoritative". Rather it should follow = X.500 and replace that word with "non-shadow"
 
 
Jim
--=__Part3615C2AB.0__=-- --===============1862456860== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext --===============1862456860==-- From ldapext-bounces@ietf.org Thu Jun 23 23:48:01 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04325 for ; Thu, 23 Jun 2005 23:48:01 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlfZA-0007yz-7K for ldapext-archive@ietf.org; Fri, 24 Jun 2005 00:13:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dlf8S-00066k-Pl; Thu, 23 Jun 2005 23:45:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dlf8R-00066f-Ea for ldapext@megatron.ietf.org; Thu, 23 Jun 2005 23:45:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04254 for ; Thu, 23 Jun 2005 23:45:41 -0400 (EDT) Received: from boole.openldap.org ([204.152.186.50] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlfWr-0007rF-NA for ldapext@ietf.org; Fri, 24 Jun 2005 00:11:00 -0400 Received: from gyspy.OpenLDAP.org (24-205-218-53.cs-cres.charterpipeline.net [24.205.218.53]) (authenticated bits=0) by boole.openldap.org (8.13.3/8.13.3) with ESMTP id j5O3jPej084421 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Jun 2005 03:45:26 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.2.1.2.0.20050623123814.0895f1f0@mail.openldap.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 23 Jun 2005 20:45:00 -0700 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: [ldapext] draft-zeilenga-ldap-dontusecopy-00.txt In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.1 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 At 12:25 PM 6/23/2005, Jim Sermersheim wrote: >I'm struggling to understand what is meant by the terms "copy" and "authoritative". I don't see one as the antithesis of the other. I am using the term 'authoritative' in the same manner which X.500(93) uses the term 'original'. I am using the term 'copy' in the same manner as the X.500(93) term 'copy'. >How is a "copy" distinguished from an "original"? Replication in the Directory refers to the existence of copies of directory entry information and operational information held by DSAs other than the DSA responsible for the creation and update of the information. This DSA, containing the original information, is called the master DSA. ... A DSA holding copied information forwards all requests that would modify the copy information, and all requests that indicate that copy information shall not be used, to the master DSA holding the information. >How does the term "copy" relate to the term "shadow"? "Shadow" is an adjective that applies to some other term, such as "copy". A "shadow copy" is information copied through shadowing. >How do these terms relate to the term "read-only"? In X.500, copies are always read-only. >To me, the term "authoritative" is completely orthogonal to most of this. While an authoritative entry is probably never read-only, the determination of the placement of an authoritative entry may be completely arbitrary or application specific. For example, an address book application may consider a group of entries held on DSA1 to be authoritative, while a provisioning application may consider many of those same entries to be authoritative only when accessed on another DSA. Other applications may wish to share the notion of where an entry is said to be authoritative. I'll replace "authoritative" with "original" to align with X.500(93). >In my experience, the need for a control which specifies an operation take place on the authoritative copy typically has to do with update operations. As update operations can never be applied to a copy, there is no need to have a control which says the update operation must be applied to the original. >One DSA is said to be authoritative for an entry, and thus update operations may be asked to be directed at that authoritative copy. This is obviously especially true in multi-master systems. In X.500(93), only one DSA can be the master for any particular entry. >If this is what the I-D seeks to provide, I suggest it rename the control to "useAuthoritative", and allow it to be applied to all operations (rather than interrogation only). The problem is in defining how to determine whether a given entry is authoritative. not. >If, on the other hand, it seeks to force an interrogation operation to be directed to a non-read-only, or non-shadow copy of an entry, it should not introduce the term "authoritative". Rather it should follow X.500 and replace that word with "non-shadow" Yes. I will use the term 'original'. (Of course, X.500 use of the term 'master copy' is confuses matters. Which, BTW, is why I introduced the term 'authoritative'.) Kurt > > >Jim >_______________________________________________ >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 From ldapext-bounces@ietf.org Sat Jun 25 09:45:17 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28407 for ; Sat, 25 Jun 2005 09:45:17 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DmBMz-0006KT-W1 for ldapext-archive@ietf.org; Sat, 25 Jun 2005 10:10:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmAwU-0006kb-NG; Sat, 25 Jun 2005 09:43:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmAwS-0006kT-NS for ldapext@megatron.ietf.org; Sat, 25 Jun 2005 09:43:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28274 for ; Sat, 25 Jun 2005 09:43:26 -0400 (EDT) Received: from ns1.sys-net.it ([194.244.21.114] helo=mail.sys-net.it) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DmBLC-0006HD-QT for ldapext@ietf.org; Sat, 25 Jun 2005 10:09:03 -0400 Received: from [192.168.1.199] (dossi.sys-net.it [81.74.43.82]) (authenticated bits=0) by mail.sys-net.it (8.13.3/8.13.3) with ESMTP id j5PDhibk021507 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 25 Jun 2005 15:43:44 +0200 DomainKey-Signature: a=rsa-sha1; s=mail; d=sys-net.it; c=simple; q=dns; b=WJ3KCJlO1ai7FLDYo/HiIRwkGJlGdg4d/rvaPtUiyeT3ulM5AjJxZjNRXAjDjQ2BI SgUAP09NPThx4Q7g2ZODg== Message-ID: <42BD5E60.7040903@sys-net.it> Date: Sat, 25 Jun 2005 15:38:40 +0200 From: Pierangelo Masarati User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.7) Gecko/20050511 White Box/1.7.7-1.1.3.4.WB1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" References: <6.2.1.2.0.20050623123814.0895f1f0@mail.openldap.org> In-Reply-To: <6.2.1.2.0.20050623123814.0895f1f0@mail.openldap.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SysNet-MailScanner-Information: postmaster@sys-net.it X-MailScanner-From: ando@sys-net.it X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: ldapext@ietf.org Subject: [ldapext] draft-zeilenga-ldap-dontusecopy & chaining X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit > > > When the control is attached to an LDAP request, the requested > operation MUST NOT be performed on copied information. That is, the > requested operation MUST be performed on authoritative information. > > If authoritative information for the target or base object of the > operation is not available, the server MUST either return a referral > to a server believed to be better able to service the request or > return an appropriate result code (e.g., unwillingToPerform). > There might be a third option, i.e. "chain" the operation by chasing the referral to where the original data is contained. I think you should either specify if this is acceptable, provided that chaining ensures that the Don't Use Copy control is propagated along with the chaining request, or this must not be performed; if you don't clearly indicate this, I would infer that the choice is left to implementors (i.e. I would consider "authoritative information available" by means of referral chasing if the server is generically configured to chase referrals). p. SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497 _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Sat Jun 25 12:20:00 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15143 for ; Sat, 25 Jun 2005 12:20:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DmDml-0001xF-90 for ldapext-archive@ietf.org; Sat, 25 Jun 2005 12:45:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmDLc-0007Xi-NB; Sat, 25 Jun 2005 12:17:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmDLb-0007Xa-Iy for ldapext@megatron.ietf.org; Sat, 25 Jun 2005 12:17:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14987 for ; Sat, 25 Jun 2005 12:17:32 -0400 (EDT) Received: from boole.openldap.org ([204.152.186.50] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DmDkL-0001sT-2k for ldapext@ietf.org; Sat, 25 Jun 2005 12:43:11 -0400 Received: from gyspy.OpenLDAP.org (24-205-218-53.cs-cres.charterpipeline.net [24.205.218.53]) (authenticated bits=0) by boole.openldap.org (8.13.3/8.13.3) with ESMTP id j5PGHHhq018852 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 25 Jun 2005 16:17:18 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.2.1.2.0.20050625082830.05f46e08@mail.openldap.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Sat, 25 Jun 2005 09:16:49 -0700 To: Pierangelo Masarati From: "Kurt D. Zeilenga" Subject: Re: [ldapext] draft-zeilenga-ldap-dontusecopy & chaining In-Reply-To: <42BD5E60.7040903@sys-net.it> References: <6.2.1.2.0.20050623123814.0895f1f0@mail.openldap.org> <42BD5E60.7040903@sys-net.it> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.1 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 At 06:38 AM 6/25/2005, Pierangelo Masarati wrote: >> When the control is attached to an LDAP request, the requested >> operation MUST NOT be performed on copied information. That is, the >> requested operation MUST be performed on authoritative information. >> >> If authoritative information for the target or base object of the >> operation is not available, the server MUST either return a referral >> to a server believed to be better able to service the request or >> return an appropriate result code (e.g., unwillingToPerform). > >There might be a third option, i.e. "chain" the operation by chasing the referral to where the original data is contained. I don't think this document and, in general, other documents defining LDAP control extensions, should mention chaining. LDAP is a client/server protocol. If a server "chains" a request, it MUST do so in a manner that provides service consistent with the service model. This document says what service the client expects. >I think you should either specify if this is acceptable, provided that chaining ensures that the Don't Use Copy control is propagated along with the chaining request, or this must not be performed; I note that chaining servers have some obligation to ensure that a non-critical control (of any type) is either used in performing the entire operation or not used in performing the entire operation. The chaining server cannot allow a portion of the operation to be performed with a control and another portion not to be. So, when chaining a request (such as portions of a subtree search) to other servers, it has to ensure that it and those other servers, all perform the same operation. It's not good enough to simply propagate a control (of any type). To ensure proper service is provided the client (which is general obligation of the directory service), the chaining server needs to either make the control critical so as to force it use by all other servers, or to remove the control altogether to force it not to be used by all other servers. It must do the former if it used the control in any way in its performance of the operation. It must do the latter if it ignored the control in any way in its performance of the operation. If it hasn't performed any of the operation, such as in the case where it chains an entire request (like when it doesn't hold the baseObject of a search request), then it has the option of including the control as presented by the client. (I note that above implies a chaining service based upon simple rewriting of requests. Such a service may not be able to adequately chain all operations. Generally, one needs to use a chaining operation which provides the original request as well information necessary to ensure consistent performance.) Note that none of this is specific to this control. Same applies to all controls. And, because the semantics are shared, it's better this be placed in a common document about chaining. It is appropriate for control specifications to simply detail what the service is to be provided to the client is. Whether the directory service is distributed or not, the receiving server is obligated to provide service consistent with the service model. The document, I believe, adequately specifies what service is to be provided to the client. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Wed Jun 29 15:46:59 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02876 for ; Wed, 29 Jun 2005 15:46:59 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dniw4-0006HE-JR for ldapext-archive@ietf.org; Wed, 29 Jun 2005 16:13:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DniVv-0000Nt-0D; Wed, 29 Jun 2005 15:46:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DniVt-0000NW-14 for ldapext@megatron.ietf.org; Wed, 29 Jun 2005 15:46:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02687 for ; Wed, 29 Jun 2005 15:46:23 -0400 (EDT) Received: from exchange.webb.net ([207.182.164.133] helo=ossex1.webb.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnivV-0006F0-Ar for ldapext@ietf.org; Wed, 29 Jun 2005 16:12:53 -0400 Received: from perihelion.corp.jabber.com (10.2.2.77 [10.2.2.77]) by ossex1.webb.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id N5WV5CQ8; Wed, 29 Jun 2005 13:35:19 -0600 From: Matt Yacobucci To: ldapext@ietf.org Content-Type: text/plain Date: Wed, 29 Jun 2005 13:45:26 -0600 Message-Id: <1120074326.605.48.camel@perihelion.corp.jabber.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: 7bit Subject: [ldapext] Proxy Authentication X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: 7bit I am having significant problems with proxy auth. Please help. Openldap version: 2.2.17 My slapd.conf has the sasl-authz-policy set to both I have a user uid=matt1 dn: cn=matt1,dc=qa,dc=jabber,dc=com saslAuthzTo: ldap:///dc=qa,dc=jabber,dc=com??sub?(objectclass=*) When I run my sample program it fails and I get the below output in my logs: => get_ctrls: oid="2.16.840.1.113730.3.4.18" (critical) parseProxyAuthz: conn 1 authzid="cn=matt2,dc=qa,dc=jabber,dc=com" slap_sasl_getdn: id=cn=matt2,dc=qa,dc=jabber,dc=com [len=31] <= get_ctrls: n=1 rc=47 err="authzId mapping failed" send_ldap_result: conn=1 op=0 p=3 send_ldap_result: err=47 matched="" text="authzId mapping failed" SAMPLE CODE: #include #include #include #include #include #include int main() { int version; LDAP* ld; LDAPControl* requestctrls[2]; LDAPControl* pactrl = NULL; int port = 7389; char* host = "sqaldap1.qa.jabber.com"; char* baseDN = "dc=qa,dc=jabber,dc=com"; char* proxyDN = "cn=matt2,dc=qa,dc=jabber,dc=com"; char* bindDN = "cn=matt1,dc=qa,dc=jabber,dc=com"; char* bindPW = "test"; if ((ld = ldap_init(host, port)) == NULL) { printf("ldap_init did not return a conn handle.\n"); return (-1); } version = LDAP_VERSION3; ldap_set_option(ld, LDAP_OPT_PROTOCOL_VERSION, &version); if (ldap_simple_bind_s(ld, bindDN, bindPW) != LDAP_SUCCESS) { printf("ldap_simple_bind_s failed"); return (-1); } pactrl = (LDAPControl*)malloc(sizeof(LDAPControl)); memset((void*)pactrl, 0, sizeof(LDAPControl)); pactrl->ldctl_oid = LDAP_CONTROL_PROXY_AUTHZ; pactrl->ldctl_iscritical = 1; pactrl->ldctl_value.bv_val = proxyDN; pactrl->ldctl_value.bv_len = strlen(proxyDN); requestctrls[0] = pactrl; requestctrls[1] = NULL; /* Perform the search using the control */ LDAPMessage* results; printf("Searching for %s with the proxy auth control.\n", proxyDN); int err; if ( (err = ldap_search_ext_s( ld, proxyDN, LDAP_SCOPE_SUBTREE, "(objectclass=*)", NULL, 0, requestctrls, NULL, NULL, LDAP_NO_LIMIT, &results )) != LDAP_SUCCESS ) { printf("%d, %s\n", err, ldap_err2string(err)); printf("ldap_search_ext failed.\n"); printf("Something is wrong with proxied auth.\n"); } else { printf("ldap_search_ext didn't fail.\n"); } return 0; } Thanks, -- Matt Yacobucci _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Wed Jun 29 16:25:56 2005 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19266 for ; Wed, 29 Jun 2005 16:25:56 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnjXm-0004ha-8T for ldapext-archive@ietf.org; Wed, 29 Jun 2005 16:52:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dnj29-0003jU-2U; Wed, 29 Jun 2005 16:19:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dnj27-0003ef-G7 for ldapext@megatron.ietf.org; Wed, 29 Jun 2005 16:19:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16210 for ; Wed, 29 Jun 2005 16:19:41 -0400 (EDT) Received: from boole.openldap.org ([204.152.186.50] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnjRj-0003QT-1U for ldapext@ietf.org; Wed, 29 Jun 2005 16:46:12 -0400 Received: from gyspy.OpenLDAP.org (24-205-218-53.cs-cres.charterpipeline.net [24.205.218.53]) (authenticated bits=0) by boole.openldap.org (8.13.3/8.13.3) with ESMTP id j5TKJPg2025740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Jun 2005 20:19:26 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.2.1.2.0.20050629131253.06f81468@mail.openldap.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 29 Jun 2005 13:19:04 -0700 To: Matt Yacobucci From: "Kurt D. Zeilenga" Subject: Re: [ldapext] Proxy Authentication In-Reply-To: <1120074326.605.48.camel@perihelion.corp.jabber.com> References: <1120074326.605.48.camel@perihelion.corp.jabber.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.1 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: ldapext@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Please note this list is intended for discussions regarding standardization of LDAP extensions, such as the LDAP Proxied Authorization control. While questions about the specification of this control are welcomed here, it seems your post is primarily in regards to the OpenLDAP Project's implementation of this LDAP extension. Hence, you post should be redirected there. I do note that specification of this control requires the controlValue to the an LDAP authzid, or empty, and your code appears to violate this requirement by sending an LDAP DN in RFC 2253 form. draft-weltman-ldapv3-proxy-13.txt: The controlValue SHALL be present and contain either an authzId [AUTH] representing the authorization identity for the request or empty if an anonymous association is to be used. Kurt At 12:45 PM 6/29/2005, Matt Yacobucci wrote: >I am having significant problems with proxy auth. Please help. > >Openldap version: 2.2.17 > >My slapd.conf has the sasl-authz-policy set to both > >I have a user uid=matt1 >dn: cn=matt1,dc=qa,dc=jabber,dc=com >saslAuthzTo: ldap:///dc=qa,dc=jabber,dc=com??sub?(objectclass=*) > >When I run my sample program it fails and I get the below output in my >logs: >=> get_ctrls: oid="2.16.840.1.113730.3.4.18" (critical) >parseProxyAuthz: conn 1 authzid="cn=matt2,dc=qa,dc=jabber,dc=com" >slap_sasl_getdn: id=cn=matt2,dc=qa,dc=jabber,dc=com [len=31] ><= get_ctrls: n=1 rc=47 err="authzId mapping failed" >send_ldap_result: conn=1 op=0 p=3 >send_ldap_result: err=47 matched="" text="authzId mapping failed" > >SAMPLE CODE: >#include > >#include >#include >#include >#include >#include > >int main() >{ > int version; > LDAP* ld; > LDAPControl* requestctrls[2]; > LDAPControl* pactrl = NULL; > > int port = 7389; > char* host = "sqaldap1.qa.jabber.com"; > char* baseDN = "dc=qa,dc=jabber,dc=com"; > > char* proxyDN = "cn=matt2,dc=qa,dc=jabber,dc=com"; > > char* bindDN = "cn=matt1,dc=qa,dc=jabber,dc=com"; > char* bindPW = "test"; > > if ((ld = ldap_init(host, port)) == NULL) > { > printf("ldap_init did not return a conn handle.\n"); > return (-1); > } > > version = LDAP_VERSION3; > ldap_set_option(ld, LDAP_OPT_PROTOCOL_VERSION, &version); > > if (ldap_simple_bind_s(ld, bindDN, bindPW) != LDAP_SUCCESS) > { > printf("ldap_simple_bind_s failed"); > return (-1); > } > > pactrl = (LDAPControl*)malloc(sizeof(LDAPControl)); > memset((void*)pactrl, 0, sizeof(LDAPControl)); > pactrl->ldctl_oid = LDAP_CONTROL_PROXY_AUTHZ; > pactrl->ldctl_iscritical = 1; > pactrl->ldctl_value.bv_val = proxyDN; > pactrl->ldctl_value.bv_len = strlen(proxyDN); > > requestctrls[0] = pactrl; > requestctrls[1] = NULL; > > /* Perform the search using the control */ > LDAPMessage* results; > printf("Searching for %s with the proxy auth control.\n", proxyDN); > int err; > if ( (err = ldap_search_ext_s( ld, proxyDN, LDAP_SCOPE_SUBTREE, > "(objectclass=*)", > NULL, 0, requestctrls, NULL, NULL, > LDAP_NO_LIMIT, > &results )) != LDAP_SUCCESS ) { > printf("%d, %s\n", err, ldap_err2string(err)); > printf("ldap_search_ext failed.\n"); > printf("Something is wrong with proxied auth.\n"); > } else { > printf("ldap_search_ext didn't fail.\n"); > } > > return 0; >} > >Thanks, >-- >Matt Yacobucci > > >_______________________________________________ >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