From mailman-admin@ietf.org Mon Sep 1 21:29:12 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18954 for ; Mon, 1 Sep 2003 21:29:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19toLW-0000MX-Ef for ldapext-archive@lists.ietf.org; Mon, 01 Sep 2003 09:03:50 -0400 Date: Mon, 01 Sep 2003 09:03:50 -0400 Message-ID: <20030901130350.21711.35748.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: ldapext-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, ldapext-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for ldapext-archive@lists.ietf.org: List Password // URL ---- -------- ldapext@ietf.org LxAC https://www1.ietf.org/mailman/options/ldapext/ldapext-archive%40lists.ietf.org From ldapext-admin@ietf.org Tue Sep 2 04:08:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28092 for ; Tue, 2 Sep 2003 04:08:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u4e4-0001B3-6j; Tue, 02 Sep 2003 02:28:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19tzJj-00023y-7a for ldapext@optimus.ietf.org; Mon, 01 Sep 2003 20:46:43 -0400 Received: from adacel.com (gunsmoke.adacel.com.au [210.11.130.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16869 for ; Mon, 1 Sep 2003 20:45:27 -0400 (EDT) Received: from nexus.adacel.com (Not Verified[10.32.240.1]) by adacel.com with NetIQ MailMarshal (v5.5.3.16) id ; Tue, 02 Sep 2003 10:40:28 +1000 Received: (qmail 10020 invoked from network); 2 Sep 2003 00:36:59 -0000 Received: from unknown (HELO shylock) (10.32.24.166) by nexus.adacel.com with SMTP; 2 Sep 2003 00:36:59 -0000 Reply-To: From: "Andrew Sciberras" To: "Ldapext $E-mail$" Date: Tue, 2 Sep 2003 10:44:59 +1000 Message-ID: <034b01c370eb$70eeceb0$a618200a@mtwav.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [ldapext] Returning the Password Policy Control Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, I believe that there may be some ambiguity in the password policy draft (draft-behera-ldap-password-policy-06.txt) regarding the inclusion of a PasswordPolicyResponse control in LDAP response messages. When the text discusses how various operations should be processed (Section 6), it is very clear on what the passwordPolicyResponse control should contain in each of the various erroneous and successful scenario's. The text even goes to the extent of specifying that the control should be returned with an empty SEQUENCE for various bind and compare cases. I believe the ambiguity lies with other operations (ADD for example), where the text does not specify whether a control should be returned if the operation is completed successfully. Typically I would assume that the absence of such text would mean that a control should not be returned. However this seems to conflict with the following description of the 'Response Control', which can be found in section 5.2: " If the client has sent a passwordPolicyRequest control, the server sends this control with the following operation responses: bindResponse, modifyResponse, addResponse, compareResponse and possibly extendedResponse, to inform of various conditions....." Although this sentence lacks any mandating words, such as MUST, I interpret it to mean that the passwordPolicyResponse control should always be returned for the previously mentioned operations, if a passwordPolicyRequest control was supplied in the original LDAP request. So, I my question is, when should a passwordPolicyResponse control be returned? Only when the text explicitly states that it should, or whenever a passwordPolicyRequest control is included in an LDAPMessage? I think that it is important to include the passwordPolicyResponse control in every bind and compare response (when the request control is supplied) to provide a strong indication to the client that the server is enforcing the password policy. By having the server indicate its support of the password policy to the client at this early authentication stage, I don't think that it's required for the control to be returned for any other operation, unless it is conveying some useful information. Clarification on this issue would be appreciated. Thanks. Andrew Sciberras _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Wed Sep 3 17:56:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10365 for ; Wed, 3 Sep 2003 17:56:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ufbd-0007SJ-Jw; Wed, 03 Sep 2003 17:56:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ufbG-0007Rg-GH for ldapext@optimus.ietf.org; Wed, 03 Sep 2003 17:55:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10328 for ; Wed, 3 Sep 2003 17:55:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ufbD-0002xz-00 for ldapext@ietf.org; Wed, 03 Sep 2003 17:55:35 -0400 Received: from prv-mail20.provo.novell.com ([137.65.81.122]) by ietf-mx with esmtp (Exim 4.12) id 19ufbC-0002xB-00 for ldapext@ietf.org; Wed, 03 Sep 2003 17:55:35 -0400 Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 03 Sep 2003 15:54:59 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.1 Date: Wed, 03 Sep 2003 15:51:57 -0600 From: "Jim Sermersheim" To: , Subject: Re: [ldapext] Returning the Password Policy Control Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__Part0E506A6D.1__=" Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , 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. --=__Part0E506A6D.1__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit You're right, it needs to be clarified. The original intent was that the control is only returned when needed (as specified), and not needed when operations suceed (and no extra information needs to be returned). We need to consider your reasons for returning the control for every bind and compare. Jim >>> "Andrew Sciberras" 9/1/03 6:44:59 PM >>> Hi, I believe that there may be some ambiguity in the password policy draft (draft-behera-ldap-password-policy-06.txt) regarding the inclusion of a PasswordPolicyResponse control in LDAP response messages. When the text discusses how various operations should be processed (Section 6), it is very clear on what the passwordPolicyResponse control should contain in each of the various erroneous and successful scenario's. The text even goes to the extent of specifying that the control should be returned with an empty SEQUENCE for various bind and compare cases. I believe the ambiguity lies with other operations (ADD for example), where the text does not specify whether a control should be returned if the operation is completed successfully. Typically I would assume that the absence of such text would mean that a control should not be returned. However this seems to conflict with the following description of the 'Response Control', which can be found in section 5.2: " If the client has sent a passwordPolicyRequest control, the server sends this control with the following operation responses: bindResponse, modifyResponse, addResponse, compareResponse and possibly extendedResponse, to inform of various conditions....." Although this sentence lacks any mandating words, such as MUST, I interpret it to mean that the passwordPolicyResponse control should always be returned for the previously mentioned operations, if a passwordPolicyRequest control was supplied in the original LDAP request. So, I my question is, when should a passwordPolicyResponse control be returned? Only when the text explicitly states that it should, or whenever a passwordPolicyRequest control is included in an LDAPMessage? I think that it is important to include the passwordPolicyResponse control in every bind and compare response (when the request control is supplied) to provide a strong indication to the client that the server is enforcing the password policy. By having the server indicate its support of the password policy to the client at this early authentication stage, I don't think that it's required for the control to be returned for any other operation, unless it is conveying some useful information. Clarification on this issue would be appreciated. Thanks. Andrew Sciberras _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext --=__Part0E506A6D.1__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit

You're right, it needs to be clarified.

The original intent was that the control is only returned when needed (as specified), and not needed when operations suceed (and no extra information needs to be returned).

We need to consider your reasons for returning the control for every bind and compare.

Jim

>>> "Andrew Sciberras" <andrews@adacel.com.au> 9/1/03 6:44:59 PM >>>
Hi,

I believe that there may be some ambiguity in the password policy draft
(draft-behera-ldap-password-policy-06.txt) regarding the inclusion of a
PasswordPolicyResponse control in LDAP response messages.

When the text discusses how various operations should be processed (Section
6), it is very clear on what the passwordPolicyResponse control should
contain in each of the various erroneous and successful scenario's.
The text even goes to the extent of specifying that the control should be
returned with an empty SEQUENCE for various bind and compare cases.

I believe the ambiguity lies with other operations (ADD for example), where
the text does not specify whether a control should be returned if the
operation is completed successfully.
Typically I would assume that the absence of such text would mean that a
control! should not be returned. However this seems to conflict with the
following description of the 'Response Control', which can be found in
section 5.2:
" If the client has sent a passwordPolicyRequest control, the server
sends this control with the following operation responses:
bindResponse, modifyResponse, addResponse, compareResponse and
possibly extendedResponse, to inform of various conditions....."

Although this sentence lacks any mandating words, such as MUST, I interpret
it to mean that the passwordPolicyResponse control should always be returned
for the previously mentioned operations, if a passwordPolicyRequest control
was supplied in the original LDAP request.

So, I my question is, when should a passwordPolicyResponse control be
returned?
Only when the text explicitly states that it should, or whenever a
passwordPolicyRequest control is included in an LDAPMessage?

I think that it is important to include the pa! sswordPolicyResponse control
in every bind and compare response (wh en the request control is supplied) to
provide a strong indication to the client that the server is enforcing the
password policy.
By having the server indicate its support of the password policy to the
client at this early authentication stage, I don't think that it's required
for the control to be returned for any other operation, unless it is
conveying some useful information.

Clarification on this issue would be appreciated.

Thanks.
Andrew Sciberras

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

--=__Part0E506A6D.1__=-- _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Wed Sep 3 20:17:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19890 for ; Wed, 3 Sep 2003 20:17:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uho5-0004T9-5Y; Wed, 03 Sep 2003 20:17:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uhnE-0004SA-5A for ldapext@optimus.ietf.org; Wed, 03 Sep 2003 20:16:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19831 for ; Wed, 3 Sep 2003 20:16:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uhnC-0006pc-00 for ldapext@ietf.org; Wed, 03 Sep 2003 20:16:06 -0400 Received: from gunsmoke.adacel.com.au ([210.11.130.7] helo=adacel.com) by ietf-mx with esmtp (Exim 4.12) id 19uhnA-0006oX-00 for ldapext@ietf.org; Wed, 03 Sep 2003 20:16:04 -0400 Received: from nexus.adacel.com (Not Verified[10.32.240.1]) by adacel.com with NetIQ MailMarshal (v5.5.3.16) id ; Thu, 04 Sep 2003 10:10:47 +1000 Received: (qmail 634 invoked from network); 4 Sep 2003 00:07:20 -0000 Received: from unknown (HELO shylock) (10.32.24.166) by nexus.adacel.com with SMTP; 4 Sep 2003 00:07:20 -0000 Reply-To: From: "Andrew Sciberras" To: "'Jim Sermersheim'" Cc: "Ldapext $E-mail$" Subject: RE: [ldapext] Returning the Password Policy Control Date: Thu, 4 Sep 2003 10:15:33 +1000 Message-ID: <041d01c37279$a938b120$a618200a@mtwav.adacel.com.au> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_041E_01C372CD.7AE4C120" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_041E_01C372CD.7AE4C120 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit G'Day, Take a look at the scenario of a bound entity changing their own userPassword and including a passwordPolicyRequest control in the LDAPMessage. (Where a passwordPolicy is in place for the userPassword attribute). By following the steps described in 6.2, if the operation succeeds, the user will simply get an LDAPMessage back with a LDAPResult of `success' and no passwordPolicyResponse control. At this point in time the entity would have no idea as to whether a password policy is being applied to their userPassword. Receiving the successful response without a passwordPolicyResponse control could mean: * The DSA knows nothing about the Password Policy control, and since it was not marked as being critical, has just ignored it, * The DSA does support Password Policy controls, but no password policy was applied to this `userPassword' attribute, * The DSA does support the Password Policy control, and a policy does apply to the userPassword attribute. If the intention of the Password Policy Specification is to suppress returning controls on successful operations, then I think we need some way to indicate to the client that a password policy is being applied to their password. I think an ideal time to do this is when the entity is using their password to authenticate themselves in a bind or compare operation. By returning the password policy control, even on a successful compare or bind, it makes the entity aware that their password has a policy applied to it and that subsequent operations performed on this password attribute will result in the policy being enforced. Regards, Andrew Sciberras -----Original Message----- From: Jim Sermersheim [mailto:jimse@novell.com] Sent: Thursday, 4 September 2003 7:52 To: andrews@adacel.com.au; ldapext@ietf.org Subject: Re: [ldapext] Returning the Password Policy Control You're right, it needs to be clarified. The original intent was that the control is only returned when needed (as specified), and not needed when operations suceed (and no extra information needs to be returned). We need to consider your reasons for returning the control for every bind and compare. Jim >>> "Andrew Sciberras" 9/1/03 6:44:59 PM >>> Hi, I think that it is important to include the passwordPolicyResponse control in every bind and compare response (when the request control is supplied) to provide a strong indication to the client that the server is enforcing the password policy. Thanks. Andrew Sciberras _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext ------=_NextPart_000_041E_01C372CD.7AE4C120 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

G'Day,

Take a look at the scenario of a bound = entity=20 changing their own userPassword and including a passwordPolicyRequest = control in=20 the LDAPMessage. (Where a passwordPolicy is in place for the = userPassword=20 attribute).

By following the steps described in = 6.2, if=20 the operation succeeds, the user will simply get an LDAPMessage back = with a=20 LDAPResult of `success' and no passwordPolicyResponse control. =

At this point in time the entity = would have=20 no idea as to whether a password policy is being applied to their=20 userPassword.

Receiving=20 the successful response without a passwordPolicyResponse control = could=20 mean:

* The DSA knows = nothing=20 about the Password Policy control, and since it was not marked as being=20 critical, has just ignored it,

* The DSA does = support=20 Password Policy controls, but no password policy was applied to this=20 `userPassword' attribute,

* The DSA does = support the=20 Password Policy control, and a policy does apply to the userPassword=20 attribute.

If the=20 intention of the Password Policy Specification is to=20 suppress returning controls on successful operations, then I think = we need=20 some way to indicate to the client that a password policy is being = applied=20 to their password.

I think an ideal time to do this is = when the=20 entity is using their password to authenticate themselves in a bind or = compare=20 operation. By returning the password policy control, even on a = successful=20 compare or bind, it makes the entity aware that their password has a = policy=20 applied to it and that subsequent operations performed on this password=20 attribute will result in the policy being enforced.

=20

Regards,

Andrew = Sciberras

-----Original=20 Message-----
From: Jim Sermersheim=20 [mailto:jimse@novell.com]
Sent: Thursday, 4 September 2003=20 7:52
To: andrews@adacel.com.au; = ldapext@ietf.org
Subject:=20 Re: [ldapext] Returning the Password Policy = Control

You're right, it needs to be clarified.

The original intent was that the control is only returned when = needed (as=20 specified), and not needed when operations suceed (and no extra = information=20 needs to be returned).

We need to consider your reasons for returning the control for = every bind=20 and compare.

Jim

>>> "Andrew Sciberras" = <andrews@adacel.com.au>=20 9/1/03 6:44:59 PM >>>
Hi,

<snip>

I think that it = is=20 important to include the passwordPolicyResponse control
in every = bind and=20 compare response (when the request control is supplied) to
provide = a strong=20 indication to the client that the server is enforcing the
password=20 policy.

</snip>

Thanks.
Andrew=20 = Sciberras

_______________________________________________
L= dapext=20 mailing list
Ldapext@ietf.org=20
https://www1.ietf= .org/mailman/listinfo/ldapext=20

------=_NextPart_000_041E_01C372CD.7AE4C120-- _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Sep 4 08:23:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16419 for ; Thu, 4 Sep 2003 08:23:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ut8f-0005m0-HD; Thu, 04 Sep 2003 08:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ut7z-0005l9-4X for ldapext@optimus.ietf.org; Thu, 04 Sep 2003 08:22:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16385 for ; Thu, 4 Sep 2003 08:22:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ut7x-00066G-00 for ldapext@ietf.org; Thu, 04 Sep 2003 08:22:17 -0400 Received: from e6.ny.us.ibm.com ([32.97.182.106]) by ietf-mx with esmtp (Exim 4.12) id 19ut7x-00065d-00 for ldapext@ietf.org; Thu, 04 Sep 2003 08:22:17 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e6.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h84CLhSO544218 for ; Thu, 4 Sep 2003 08:21:43 -0400 Received: from d27ml001.rchland.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h84CLg4c058660 for ; Thu, 4 Sep 2003 08:21:42 -0400 Subject: RE: [ldapext] Returning the Password Policy Control To: ldapext@ietf.org X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: John McMeeking Date: Thu, 4 Sep 2003 07:21:39 -0500 X-MIMETrack: Serialize by Router on d27ml001/27/M/IBM(Build V65_08242003|August 24, 2003) at 09/04/2003 07:21:42 AM MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable I've never thought of the password policy control response as being a mechanism for informing the client that a password policy applied to an= y given request=2E Rather, I view the purpose of the control to be to ca= rry additional error / warning information so that a password policy aware client could react to it=2E I don't think the typical application is concerned with whether a passw= ord policy is in effect, any more than I would expect logon to a system to = tell me that=2E I just want to know that I have logged in successfully, or changed my password successfully, and if there is an error (or my passw= ord is about to expire), then I want to know that it is because passwords expire every 186 days (for example)=2E I do think that an administrator or auditor has an interest in knowing = that password policy applies to a given entry and / or password attribute=2E= I don't think that returning a password policy response control is the be= st way to satisfy such a requirement=2E One way to accomplish this is to = define an operational attribute, say passwordPolicySubentry, that names the password policy subentry(ies?) that governs the entry=2E The administr= ator / auditor should have authority to read the password policy entry=2E If there is a subtreespecification associated with the password policy [sub]entry, it could be challenging determining whether a given policy applies to a specific entry=2E For example, an entry could fall within= a governed subtree, but not match the filter or other component of the subtree specification=2E The question of whether a subtree specificati= on applies to an entry is a general problem=2E It might be appropriate to= have password policy define the passwordPolicySubentry attribute, and have something like the subentry draft define an extended operation to deter= mine if a given subentry applies to a given entry=2E John McMeeking = "Andrew = Sciberras" To: "'Jim Sermersh= eim'" om=2Eau> Subject: RE: [ldapext= ] Returning the Password Policy Control Sent by: = ldapext-admin@iet = f=2Eorg = = = 09/03/2003 07:15 = PM = Please respond to = andrews = = = G'Day, Take a look at the scenario of a bound entity changing their own userPassword and including a passwordPolicyRequest control in the LDAPMessage=2E (Where a passwordPolicy is in place for the userPassword= attribute)=2E By following the steps described in 6=2E2, if the operation succeeds, = the user will simply get an LDAPMessage back with a LDAPResult of `success= ' and no passwordPolicyResponse control=2E At this point in time the entity would have no idea as to whether a password policy is being applied to their userPassword=2E Receiving the successful response without=A0a passwordPolicyResponse c= ontrol could mean: =A0=A0=A0 * The DSA knows nothing about the Password Policy control, a= nd since it was not marked as being critical, has just ignored it, =A0=A0=A0 * The DSA does support Password Policy controls, but no pass= word policy was applied to this `userPassword' attribute, =A0=A0=A0 * The DSA does support the Password Policy control, and a po= licy does apply to the userPassword attribute=2E If the intention of the Password Policy Specification is=A0to suppress=A0returning controls on successful operations, then I think we= need some way to indicate to the client that=A0a password policy is being ap= plied to their password=2E I think an ideal time to do this is when the entity is using their password to authenticate themselves in a bind or compare operation=2E = By returning the password policy control, even on a successful compare or= bind, it makes the entity aware that their password has a policy appli= ed to it and that subsequent operations performed on this password attrib= ute will result in the policy being enforced=2E Regards, Andrew Sciberras -----Original Message----- From: Jim Sermersheim [mailto:jimse@novell=2Ecom] Sent: Thursday, 4 September 2003 7:52 To: andrews@adacel=2Ecom=2Eau; ldapext@ietf=2Eorg Subject: Re: [ldapext] Returning the Password Policy Control You're right, it needs to be clarified=2E The original intent was that the control is only returned when needed (= as specified), and not needed when operations suceed (and no extra informa= tion needs to be returned)=2E We need to consider your reasons for returning the control for every bi= nd and compare=2E Jim >>> "Andrew Sciberras" 9/1/03 6:44:59 PM >= >> Hi, =A0 I think that it is important to include the passwordPolicyResponse con= trol in every bind and compare response (when the request control is suppli= ed) to provide a strong indication to the client that the server is enforcing= the password policy=2E =A0Thanks=2E Andrew Sciberras _______________________________________________ Ldapext mailing list Ldapext@ietf=2Eorg https://www1=2Eietf=2Eorg/mailman/listinfo/ldapext = _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Sep 4 08:40:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17367 for ; Thu, 4 Sep 2003 08:40:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19utP9-00070a-J9; Thu, 04 Sep 2003 08:40:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19utOc-0006yc-IB for ldapext@optimus.ietf.org; Thu, 04 Sep 2003 08:39:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17274 for ; Thu, 4 Sep 2003 08:39:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19utOb-00079M-00 for ldapext@ietf.org; Thu, 04 Sep 2003 08:39:29 -0400 Received: from e1.ny.us.ibm.com ([32.97.182.101]) by ietf-mx with esmtp (Exim 4.12) id 19utOW-00078L-00 for ldapext@ietf.org; Thu, 04 Sep 2003 08:39:25 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h84Cchg2149838 for ; Thu, 4 Sep 2003 08:38:43 -0400 Received: from d27ml001.rchland.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h84Ccg4c022802 for ; Thu, 4 Sep 2003 08:38:42 -0400 To: ldapext@ietf.org X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: John McMeeking Date: Thu, 4 Sep 2003 07:38:38 -0500 X-MIMETrack: Serialize by Router on d27ml001/27/M/IBM(Build V65_08242003|August 24, 2003) at 09/04/2003 07:38:42 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: [ldapext] Password Policy - locking accounts Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Is the notion of an administrator locking/unlocking (i.e. enable/disable for authentication) an entry within the scope of the password policy draft? This seems like a logical addition and a reasonable candidate for something to be done in a standard way. If folks agree, I suggest adding an extended operation to lock or unlock a given entry. On a related note, it is common to be able to set "password must be reset" on a per user basis -- for example setting the password for an entry to be used by an application. This could be done by modifying the pwdReset attribute, in which I think it would be appropriate for password policy to specify that servers may allow this attribute to be modified. Or another extended operation; I don't have any good guidelines for when I think an extended operation is more appropriate than modifying what has so far been presented as a "status" attribute -- though I didn't see any "NO-USER-MODIFICATION" atttached to any of these attributes. John McMeeking _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Sep 4 11:07:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00273 for ; Thu, 4 Sep 2003 11:07:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uvhM-0007Jp-QE; Thu, 04 Sep 2003 11:07:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uvge-0007IZ-Vm for ldapext@optimus.ietf.org; Thu, 04 Sep 2003 11:06:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00088 for ; Thu, 4 Sep 2003 11:06:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uvgc-0005Gn-00 for ldapext@ietf.org; Thu, 04 Sep 2003 11:06:14 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx with esmtp (Exim 4.12) id 19uvgb-0005Gf-00 for ldapext@ietf.org; Thu, 04 Sep 2003 11:06:13 -0400 Received: from odin.France.Sun.COM ([129.157.174.8]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h84F3Phi022966; Thu, 4 Sep 2003 09:03:26 -0600 (MDT) Received: from Sun.com (bondi [129.157.192.47]) by odin.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with ESMTP id h84F3Oe26713; Thu, 4 Sep 2003 17:03:24 +0200 (MEST) Message-ID: <3F57543C.4000806@Sun.com> Date: Thu, 04 Sep 2003 17:03:24 +0200 From: Ludovic Poitou Organization: Sun Microsystems Inc. User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John McMeeking CC: ldapext@ietf.org Subject: Re: [ldapext] Password Policy - locking accounts References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit John McMeeking wrote: > > >Is the notion of an administrator locking/unlocking (i.e. enable/disable >for authentication) an entry within the scope of the password policy draft? >This seems like a logical addition and a reasonable candidate for something >to be done in a standard way. > >If folks agree, I suggest adding an extended operation to lock or unlock a >given entry. > I don't believe that enabling / disabling an account for authentication is part of the password policy. I think it is more of a question of a login policy (ie one would like to enable / disable only some part of the day, or during week ends...). This is outside the scope of the password policy document. > >On a related note, it is common to be able to set "password must be reset" >on a per user basis -- for example setting the password for an entry to be >used by an application. This could be done by modifying the pwdReset >attribute, in which I think it would be appropriate for password policy to >specify that servers may allow this attribute to be modified. Or another >extended operation; I don't have any good guidelines for when I think an >extended operation is more appropriate than modifying what has so far been >presented as a "status" attribute -- though I didn't see any >"NO-USER-MODIFICATION" atttached to any of these attributes. > > Our implementation allows administrators to modify the operational attributes. It's easier than extended operation and more coupled with Access Controls. Extended operations are more complex to build in clients and SDKs and Access Controls are to be set for each extended operation as well. I agree that we should add some text in the draft regarding the possibility to modify some of the attributes. Ludovic. >John McMeeking > > >_______________________________________________ >Ldapext mailing list >Ldapext@ietf.org >https://www1.ietf.org/mailman/listinfo/ldapext > > -- Ludovic Poitou Sun Microsystems Inc. Sun ONE products - Directory Server Group - Grenoble - France _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Sep 4 18:03:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25659 for ; Thu, 4 Sep 2003 18:03:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v2Bx-0000Yy-1J; Thu, 04 Sep 2003 18:03:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v2Bt-0000Yf-0j for ldapext@optimus.ietf.org; Thu, 04 Sep 2003 18:02:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25568 for ; Thu, 4 Sep 2003 18:02:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19v2Bq-0005wV-00 for ldapext@ietf.org; Thu, 04 Sep 2003 18:02:54 -0400 Received: from gunsmoke.adacel.com.au ([210.11.130.7] helo=adacel.com) by ietf-mx with esmtp (Exim 4.12) id 19v2Bo-0005w4-00 for ldapext@ietf.org; Thu, 04 Sep 2003 18:02:53 -0400 Received: from nexus.adacel.com (Not Verified[10.32.240.1]) by adacel.com with NetIQ MailMarshal (v5.5.3.16) id ; Fri, 05 Sep 2003 07:57:23 +1000 Received: (qmail 23189 invoked from network); 4 Sep 2003 21:53:56 -0000 Received: from unknown (HELO shylock) (10.32.24.166) by nexus.adacel.com with SMTP; 4 Sep 2003 21:53:56 -0000 Reply-To: From: "Andrew Sciberras" To: "'John McMeeking'" Cc: Subject: RE: [ldapext] Returning the Password Policy Control Date: Fri, 5 Sep 2003 08:02:16 +1000 Message-ID: <046e01c37330$34a66390$a618200a@mtwav.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Content-Transfer-Encoding: 7bit Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi John! >One way to accomplish this is to define >an operational attribute, say passwordPolicySubentry, that names the >password policy subentry(ies?) that governs the entry. The administrator / >auditor should have authority to read the password policy entry. >It might be appropriate to have password policy define the >passwordPolicySubentry attribute, and have something like the subentry >draft define an extended operation to determine if a given subentry applies >to a given entry. The password policy does define an operational attribute called pwdPolicySubentry which points to the pwdPolicy subentry in effect for the given entry. And your absolutely right, anyone could use this attribute to identify the exact details of the passsword policy being applied to the various attributes within the entry. I guess my question now is, if the intention of the password policy response control is purely to convey error and warning information, what is the point of returning a response control without any information? After a quick glace at the draft, this apears to occur in the Bind and Compare operations. > >John McMeeking > Cheers, Andrew Sciberras _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Sep 4 18:12:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26848 for ; Thu, 4 Sep 2003 18:12:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v2Kf-0001B3-5S; Thu, 04 Sep 2003 18:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v2Js-0001AB-3y for ldapext@optimus.ietf.org; Thu, 04 Sep 2003 18:11:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26683 for ; Thu, 4 Sep 2003 18:11:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19v2Jp-00068d-00 for ldapext@ietf.org; Thu, 04 Sep 2003 18:11:09 -0400 Received: from gunsmoke.adacel.com.au ([210.11.130.7] helo=adacel.com) by ietf-mx with esmtp (Exim 4.12) id 19v2Jo-00067U-00 for ldapext@ietf.org; Thu, 04 Sep 2003 18:11:08 -0400 Received: from nexus.adacel.com (Not Verified[10.32.240.1]) by adacel.com with NetIQ MailMarshal (v5.5.3.16) id ; Fri, 05 Sep 2003 08:05:45 +1000 Received: (qmail 23810 invoked from network); 4 Sep 2003 22:02:18 -0000 Received: from unknown (HELO shylock) (10.32.24.166) by nexus.adacel.com with SMTP; 4 Sep 2003 22:02:18 -0000 Reply-To: From: "Andrew Sciberras" To: "'John McMeeking'" , Subject: RE: [ldapext] Password Policy - locking accounts Date: Fri, 5 Sep 2003 08:10:38 +1000 Message-ID: <046f01c37331$5fc6ed50$a618200a@mtwav.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Content-Transfer-Encoding: 7bit Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi John! >Is the notion of an administrator locking/unlocking (i.e. >enable/disable >for authentication) an entry within the scope of the password >policy draft? >This seems like a logical addition and a reasonable candidate >for something >to be done in a standard way. The draft specifies an attribute called pwdAccountLockedTime which holds the time at which the user's account was locked. The draft states the following about the operational attribute (Section 4.3.3): >A 0 value means that the account has been locked >permanently, and that only an administrator can unlock the account. Since 0 isn't a valid GeneralizedTime value, I assume it means 00000101000Z. In any case, the administrator could simply set this attribute to the zero value in an account, which would effectively provide an administrator with the power to lock/unlock an entry. > >John McMeeking > Andrew Sciberras _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Sep 4 20:02:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03577 for ; Thu, 4 Sep 2003 20:02:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v437-0005SP-HP; Thu, 04 Sep 2003 20:02:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v42j-0005Rv-Dm for ldapext@optimus.ietf.org; Thu, 04 Sep 2003 20:01:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03515 for ; Thu, 4 Sep 2003 20:01:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19v42h-0000xU-00 for ldapext@ietf.org; Thu, 04 Sep 2003 20:01:35 -0400 Received: from gunsmoke.adacel.com.au ([210.11.130.7] helo=adacel.com) by ietf-mx with esmtp (Exim 4.12) id 19v42g-0000uC-00 for ldapext@ietf.org; Thu, 04 Sep 2003 20:01:34 -0400 Received: from nexus.adacel.com (Not Verified[10.32.240.1]) by adacel.com with NetIQ MailMarshal (v5.5.3.16) id ; Fri, 05 Sep 2003 09:56:09 +1000 Received: (qmail 3071 invoked from network); 4 Sep 2003 23:52:43 -0000 Received: from unknown (HELO osmium) (10.32.24.165) by nexus.adacel.com with SMTP; 4 Sep 2003 23:52:43 -0000 Reply-To: From: "Steven Legg" To: "'John McMeeking'" , Subject: RE: [ldapext] Returning the Password Policy Control Date: Fri, 5 Sep 2003 11:01:00 +1100 Message-ID: <005001c37340$cae062b0$a518200a@osmium.mtwav.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id UAA03516 Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable John, John McMeeking wrote: > If there is a subtreespecification associated with the password policy > [sub]entry, it could be challenging determining whether a given policy > applies to a specific entry. For example, an entry could > fall within a > governed subtree, but not match the filter or other component of the > subtree specification. The question of whether a subtree > specification > applies to an entry is a general problem. I have been using subtree specifications for a long time and haven't found them to be challenging. Given an entry's DN and object class it is a straightforward test to decide if the entry is within the specified subtree. Regards, Steven > It might be > appropriate to have > password policy define the passwordPolicySubentry attribute, and have > something like the subentry draft define an extended > operation to determine > if a given subentry applies to a given entry. > > > John McMeeking > > > > > > "Andrew > > Sciberras" To: > "'Jim Sermersheim'" > "Ldapext $E-mail$" > om.au> Subject: RE: > [ldapext] Returning the Password Policy Control > Sent by: > > ldapext-admin@iet > > f.org > > > > > > 09/03/2003 07:15 > > PM > > Please respond to > > andrews > > > > > > > > > > > G'Day, > > Take a look at the scenario of a bound entity changing their own > userPassword and including a passwordPolicyRequest control in the > LDAPMessage. (Where a passwordPolicy is in place for the userPassword > attribute). > By following the steps described in 6.2, if the operation > succeeds, the > user will simply get an LDAPMessage back with a LDAPResult > of `success' > and no passwordPolicyResponse control. > At this point in time the entity would have no idea as to whether a > password policy is being applied to their userPassword. > Receiving the successful response without=A0a > passwordPolicyResponse control > could mean: > =A0=A0=A0 * The DSA knows nothing about the Password Policy > control, and since > it was not marked as being critical, has just ignored it, > =A0=A0=A0 * The DSA does support Password Policy controls, but no pass= word > policy was applied to this `userPassword' attribute, > =A0=A0=A0 * The DSA does support the Password Policy control, and > a policy does > apply to the userPassword attribute. > > If the intention of the Password Policy Specification is=A0to > suppress=A0returning controls on successful operations, then I > think we need > some way to indicate to the client that=A0a password policy is > being applied > to their password. > I think an ideal time to do this is when the entity is using their > password to authenticate themselves in a bind or compare > operation. By > returning the password policy control, even on a successful > compare or > bind, it makes the entity aware that their password has a > policy applied > to it and that subsequent operations performed on this > password attribute > will result in the policy being enforced. > > Regards, > Andrew Sciberras > > -----Original Message----- > From: Jim Sermersheim [mailto:jimse@novell.com] > Sent: Thursday, 4 September 2003 7:52 > To: andrews@adacel.com.au; ldapext@ietf.org > Subject: Re: [ldapext] Returning the Password Policy Control > > > You're right, it needs to be clarified. > > The original intent was that the control is only returned > when needed (as > specified), and not needed when operations suceed (and no > extra information > needs to be returned). > > We need to consider your reasons for returning the control > for every bind > and compare. > > Jim > > >>> "Andrew Sciberras" 9/1/03 6:44:59 PM >>> > Hi, > > =A0 > > I think that it is important to include the > passwordPolicyResponse control > in every bind and compare response (when the request control > is supplied) > to > provide a strong indication to the client that the server is > enforcing the > password policy. > > > > =A0Thanks. > Andrew Sciberras > > > _______________________________________________ > 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-admin@ietf.org Mon Sep 15 14:41:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18461 for ; Mon, 15 Sep 2003 14:41:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yyHV-0005FG-Qp; Mon, 15 Sep 2003 14:41:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yyH1-0005E7-2A for ldapext@optimus.ietf.org; Mon, 15 Sep 2003 14:40:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18386 for ; Mon, 15 Sep 2003 14:40:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19yyGy-00047O-00 for ldapext@ietf.org; Mon, 15 Sep 2003 14:40:28 -0400 Received: from smtp.opengroup.org ([192.153.166.4]) by ietf-mx with esmtp (Exim 4.12) id 19yyGx-000462-00 for ldapext@ietf.org; Mon, 15 Sep 2003 14:40:27 -0400 Received: from CHRIS-H.opengroup.org (woodrising.demon.co.uk [194.222.114.254]) by smtp.opengroup.org (8.11.6/8.11.6) with ESMTP id h8FIddG25277; Mon, 15 Sep 2003 19:39:39 +0100 Message-Id: <5.1.0.14.1.20030915192900.031bcc18@mailhome.rdg.opengroup.org> X-Sender: cjh@mailhome.rdg.opengroup.org X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 15 Sep 2003 19:36:23 +0100 To: ietf-ldapbis@openldap.org, ietf-ldup@imc.org, ldapext@ietf.org, ldap@umich.edu.list.cnri.reston.va.us From: Chris Harding Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_10 version=2.55 Subject: [ldapext] LDAP Plugfest Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Hi - The Directory Interoperability Forum (DIF) is holding 2003's second LDAP interoperability PLUGFEST for directories and directory-enabled applications at the Oracle Conference Center in Redwood Shores, CA on October 6-7, 2003. Directory-enabled application vendors can use this PLUGFEST to test in preparation for certifying that their applications are "LDAP Ready", an Open Group Certification that assures customers that the applications are guaranteed interoperable with LDAP Certified directory products. PLUGFESTS are events where multiple vendors meet and test product interoperability in real life. These events are the most effective way to test product interoperability, because they are tested against products they will meet in customer IT infrastructures. If you develop products use the Lightweight Directory Access Protocol (LDAP), then they must interoperate with LDAP servers in order to function. Certification of this interoperability will give your customers confidence that your products do truly interoperate at a useful level, and increase your sales volumes at lower sales, marketing, development and testing costs. Check out our website at http://www.opengroup.org/dif/dc11/ to find out more. You can register for the PLUGFEST on the web. Or contact me for more information. (I'm sending this mail to several relevant lists. My apologies if you receive it more than once.) Regards, Chris +++++ ======================================================================== Dr. Christopher J. Harding T H E Executive Director for the Directory Interoperability Forum O P E N Apex Plaza, Forbury Road, Reading RG1 1AX, UK G R O U P Mailto:c.harding@opengroup.org Phone: +44 118 902 3018 WWW: http://www.opengroup.org Mobile: +44 774 063 1520 ======================================================================== Boundaryless Information Flow: Open Source In The Enterprise September 8, 2003 Hilton London Paddington, London, UK www.opengroup.org/london2003 ======================================================================== _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext