From ldapext-bounces@ietf.org Mon Jan 02 01:23:45 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtJ6f-00046k-82; Mon, 02 Jan 2006 01:23:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtJ6d-00046F-I4 for ldapext@megatron.ietf.org; Mon, 02 Jan 2006 01:23:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20972 for ; Mon, 2 Jan 2006 01:22:29 -0500 (EST) Received: from dp.samba.org ([66.70.73.150] helo=lists.samba.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtJBf-0004N0-4J for ldapext@ietf.org; Mon, 02 Jan 2006 01:28:55 -0500 Received: from localhost.localdomain (localhost [127.0.0.1]) by lists.samba.org (Postfix) with ESMTP id 65772162BC6; Mon, 2 Jan 2006 06:23:39 +0000 (GMT) Subject: Re: [ldapext] Interaction of with authentication applications From: Andrew Bartlett To: Pierangelo Masarati In-Reply-To: <1135688297.3650.7.camel@ando> References: <1135688297.3650.7.camel@ando> Date: Mon, 02 Jan 2006 17:23:38 +1100 Message-Id: <1136183018.15159.78.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: Alexey Melnikov , 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="===============1125379429==" Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org --===============1125379429== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-hwLmBXjQpSB1kxHbchvw" --=-hwLmBXjQpSB1kxHbchvw Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2005-12-27 at 13:58 +0100, Pierangelo Masarati wrote: > Dear all, >=20 > Howard Chu and I, of the OpenLDAP Project, and Alexey Melnikov of Cyrus > SASL have been chatting about the issues of making password-based SASL > mechs aware and respectful of any Password Policy mechanism implemented > at the DSA that contains the passwords, and used by the SASL mechanisms > by way of auxprop lookup. I'll briefly summarize the private discussion > we had, and then expose my suggestions for a possible evolution of > draft-behera-ldap-password-policy. > This message should be considered a notification of the problem we're > addressing; we're open to suggestions for different solutions. We think > it would be important to include this further lookup-based mechanism > into those accounted for by the LDAP password policy I.D., because it > would broaden its application to authentication mechanisms that are > closely related to those currently addressed. I'm very interested in this space, due to the poor history that Samba has achieved in solving exactly these problems in the past. As I develop Samba4 and it's LDAP server, I would like to move to better and more standards-based solutions. In particular, I have an aim that Samba4 (an implementation of many of the AD protocols for windows domain control, amongst other things) may back onto an arbitrary LDAP server. This places Samba4 in the same situation as Cyrus-SASL above. Similarly, Samba3 is already in that situation, and performs poorly in this area. Firstly, I fail to see the distinction between directory authentication and application authentication, in a well-managed solution. This will show in the remainder of my response. As a history: Traditionally, Samba3 used LDAP simply as a data store, with no reference to it for password policy, or even synchronisation. =20 Before the Samba3 release, I added support to set passwords into LDAP using the openldap password set exop (but would only read it's own password values). Samba3 eventually gained support for reading the Novell eDirectory universal password, and this is where the hacks really started: The password is obtained with a custom exop, and to perform the second stage (the notification of the authentication results), a *simple bind* was returned to the server. The bind would be with the plaintext password to indicate success (and the result checked to indicate if the policy would allow the login), or with a random password to indicate failure. While I don't expect changes in this area for Samba3 (however anything is possible), I would really like to see a better and standards-based way to handle this over LDAP in Samba4. I would like Cyrus-SASL (and RADIUS servers etc) to operate in a Samba4 environment, and correctly honour our password policy, in a standard manner. A standard policy here would also simplify the creation of alternate KDC implementations (which would back onto Samba4 via LDAP). =20 I would also like Samba4 to use the directory policy, when it is simply a front-end to the larger directory. So, I'm glad to hear that this area is being thought about by others. One particular comment I have is that for a password change, I need to be able to trigger what is considered by the directory to be a 'user change' operation, but with administrative credentials. This is because we do not get the old plaintext in the kpassswd and NTLM password change systems. I also need to be able to return the following values (samr.idl in samba4): /* password properties flags */ const uint32 DOMAIN_PASSWORD_COMPLEX =3D 0x00000001; const uint32 DOMAIN_PASSWORD_NO_ANON_CHANGE =3D 0x00000002; const uint32 DOMAIN_PASSWORD_NO_CLEAR_CHANGE =3D 0x00000004; const uint32 DOMAIN_PASSWORD_STORE_CLEARTEXT =3D 0x00000010; const uint32 DOMAIN_REFUSE_PASSWORD_CHANGE =3D 0x00000020; typedef struct { uint16 min_password_length; uint16 password_history_length; uint32 password_properties; /* yes, these are signed. They are in negative 100ns */ dlong max_password_age; dlong min_password_age; } samr_DomInfo1; Andrew Bartlett --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Student Network Administrator, Hawker College http://hawkerc.net --=-hwLmBXjQpSB1kxHbchvw Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQBDuMbqz4A8Wyi0NrsRAndLAKCHay/0icAFfRYAnlr1aayKTXYWkwCfWoGK SLiT6W9kTbFl7D0Ji45j29E= =jDQm -----END PGP SIGNATURE----- --=-hwLmBXjQpSB1kxHbchvw-- --===============1125379429== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext --===============1125379429==-- From ldapext-bounces@ietf.org Mon Jan 02 02:57:14 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtKZ7-000135-Ry; Mon, 02 Jan 2006 02:57:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtKZ3-000118-Ot for ldapext@megatron.ietf.org; Mon, 02 Jan 2006 02:57:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29505 for ; Mon, 2 Jan 2006 02:55:57 -0500 (EST) Received: from ns1.sys-net.it ([194.244.21.114] helo=mail.sys-net.it) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtKe5-0007G2-Kv for ldapext@ietf.org; Mon, 02 Jan 2006 03:02:22 -0500 Received: from ando.intra.sys-net.it (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 k027uFJG005672 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 2 Jan 2006 08:56:22 +0100 Subject: Re: [ldapext] Interaction of with authentication applications From: Pierangelo Masarati To: Andrew Bartlett In-Reply-To: <1136183018.15159.78.camel@localhost.localdomain> References: <1135688297.3650.7.camel@ando> <1136183018.15159.78.camel@localhost.localdomain> Content-Type: text/plain Date: Mon, 02 Jan 2006 09:03:20 +0100 Message-Id: <1136189001.3334.14.camel@ando> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-22) Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.1 (mail.sys-net.it [194.244.21.114]); Mon, 02 Jan 2006 08:56:23 +0100 (CET) X-SysNet-MailScanner-Information: postmaster@sys-net.it X-MailScanner-From: ando@sys-net.it X-Spam-Score: 0.0 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Content-Transfer-Encoding: 7bit Cc: Alexey Melnikov , 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 Andrew, without getting too much into the details of your message, what you describe sounds quite close to what I mean. The point is that the draft-behera-ldap-password-policy is essentially intended for a simple client <-> server relationship, and there seems to be no intention to broaden it to generic password policy (which I understand, because if it needs to account for all the different needs it could become obfuscate and nearly unusable). When speaking about application authentication, I mean something like client <-> { application <-> DSA } where the application authenticates the client using services stored on the DSA server, including the password and the password policy. The policy could still apply if you see the whole from the client's perspective, but now the server doesn't get a simple bind but rather an auxprop lookup, as in general we cannot turn generic password-based authentications into simple binds. So if we still want to apply the password policy, using the facilities provided by the DSA, the responsibility has to move to the application. Technically, this has to result in a code duplication which, IMHO, could be eliminated by providing some cooperation means between the application and the server. With OpenLDAP, for example, we can circumvent this by moving password policy enforcement into the app (in this case Cyrus SASL, but I guess it would be essentially the same with Samba 3, as far as I know of it). Then, the administrative operations related to storing policy info into the DSA would be performed as regular modify, with a privileged identity, and with the manageDIT control (undocumented, I know; it's a work in progress) to circumvent the NO-USER-MODIFICATION constraint. Currently, I'm working at the Cyrus SASL side to allow backpropgtion of errors during auxprop lookup; next step will be full (well, as much as possible) password policy awareness in OpenLDAP internal and ldapdb external auxprop lookup functionalities. p. On Mon, 2006-01-02 at 17:23 +1100, Andrew Bartlett wrote: > On Tue, 2005-12-27 at 13:58 +0100, Pierangelo Masarati wrote: > > Dear all, > > > > Howard Chu and I, of the OpenLDAP Project, and Alexey Melnikov of Cyrus > > SASL have been chatting about the issues of making password-based SASL > > mechs aware and respectful of any Password Policy mechanism implemented > > at the DSA that contains the passwords, and used by the SASL mechanisms > > by way of auxprop lookup. I'll briefly summarize the private discussion > > we had, and then expose my suggestions for a possible evolution of > > draft-behera-ldap-password-policy. > > > This message should be considered a notification of the problem we're > > addressing; we're open to suggestions for different solutions. We think > > it would be important to include this further lookup-based mechanism > > into those accounted for by the LDAP password policy I.D., because it > > would broaden its application to authentication mechanisms that are > > closely related to those currently addressed. > > I'm very interested in this space, due to the poor history that Samba > has achieved in solving exactly these problems in the past. As I > develop Samba4 and it's LDAP server, I would like to move to better and > more standards-based solutions. > > In particular, I have an aim that Samba4 (an implementation of many of > the AD protocols for windows domain control, amongst other things) may > back onto an arbitrary LDAP server. This places Samba4 in the same > situation as Cyrus-SASL above. Similarly, Samba3 is already in that > situation, and performs poorly in this area. > > Firstly, I fail to see the distinction between directory authentication > and application authentication, in a well-managed solution. This will > show in the remainder of my response. > > As a history: Traditionally, Samba3 used LDAP simply as a data store, > with no reference to it for password policy, or even synchronisation. > > Before the Samba3 release, I added support to set passwords into LDAP > using the openldap password set exop (but would only read it's own > password values). Samba3 eventually gained support for reading the > Novell eDirectory universal password, and this is where the hacks really > started: > > The password is obtained with a custom exop, and to perform the second > stage (the notification of the authentication results), a *simple bind* > was returned to the server. The bind would be with the plaintext > password to indicate success (and the result checked to indicate if the > policy would allow the login), or with a random password to indicate > failure. > > While I don't expect changes in this area for Samba3 (however anything > is possible), I would really like to see a better and standards-based > way to handle this over LDAP in Samba4. I would like Cyrus-SASL (and > RADIUS servers etc) to operate in a Samba4 environment, and correctly > honour our password policy, in a standard manner. A standard policy > here would also simplify the creation of alternate KDC implementations > (which would back onto Samba4 via LDAP). > > I would also like Samba4 to use the directory policy, when it is simply > a front-end to the larger directory. > > So, I'm glad to hear that this area is being thought about by others. > One particular comment I have is that for a password change, I need to > be able to trigger what is considered by the directory to be a 'user > change' operation, but with administrative credentials. This is because > we do not get the old plaintext in the kpassswd and NTLM password change > systems. I also need to be able to return the following values > (samr.idl in samba4): > > /* password properties flags */ > const uint32 DOMAIN_PASSWORD_COMPLEX = 0x00000001; > const uint32 DOMAIN_PASSWORD_NO_ANON_CHANGE = 0x00000002; > const uint32 DOMAIN_PASSWORD_NO_CLEAR_CHANGE = 0x00000004; > const uint32 DOMAIN_PASSWORD_STORE_CLEARTEXT = 0x00000010; > const uint32 DOMAIN_REFUSE_PASSWORD_CHANGE = 0x00000020; > > typedef struct { > uint16 min_password_length; > uint16 password_history_length; > uint32 password_properties; > > /* yes, these are signed. They are in negative 100ns */ > dlong max_password_age; > dlong min_password_age; > } samr_DomInfo1; > > Andrew Bartlett > Ing. Pierangelo Masarati Responsabile Open Solution OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati@sys-net.it ------------------------------------------ _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Mon Jan 02 07:46:40 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtP5E-0004r7-8a; Mon, 02 Jan 2006 07:46:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtP5C-0004oS-QL for ldapext@megatron.ietf.org; Mon, 02 Jan 2006 07:46:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24290 for ; Mon, 2 Jan 2006 07:45:26 -0500 (EST) Received: from dp.samba.org ([66.70.73.150] helo=lists.samba.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtPAG-00078m-FQ for ldapext@ietf.org; Mon, 02 Jan 2006 07:51:53 -0500 Received: from localhost.localdomain (localhost [127.0.0.1]) by lists.samba.org (Postfix) with ESMTP id 4C36616381D; Mon, 2 Jan 2006 12:46:31 +0000 (GMT) Subject: Re: [ldapext] Interaction of with authentication applications From: Andrew Bartlett To: Pierangelo Masarati In-Reply-To: <1136189001.3334.14.camel@ando> References: <1135688297.3650.7.camel@ando> <1136183018.15159.78.camel@localhost.localdomain> <1136189001.3334.14.camel@ando> Date: Mon, 02 Jan 2006 23:46:29 +1100 Message-Id: <1136205989.15159.86.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: Alexey Melnikov , 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="===============0226712630==" Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org --===============0226712630== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-KO1u62n4RWPuM6qSvunJ" --=-KO1u62n4RWPuM6qSvunJ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2006-01-02 at 09:03 +0100, Pierangelo Masarati wrote: > Andrew, >=20 > without getting too much into the details of your message, what you > describe sounds quite close to what I mean. The point is that the > draft-behera-ldap-password-policy is essentially intended for a simple >=20 > client <-> server >=20 > relationship, and there seems to be no intention to broaden it to > generic password policy (which I understand, because if it needs to > account for all the different needs it could become obfuscate and nearly > unusable). >=20 > When speaking about application authentication, I mean something like >=20 > client <-> { application <-> DSA } >=20 > where the application authenticates the client using services stored on > the DSA server, including the password and the password policy. The > policy could still apply if you see the whole from the client's > perspective, but now the server doesn't get a simple bind but rather an > auxprop lookup, as in general we cannot turn generic password-based > authentications into simple binds. =20 The other reason we should consider this area as closely tied to the client <-> server exchange is the number of applications that still do 'ldap authentication' by simple binds... > So if we still want to apply the > password policy, using the facilities provided by the DSA, the > responsibility has to move to the application. Technically, this has to > result in a code duplication which, IMHO, could be eliminated by > providing some cooperation means between the application and the server. > With OpenLDAP, for example, we can circumvent this by moving password > policy enforcement into the app (in this case Cyrus SASL, but I guess it > would be essentially the same with Samba 3, as far as I know of it). > Then, the administrative operations related to storing policy info into > the DSA would be performed as regular modify, with a privileged > identity, and with the manageDIT control (undocumented, I know; it's a > work in progress) to circumvent the NO-USER-MODIFICATION constraint. I'm unclear why we are doing modifies here. While a complete hack, the Novell eDirectory with Samba3 approach is I believe instructive. I just want a standards-based way to do it. For logins:=20 The password should be fetched, and a password compare done. =20 A message should be sent to the server indicating:=20 - success/failure - source IP - other details (such as the NTLM 'workstation name') The server should handle all the modifies, I think. For password changes: The existing password change exop, but with clear info on failures. This should set all hash types etc. I don't actually see where the manageDIT modify would come into it. The other point to consider is that any change should easily hook into the code for the server-only policy > Currently, I'm working at the Cyrus SASL side to allow backpropgtion of > errors during auxprop lookup; next step will be full (well, as much as > possible) password policy awareness in OpenLDAP internal and ldapdb > external auxprop lookup functionalities. If the hooks do look like what I suggest above, then we might even get Samba3 along for this, because the internal APIs already exist for the eDirectory case. Andrew Bartlett --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Student Network Administrator, Hawker College http://hawkerc.net --=-KO1u62n4RWPuM6qSvunJ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQBDuSClz4A8Wyi0NrsRAoMDAKCUxv6lCeFZ3SJI2umtZpYFlkrOugCeKHJl sQHc5SW/s6DLSx8QN3zvVCo= =mBkw -----END PGP SIGNATURE----- --=-KO1u62n4RWPuM6qSvunJ-- --===============0226712630== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext --===============0226712630==-- From ldapext-bounces@ietf.org Mon Jan 02 08:22:29 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtPdt-0008M7-M4; Mon, 02 Jan 2006 08:22:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtPds-0008M2-Ea for ldapext@megatron.ietf.org; Mon, 02 Jan 2006 08:22:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28084 for ; Mon, 2 Jan 2006 08:21:15 -0500 (EST) Received: from ns1.sys-net.it ([194.244.21.114] helo=mail.sys-net.it) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtPiw-0008R5-24 for ldapext@ietf.org; Mon, 02 Jan 2006 08:27:43 -0500 Received: from ando.intra.sys-net.it (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 k02DLsdZ000972 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 2 Jan 2006 14:21:55 +0100 Subject: Re: [ldapext] Interaction of with authentication applications From: Pierangelo Masarati To: Andrew Bartlett In-Reply-To: <1136205989.15159.86.camel@localhost.localdomain> References: <1135688297.3650.7.camel@ando> <1136183018.15159.78.camel@localhost.localdomain> <1136189001.3334.14.camel@ando> <1136205989.15159.86.camel@localhost.localdomain> Content-Type: text/plain Date: Mon, 02 Jan 2006 14:29:00 +0100 Message-Id: <1136208540.3334.55.camel@ando> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-22) Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.1 (mail.sys-net.it [194.244.21.114]); Mon, 02 Jan 2006 14:21:55 +0100 (CET) X-SysNet-MailScanner-Information: postmaster@sys-net.it X-MailScanner-From: ando@sys-net.it X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: 7bit 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 On Mon, 2006-01-02 at 23:46 +1100, Andrew Bartlett wrote: > I'm unclear why we are doing modifies here. While a complete hack, the > Novell eDirectory with Samba3 approach is I believe instructive. I just > want a standards-based way to do it. > > For logins: > The password should be fetched, and a password compare done. ^^^ you assume every authentication can be turned in a value compare; for those cases, draft-behera is just fine, because it already accounts for compare on the pwdAttribute as an authentication method. However, there are other password-based methods that need the value, not just a yes/no. This is what I'm discussing, and that's why I need separate "lookup" and "done" methods; that's also why my needs are currently out of the scope of draft-behera, requiring me to (re-)implement its logics in the authentication application, using hacks to update the authentication state info in the DSA. > > A message should be sent to the server indicating: > - success/failure > - source IP > - other details (such as the NTLM 'workstation name') > > The server should handle all the modifies, I think. > > For password changes: > The existing password change exop, but with clear info on failures. All you need to use is the password policy control as described in the draft; OpenLDAP already implements the server-side of ppolicy in an overlay, and the client side in the library: get libldap 2.3 and that's all. > This should set all hash types etc. Yes. > > I don't actually see where the manageDIT modify would come into it. The > other point to consider is that any change should easily hook into the > code for the server-only policy See above. > If the hooks do look like what I suggest above, then we might even get > Samba3 along for this, because the internal APIs already exist for the > eDirectory case. Well, if you're fine with LDAP compare, yes: you can definitely have it working in Samba 3, as far as I can tell. p. Ing. Pierangelo Masarati Responsabile Open Solution OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati@sys-net.it ------------------------------------------ _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Mon Jan 02 08:39:53 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtPuj-0008VK-MN; Mon, 02 Jan 2006 08:39:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtPuh-0008Tw-Fw for ldapext@megatron.ietf.org; Mon, 02 Jan 2006 08:39:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29672 for ; Mon, 2 Jan 2006 08:38:39 -0500 (EST) Received: from highlandsun.propagation.net ([66.221.212.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtPzl-0000SJ-T5 for ldapext@ietf.org; Mon, 02 Jan 2006 08:45:07 -0500 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 k02Ddd09017884; Mon, 2 Jan 2006 07:39:41 -0600 Message-ID: <43B92D17.1040800@highlandsun.com> Date: Mon, 02 Jan 2006 05:39:35 -0800 From: Howard Chu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051221 SeaMonkey/1.5a MIME-Version: 1.0 To: Pierangelo Masarati Subject: Re: [ldapext] Interaction of with authentication applications References: <1135688297.3650.7.camel@ando> <1136183018.15159.78.camel@localhost.localdomain> <1136189001.3334.14.camel@ando> <1136205989.15159.86.camel@localhost.localdomain> <1136208540.3334.55.camel@ando> In-Reply-To: <1136208540.3334.55.camel@ando> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: ldapext@ietf.org, Andrew Bartlett 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 Pierangelo Masarati wrote: > ^^^ you assume every authentication can be turned in a value compare; > for those cases, draft-behera is just fine, because it already accounts > for compare on the pwdAttribute as an authentication method. However, > there are other password-based methods that need the value, not just a > yes/no. This is what I'm discussing, and that's why I need separate > "lookup" and "done" methods; that's also why my needs are currently out > of the scope of draft-behera, requiring me to (re-)implement its logics > in the authentication application, using hacks to update the > authentication state info in the DSA. As suggested, you could use a regular Bind operation to update the authentication state in the auxprop "done" method. As long as the done method is called in all cases, the lookup method doesn't need to trigger any updates, and the only extension we need is to define the ppolicy control behavior when accompanying a Search. I think this is a relatively benign change and ought to be rolled into draft-behera; it is at least as relevant as the current support for Compare operations. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/ _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Mon Jan 02 08:47:16 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtQ1s-0003Xk-Qn; Mon, 02 Jan 2006 08:47:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtQ1r-0003Ua-2y for ldapext@megatron.ietf.org; Mon, 02 Jan 2006 08:47:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00422 for ; Mon, 2 Jan 2006 08:46:02 -0500 (EST) Received: from ns1.sys-net.it ([194.244.21.114] helo=mail.sys-net.it) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtQ6w-0000hJ-EB for ldapext@ietf.org; Mon, 02 Jan 2006 08:52:30 -0500 Received: from ando.intra.sys-net.it (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 k02Dkbr8002711 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 2 Jan 2006 14:46:37 +0100 Subject: Re: [ldapext] Interaction of with authentication applications From: Pierangelo Masarati To: Howard Chu In-Reply-To: <43B92D17.1040800@highlandsun.com> References: <1135688297.3650.7.camel@ando> <1136183018.15159.78.camel@localhost.localdomain> <1136189001.3334.14.camel@ando> <1136205989.15159.86.camel@localhost.localdomain> <1136208540.3334.55.camel@ando> <43B92D17.1040800@highlandsun.com> Content-Type: text/plain Date: Mon, 02 Jan 2006 14:53:42 +0100 Message-Id: <1136210022.3334.61.camel@ando> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-22) Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.1 (mail.sys-net.it [194.244.21.114]); Mon, 02 Jan 2006 14:46:38 +0100 (CET) X-SysNet-MailScanner-Information: postmaster@sys-net.it X-MailScanner-From: ando@sys-net.it X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Cc: ldapext@ietf.org, Andrew Bartlett 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 On Mon, 2006-01-02 at 05:39 -0800, Howard Chu wrote: > As suggested, you could use a regular Bind operation to update the > authentication state in the auxprop "done" method. As long as the done > method is called in all cases, the lookup method doesn't need to trigger > any updates, and the only extension we need is to define the ppolicy > control behavior when accompanying a Search. I think this is a > relatively benign change and ought to be rolled into draft-behera; it is > at least as relevant as the current support for Compare operations. My point is: what if we lookup auxprops non in cleartext? But I fear the answer would be: use a Compare instead of a Bind... p. Ing. Pierangelo Masarati Responsabile Open Solution OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati@sys-net.it ------------------------------------------ _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Mon Jan 02 16:58:34 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtXhJ-00073R-V9; Mon, 02 Jan 2006 16:58:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtXhI-00071a-GU for ldapext@megatron.ietf.org; Mon, 02 Jan 2006 16:58:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19898 for ; Mon, 2 Jan 2006 16:57:18 -0500 (EST) Received: from dp.samba.org ([66.70.73.150] helo=lists.samba.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtXmQ-00070l-3h for ldapext@ietf.org; Mon, 02 Jan 2006 17:03:52 -0500 Received: from localhost.localdomain (localhost [127.0.0.1]) by lists.samba.org (Postfix) with ESMTP id 58C8D162B74; Mon, 2 Jan 2006 21:58:24 +0000 (GMT) Subject: Re: [ldapext] Interaction of with authentication applications From: Andrew Bartlett To: Pierangelo Masarati In-Reply-To: <1136208540.3334.55.camel@ando> References: <1135688297.3650.7.camel@ando> <1136183018.15159.78.camel@localhost.localdomain> <1136189001.3334.14.camel@ando> <1136205989.15159.86.camel@localhost.localdomain> <1136208540.3334.55.camel@ando> Date: Tue, 03 Jan 2006 08:58:21 +1100 Message-Id: <1136239101.15159.95.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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="===============2083412561==" Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org --===============2083412561== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-8WjQ3T1cjFf/7oDRhrJI" --=-8WjQ3T1cjFf/7oDRhrJI Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2006-01-02 at 14:29 +0100, Pierangelo Masarati wrote: > On Mon, 2006-01-02 at 23:46 +1100, Andrew Bartlett wrote: >=20 > > I'm unclear why we are doing modifies here. While a complete hack, the > > Novell eDirectory with Samba3 approach is I believe instructive. I jus= t > > want a standards-based way to do it. > >=20 > > For logins:=20 > > The password should be fetched, and a password compare done. =20 >=20 > ^^^ you assume every authentication can be turned in a value compare; Oh, I was a bit sloppy with my language. I meant a comparison of the challenge-response result in Samba, not an LDAP compare operation. Andrew Bartlett --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Student Network Administrator, Hawker College http://hawkerc.net --=-8WjQ3T1cjFf/7oDRhrJI Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQBDuaH9z4A8Wyi0NrsRAqybAJ9blnUdcTrIuDnWbcqaV36pR7GuOQCdGY/j EloxwE7MCIHMvddQ1i90rRo= =wZIv -----END PGP SIGNATURE----- --=-8WjQ3T1cjFf/7oDRhrJI-- --===============2083412561== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext --===============2083412561==-- From ldapext-bounces@ietf.org Wed Jan 04 08:00:03 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eu8FH-0007Ha-GT; Wed, 04 Jan 2006 08:00:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eu8FE-0007H1-FN for ldapext@megatron.ietf.org; Wed, 04 Jan 2006 08:00:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26131 for ; Wed, 4 Jan 2006 07:58:45 -0500 (EST) Received: from dp.samba.org ([66.70.73.150] helo=lists.samba.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eu8Kh-00077A-GF for ldapext@ietf.org; Wed, 04 Jan 2006 08:05:40 -0500 Received: from localhost.localdomain (localhost [127.0.0.1]) by lists.samba.org (Postfix) with ESMTP id C9C911638AD; Wed, 4 Jan 2006 12:59:52 +0000 (GMT) Subject: Re: [ldapext] Interaction of with authentication applications From: Andrew Bartlett To: Howard Chu In-Reply-To: <43B92D17.1040800@highlandsun.com> References: <1135688297.3650.7.camel@ando> <1136183018.15159.78.camel@localhost.localdomain> <1136189001.3334.14.camel@ando> <1136205989.15159.86.camel@localhost.localdomain> <1136208540.3334.55.camel@ando> <43B92D17.1040800@highlandsun.com> Date: Wed, 04 Jan 2006 23:59:51 +1100 Message-Id: <1136379591.15159.179.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 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="===============1150763594==" Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org --===============1150763594== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-2ImBcJ0I5m5Qi+ajvuhI" --=-2ImBcJ0I5m5Qi+ajvuhI Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2006-01-02 at 05:39 -0800, Howard Chu wrote: > Pierangelo Masarati wrote: > > ^^^ you assume every authentication can be turned in a value compare; > > for those cases, draft-behera is just fine, because it already accounts > > for compare on the pwdAttribute as an authentication method. However, > > there are other password-based methods that need the value, not just a > > yes/no. This is what I'm discussing, and that's why I need separate > > "lookup" and "done" methods; that's also why my needs are currently out > > of the scope of draft-behera, requiring me to (re-)implement its logics > > in the authentication application, using hacks to update the > > authentication state info in the DSA. >=20 > As suggested, you could use a regular Bind operation to update the=20 > authentication state in the auxprop "done" method. As long as the done=20 > method is called in all cases, the lookup method doesn't need to trigger=20 > any updates, and the only extension we need is to define the ppolicy=20 > control behavior when accompanying a Search. I think this is a=20 > relatively benign change and ought to be rolled into draft-behera; it is=20 > at least as relevant as the current support for Compare operations. But how should this be handled if we don't store the plaintext. I realise this isn't where Cyrus-SASL is heading, but Samba traditionally only stores the NT and LM hashes. For the Samba4 work, storage of what windows calls the 'reversibly encrypted password' is optional, and I would hate for LDAP-based password policy to rely on it. Also, how could I attach (to the bind operation for updating/validation of the policy) the IP the user authenticated from (and other such details)?=20 Andrew Bartlett --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Student Network Administrator, Hawker College http://hawkerc.net --=-2ImBcJ0I5m5Qi+ajvuhI Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQBDu8bGz4A8Wyi0NrsRAgdQAKCVtBIkFOH1+5fjgwi71AvKzu/NygCfSRqm ICpMQI5jFlq5lNEplE4TRTI= =5GL7 -----END PGP SIGNATURE----- --=-2ImBcJ0I5m5Qi+ajvuhI-- --===============1150763594== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext --===============1150763594==-- From ldapext-bounces@ietf.org Wed Jan 04 22:51:09 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuM9d-00030C-GW; Wed, 04 Jan 2006 22:51:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuM9Y-0002zP-OI for ldapext@megatron.ietf.org; Wed, 04 Jan 2006 22:51:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14454 for ; Wed, 4 Jan 2006 22:49:50 -0500 (EST) Received: from highlandsun.propagation.net ([66.221.212.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuMF9-0007zO-5G for ldapext@ietf.org; Wed, 04 Jan 2006 22:56:52 -0500 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 k053ojQu025279; Wed, 4 Jan 2006 21:50:46 -0600 Message-ID: <43BC979D.3020904@highlandsun.com> Date: Wed, 04 Jan 2006 19:50:53 -0800 From: Howard Chu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051221 SeaMonkey/1.5a Mnenhy/0.7.3.0 MIME-Version: 1.0 To: Andrew Bartlett Subject: Re: [ldapext] Interaction of with authentication applications References: <1135688297.3650.7.camel@ando> <1136183018.15159.78.camel@localhost.localdomain> <1136189001.3334.14.camel@ando> <1136205989.15159.86.camel@localhost.localdomain> <1136208540.3334.55.camel@ando> <43B92D17.1040800@highlandsun.com> <1136379591.15159.179.camel@localhost.localdomain> In-Reply-To: <1136379591.15159.179.camel@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit 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 Andrew Bartlett wrote: > On Mon, 2006-01-02 at 05:39 -0800, Howard Chu wrote: >> As suggested, you could use a regular Bind operation to update the >> authentication state in the auxprop "done" method. As long as the done >> method is called in all cases, the lookup method doesn't need to trigger >> any updates, and the only extension we need is to define the ppolicy >> control behavior when accompanying a Search. I think this is a >> relatively benign change and ought to be rolled into draft-behera; it is >> at least as relevant as the current support for Compare operations. > > But how should this be handled if we don't store the plaintext. I > realise this isn't where Cyrus-SASL is heading, but Samba traditionally > only stores the NT and LM hashes. For the Samba4 work, storage of what > windows calls the 'reversibly encrypted password' is optional, and I > would hate for LDAP-based password policy to rely on it. The enforcement of password policy works regardless of the method/hash used to store passwords in the directory. However, for Cyrus SASL secret-based mechs, obviously we need plaintext, and password modifications must be sent to the server in plaintext. > Also, how could I attach (to the bind operation for updating/validation > of the policy) the IP the user authenticated from (and other such > details)? These are clearly application-specific issues, and it's just this sort of thing I'm sure Kurt was trying to avoid dragging into the picture. It is right and proper that draft-behera only address features and behaviors relevant to an LDAP client authenticating to an LDAP server. When the LDAP client is itself an application authenticating on behalf of some other client, you've really got a proxy situation, and that deserves its own separate consideration. Where the two situations overlap, it makes sense to me to unify them. I think there is sufficient overlap in the Cyrus SASL case. Where the two situations differ, it makes sense to isolate the differences. The password policy specification only talks about password management. A user's IP address may figure into authentication policy or more generally into access control, but that's outside the scope of a password discussion. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/ _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Fri Jan 06 16:10:08 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Euyqe-0001R4-9T; Fri, 06 Jan 2006 16:10:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Euyqb-0001Pt-At for ldapext@megatron.ietf.org; Fri, 06 Jan 2006 16:10:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11181 for ; Fri, 6 Jan 2006 16:08:47 -0500 (EST) Received: from dp.samba.org ([66.70.73.150] helo=lists.samba.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuywX-0001gP-KD for ldapext@ietf.org; Fri, 06 Jan 2006 16:16:14 -0500 Received: from localhost.localdomain (localhost [127.0.0.1]) by lists.samba.org (Postfix) with ESMTP id D0528162C1B; Fri, 6 Jan 2006 21:09:57 +0000 (GMT) Subject: Re: [ldapext] Interaction of with authentication applications From: Andrew Bartlett To: Howard Chu In-Reply-To: <43BC979D.3020904@highlandsun.com> References: <1135688297.3650.7.camel@ando> <1136183018.15159.78.camel@localhost.localdomain> <1136189001.3334.14.camel@ando> <1136205989.15159.86.camel@localhost.localdomain> <1136208540.3334.55.camel@ando> <43B92D17.1040800@highlandsun.com> <1136379591.15159.179.camel@localhost.localdomain> <43BC979D.3020904@highlandsun.com> Date: Sat, 07 Jan 2006 08:09:56 +1100 Message-Id: <1136581796.15159.364.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 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="===============1320919202==" Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org --===============1320919202== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-x+egH2kOfroXs/AH7+rN" --=-x+egH2kOfroXs/AH7+rN Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2006-01-04 at 19:50 -0800, Howard Chu wrote: > Where the two situations overlap, it makes sense to me to unify them. I=20 > think there is sufficient overlap in the Cyrus SASL case. Where the two=20 > situations differ, it makes sense to isolate the differences. The=20 > password policy specification only talks about password management. A=20 > user's IP address may figure into authentication policy or more=20 > generally into access control, but that's outside the scope of a=20 > password discussion. I've been looking at the spec again, from the password management angle. I understand the intent to limit the scope here. What I'm worried about is again an application proxy issue, but more limited: Strictly within the password management space, I want to communicate to the back end the difference between: - user changes their password=20 - administrator changes a user's password (but must follow some restrictions) - big hammer (I am going to set 'cat' and you shouldn't stop me...) I need that in Samba4 (and indeed the first 2 in Samba3), if we are to have the directory enforce the password policies. However, in all cases the bind occurs as an administrative user, as we never get the user's cleartext in these protocols. I presume the big hammer matches up with ManageDIT? Could we add a control to advise the backend of the other details? =20 Andrew Bartlett --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Student Network Administrator, Hawker College http://hawkerc.net --=-x+egH2kOfroXs/AH7+rN Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQBDvtykz4A8Wyi0NrsRAop6AJ9QL+0ukS8AxdPK6JOmAP3xYoSSqgCfRj/S 25dNVAekMnF6tsPg33NEOsk= =KGqb -----END PGP SIGNATURE----- --=-x+egH2kOfroXs/AH7+rN-- --===============1320919202== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext --===============1320919202==-- From ldapext-bounces@ietf.org Mon Jan 09 10:00:42 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvyVm-00081M-6v; Mon, 09 Jan 2006 10:00:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvyVj-00081H-Nn for ldapext@megatron.ietf.org; Mon, 09 Jan 2006 10:00:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19960 for ; Mon, 9 Jan 2006 09:59:21 -0500 (EST) Received: from e3.ny.us.ibm.com ([32.97.182.143]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EvycC-0007FM-U4 for ldapext@ietf.org; Mon, 09 Jan 2006 10:07:24 -0500 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e3.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id k09F0HOc017795 for ; Mon, 9 Jan 2006 10:00:17 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id k09F0Hku126746 for ; Mon, 9 Jan 2006 10:00:17 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.13.3) with ESMTP id k09F0H00014354 for ; Mon, 9 Jan 2006 10:00:17 -0500 Received: from d27ml001.rchland.ibm.com (d27ml001.rchland.ibm.com [9.10.229.77]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id k09F0GiE014337 for ; Mon, 9 Jan 2006 10:00:16 -0500 In-Reply-To: <1136581796.15159.364.camel@localhost.localdomain> To: ldapext@ietf.org Subject: Re: [ldapext] Interaction of with authentication applications MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF85 November 04, 2005 From: John McMeeking Message-ID: Date: Mon, 9 Jan 2006 09:00:15 -0600 X-MIMETrack: Serialize by Router on d27ml001/27/M/IBM(Release 7.0|August 18, 2005) at 01/09/2006 09:00:16 AM, Serialize complete at 01/09/2006 09:00:16 AM X-Spam-Score: 1.8 (+) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a 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="===============0186590533==" Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org --===============0186590533== Content-Type: text/html; charset="US-ASCII"
Setting aside the question of what draft might address this, it looks like there are two things (at least) to address:

1.  Proxied binds, where the server provides a password but doesn't receive a bind request (or even compare).  An application performs authentication after using search to retreive the password.
2.  Proxied password changes, where the server stores the password but an application changes the password on behalf of a user.

I assume the password is shared with other applications or LDAP clients, otherwise there's really no need to have LDAP password policy at all; you just need a schema.

For the proxied bind case, I think an extended request would be appropriate.  There was some mention of changes to search.  Unless I missed the point, it seems like that would require two searches - one to retrieve the password and account status, a second to somehow indicate bind success or failure.  That seems like inappropiate use of a search control.  The extended request value could contain an entry DN and an indication of whether the bind was successful or not.  The server would update the password policy state accordingly.  I agree that items like clients IP address would be outside the scope of this discussion.

For the proxied password change, I think you'd want a control attached to the modify request (or the password change extended request).  As I read it, the existing password policy acknowledges a two kinds of password changes:
1.  changing your own password
2.  changing someone else's password

As you suggested, one could define a control to cover the first case. I don't think the control needs any value, just the presence of the control to tell the server to act like this is a password change from the client.  At that, the LDAP Proxied Authorization Control (draft-weltman-ldapv3-proxy-xx) might also work, though it carries a lot more function with it unless the server implementation is restricted to just this use.

For the second case, I don't think we need to define anything extra.  It seems to me this falls cleanly into the category of changing someone else's password and should be covered by the password policy draft.  Your note suggests there might be some holes in password policy draft - different flavors of administrative password changes - and I don't know if the existing draft meets your needs there.


John  McMeeking

ldapext-bounces@ietf.org wrote on 01/06/2006 03:09:56 PM:

> On Wed, 2006-01-04 at 19:50 -0800, Howard Chu wrote:
>
> > Where the two situations overlap, it makes sense to me to unify them. I
> > think there is sufficient overlap in the Cyrus SASL case. Where the two
> > situations differ, it makes sense to isolate the differences. The
> > password policy specification only talks about password management. A
> > user's IP address may figure into authentication policy or more
> > generally into access control, but that's outside the scope of a
> > password discussion.
>
> I've been looking at the spec again, from the password management angle.
> I understand the intent to limit the scope here.
>
> What I'm worried about is again an application proxy issue, but more
> limited:  Strictly within the password management space, I want to
> communicate to the back end the difference between:
>
>  - user changes their password
>  - administrator changes a user's password (but must follow some
> restrictions)
>  - big hammer (I am going to set 'cat' and you shouldn't stop me...)
>
> I need that in Samba4 (and indeed the first 2 in Samba3), if we are to
> have the directory enforce the password policies.  However, in all cases
> the bind occurs as an administrative user, as we never get the user's
> cleartext in these protocols.
>
> I presume the big hammer matches up with ManageDIT?  Could we add a
> control to advise the backend of the other details?
>  
> Andrew Bartlett
>
> --
> Andrew Bartlett                                http://samba.org/~abartlet/
> Authentication Developer, Samba Team           http://samba.org
> Student Network Administrator, Hawker College  http://hawkerc.net
> [attachment "signature.asc" deleted by John McMeeking/Rochester/IBM]
> _______________________________________________
> Ldapext mailing list
> Ldapext@ietf.org
> https://www1.ietf.org/mailman/listinfo/ldapext
 --===============0186590533== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext --===============0186590533==-- From ldapext-bounces@ietf.org Fri Jan 20 16:52:11 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F04B1-0007QI-L8; Fri, 20 Jan 2006 16:52:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F04Az-0007LL-MW for ldapext@megatron.ietf.org; Fri, 20 Jan 2006 16:52:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04329 for ; Fri, 20 Jan 2006 16:50:38 -0500 (EST) Received: from boole.openldap.org ([204.152.186.50] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F04Jj-0000Cr-VW for ldapext@ietf.org; Fri, 20 Jan 2006 17:01:13 -0500 Received: from gyspy.OpenLDAP.org (24-205-218-53.dhcp.crcy.nv.charter.com [24.205.218.53] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.13.3/8.13.3) with ESMTP id k0KLpnDG043928 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 20 Jan 2006 21:51:49 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <7.0.0.16.0.20060120132200.0223e9a8@OpenLDAP.org> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Fri, 20 Jan 2006 13:51:25 -0800 To: ldapext@ietf.org From: "Kurt D. Zeilenga" In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Subject: [ldapext] Re: I-D ACTION:draft-furuseth-ldap-untypedobject-01.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: , Sender: ldapext-bounces@ietf.org Errors-To: ldapext-bounces@ietf.org I don't see way this class would have any MUST/MAY attributes (other than 'objectClass' as required by the SUP top). It seems that it would be more appropriate to use DIT content rules/auxiliary object classes (including possibly extensibleObject) to require/allow any desired attributes, including those used for naming. I don't like the name of this class, but the alternatives don't seem much better (if better at all), 'unclassifiedObject', 'structurallessObject', 'unstructuredObject' (at present, I prefer the latter). A few misc. comments (mostly editorial, but some of substance). Reference the revised LDAP TS instead of RFC 3377 for LDAP (its nearly all approved now). s/'natural'/natural/ so as not to be confused to be an descriptor Second paragraph of 1 is not only oddly formated, but oddly worded. Unclear whether [LDAP-NIS] refers to the revised NIS/LDAP specification or RFC 2307. One or the other please. The example should include the LDIF for an object of this class. "This document raises no known security issues." Well, given RFC 2256 discussions security considerations for attributes such as CN, I would think there are known security issues impacting this specification. And even if you were to removal all attributes from the class, there would likely still be some generally applicable considerations worthy of mention. I suggest the authors read Section 7 of draft-zeilenga-ldap-ext and attempt to satisfy its requirements/recommendations here. "[Editor: I don't know if last sentence is necessary.]" It's not. And the OID assigned would not be 1.3.6.1.1, but some OID under 1.3.6.1.1. The sentence and note should be deleted. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Fri Jan 20 20:22:13 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F07SH-0004Eo-Un; Fri, 20 Jan 2006 20:22:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F07SF-0004Dh-Cv for ldapext@megatron.ietf.org; Fri, 20 Jan 2006 20:22:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18536 for ; Fri, 20 Jan 2006 20:20:44 -0500 (EST) Received: from pat.uio.no ([129.240.130.16] ident=7411) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F07b5-0006UW-68 for ldapext@ietf.org; Fri, 20 Jan 2006 20:31:19 -0500 Received: from mail-mx7.uio.no ([129.240.10.52]) by pat.uio.no with esmtp (Exim 4.43) id 1F07S6-0004hQ-Em; Sat, 21 Jan 2006 02:22:02 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx7.uio.no with esmtp (Exim 4.43) id 1F07S4-0006yT-F6; Sat, 21 Jan 2006 02:22:00 +0100 Received: from hbf by bombur.uio.no with local (Exim 4.44) id 1F07S4-0003XC-Dt; Sat, 21 Jan 2006 02:22:00 +0100 From: Hallvard B Furuseth MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: Date: Sat, 21 Jan 2006 02:22:00 +0100 To: "Kurt D. Zeilenga" Subject: Re: [ldapext] Re: I-D ACTION:draft-furuseth-ldap-untypedobject-01.txt In-Reply-To: <7.0.0.16.0.20060120132200.0223e9a8@OpenLDAP.org> References: <7.0.0.16.0.20060120132200.0223e9a8@OpenLDAP.org> X-Mailer: VM 7.18 under Emacs 21.4.1 X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, autolearn=disabled, UIO_MAIL_IS_INTERNAL -5.00) X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit 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 Kurt D. Zeilenga writes: > I don't see way this class would have any MUST/MAY attributes > (other than 'objectClass' as required by the SUP top). Well, the rationale is in Appendix A, except: > It seems that it would be more appropriate to use DIT content > rules/auxiliary object classes (including possibly extensibleObject) > to require/allow any desired attributes, including those used for > naming. I don't get this. Plenty of other object classes can be used for a number of different scenarios and provide a bunch of attributes that just might be useful, e.g. the MAY attributes to 'person'. That's partly what MAY is for in the first place. How is this different? The major thing wrong I can see with this class is that it must be structural but doesn't really deserve to be, not which attributes it has. And quite possibly it has too many naming attributes. I can see moving the other naming attrs than CN to an aux class which would also be defined in the draft. extensibleObject and DIT content rules may both be unsupported. But it might be an idea to suggest them in the draft, in particular if most/all attributes are deleted. > I don't like the name of this class, but the alternatives don't seem > much better (if better at all), 'unclassifiedObject', > 'structurallessObject', 'unstructuredObject' (at present, I prefer the > latter). Yeah, they are all equally bad:-( I could go for either. structurallessObject... hmm, it sounded absolutely wrong at first glance, but maybe not... Or namedObject, which this version of the draft steals some text from. Don't know where the namedObject draft is going or if this would be OK with the author of that one. > A few misc. comments (mostly editorial, but some of > substance). Leaving most for Alexey. > "This document raises no known security issues." > Well, given RFC 2256 discussions security considerations > for attributes such as CN, I would think there are > known security issues impacting this specification. > (...) I suggest > the authors read Section 7 of draft-zeilenga-ldap-ext > and attempt to satisfy its requirements/recommendations > here. Good tip. BTW, sorry about dropping this draft some time ago. Alexey picked it up again. -- Hallvard _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Sun Jan 22 18:45:51 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0ou7-0006r6-Sk; Sun, 22 Jan 2006 18:45:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0ou6-0006oG-Au for ldapext@megatron.ietf.org; Sun, 22 Jan 2006 18:45:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27561 for ; Sun, 22 Jan 2006 18:44:20 -0500 (EST) Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F0p3F-0008OM-HS for ldapext@ietf.org; Sun, 22 Jan 2006 18:55:23 -0500 Received: from [10.40.68.80] ([219.238.46.67]) by rufus.isode.com via TCP (submission) with ESMTPA; Sun, 22 Jan 2006 23:45:13 +0000 Message-ID: <43D418FD.7010309@isode.com> Date: Sun, 22 Jan 2006 23:45:01 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hallvard B Furuseth Subject: Re: [ldapext] Re: I-D ACTION:draft-furuseth-ldap-untypedobject-01.txt References: <7.0.0.16.0.20060120132200.0223e9a8@OpenLDAP.org> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: 7bit Cc: ldapext@ietf.org, "Kurt D. Zeilenga" 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 Hallvard B Furuseth wrote: >Kurt D. Zeilenga writes: > > >>I don't see way this class would have any MUST/MAY attributes >>(other than 'objectClass' as required by the SUP top). >> >> > >Well, the rationale is in Appendix A, except: > > >>It seems that it would be more appropriate to use DIT content >>rules/auxiliary object classes (including possibly extensibleObject) >>to require/allow any desired attributes, including those used for >>naming. >> >> > >I don't get this. Plenty of other object classes can be used for a >number of different scenarios and provide a bunch of attributes that >just might be useful, e.g. the MAY attributes to 'person'. That's >partly what MAY is for in the first place. How is this different? >The major thing wrong I can see with this class is that it must be >structural but doesn't really deserve to be, not which attributes it >has. > >And quite possibly it has too many naming attributes. I can see >moving the other naming attrs than CN to an aux class which would >also be defined in the draft. > > For the purposes I use this Object Class in Isode software I need cn, uid and dc. The description attribute seems to be a good idea for describing why an entry of this class is present in DIT. I don't have strong opinion about other attributes. >extensibleObject and DIT content rules may both be unsupported. > > Right. >But it might be an idea to suggest them in the draft, in particular >if most/all attributes are deleted. > > >>I don't like the name of this class, but the alternatives don't seem >>much better (if better at all), 'unclassifiedObject', >>'structurallessObject', 'unstructuredObject' (at present, I prefer the >>latter). >> >> > >Yeah, they are all equally bad:-( I could go for either. > >structurallessObject... hmm, it sounded absolutely wrong at first >glance, but maybe not... > > I like the name Container, which is used by Microsoft AD for similar purposes. >Or namedObject, which this version of the draft steals some text from. >Don't know where the namedObject draft is going or if this would be OK >with the author of that one. > > I think Luke Howard has agreed to my idea of having a single merged draft. >>A few misc. comments (mostly editorial, but some of >>substance). >> >> > >Leaving most for Alexey. > > Yes, comments look straightforward. >> "This document raises no known security issues." >> Well, given RFC 2256 discussions security considerations >> for attributes such as CN, I would think there are >> known security issues impacting this specification. >> (...) I suggest >> the authors read Section 7 of draft-zeilenga-ldap-ext >> and attempt to satisfy its requirements/recommendations >> here. >> >> > >Good tip. > > Ok, I will think about Security Considerations for the next revision. Alexey _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Mon Jan 23 15:01:35 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F17sd-0007ZD-BD; Mon, 23 Jan 2006 15:01:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F17sc-0007Yz-Mz; Mon, 23 Jan 2006 15:01:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13776; Mon, 23 Jan 2006 15:00:04 -0500 (EST) Received: from boole.openldap.org ([204.152.186.50] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1821-0002HF-25; Mon, 23 Jan 2006 15:11:18 -0500 Received: from gyspy.OpenLDAP.org (24-205-218-53.dhcp.crcy.nv.charter.com [24.205.218.53] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.13.3/8.13.3) with ESMTP id k0NK1Qi5091902 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Jan 2006 20:01:26 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <7.0.0.16.0.20060123115156.0226d6d0@OpenLDAP.org> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Mon, 23 Jan 2006 12:00:59 -0800 To: ldapext@ietf.org From: "Kurt D. Zeilenga" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: directory@apps.ietf.org Subject: [ldapext] Open meeting of the Directory Directory (tentative) 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 I have requested a session slot at IETF#65 to hold an open meeting of the directory directorate. As discussed at IETF#64, the purpose of this meeting would be discuss on-going and future directory standardization efforts, namely LDAP extensions such as LDAP Distributed Operations (chaining). Below is the basic agenda I proposed. Thoughts on additional topics welcomed. (I note that a 1 hour session was initially requested, if it becomes clear we need more time, I'll amend the request). (Note: while I've bcc'ed this to the directory directorate mailing list, as that list has a restricted membership, and this session is intended to be open, discussion should take place on the ldapext list.) Regards, Kurt Open Meeting of the IETF Directory Directorate Session Chair: Kurt Zeilenga Purpose: Discuss on-going directory standardization work, namely LDAP extension work. 0) Preliminaries 1) Introduction 2) Discussion of on-going directory standardization efforts a) Distributed Operations (Chaining) b) Other 3) Open Mic 4) Next Steps _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Tue Jan 24 01:41:00 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1HrQ-0004hn-NJ; Tue, 24 Jan 2006 01:41:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1Hr1-0004VS-1T for ldapext@megatron.ietf.org; Tue, 24 Jan 2006 01:40:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12479 for ; Tue, 24 Jan 2006 01:39:02 -0500 (EST) Received: from boole.openldap.org ([204.152.186.50] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1I0T-0004D0-Ey for ldapext@ietf.org; Tue, 24 Jan 2006 01:50:22 -0500 Received: from gyspy.OpenLDAP.org (24-205-218-53.dhcp.crcy.nv.charter.com [24.205.218.53] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.13.3/8.13.3) with ESMTP id k0O6eLhT015561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Jan 2006 06:40:22 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <7.0.0.16.0.20060123213208.0393f0f0@OpenLDAP.org> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Mon, 23 Jan 2006 22:39:52 -0800 To: Alexey Melnikov From: "Kurt D. Zeilenga" Subject: Re: [ldapext] Re: I-D ACTION:draft-furuseth-ldap-untypedobject-01.txt In-Reply-To: <43D418FD.7010309@isode.com> References: <7.0.0.16.0.20060120132200.0223e9a8@OpenLDAP.org> <43D418FD.7010309@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.1 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Cc: Hallvard B Furuseth , 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 At 03:45 PM 1/22/2006, Alexey Melnikov wrote: >Hallvard B Furuseth wrote: >>Kurt D. Zeilenga writes: >>>I don't see way this class would have any MUST/MAY attributes >>>(other than 'objectClass' as required by the SUP top). >>> >>Well, the rationale is in Appendix A, except: Yes, I just don't agree with the rationale. I would rather the class be defined not to allow any attribute that if present, irregardless of value, be indicative of a particular type of object. That is, the allowed attributes should not 'type' the untyped object. For instance, the presence of 'dc' implies the object can be typed as being domain related. You note this in the I-D: Use of the [other attributes] may be an indication that the entry should have a more descriptive object class instead of or in addition to this one. But I note that as attributes used for naming are also descriptive of the object, your note should not only apply to "[other attributes]", but to all attributes of the class. Even presence of cn can be viewed as typing the object as being 'named'. Instead of dividing the class by presence of cn, I rather do this by class, either have namedObject & unnamedObject structural classes, or untypedObject structrual class and a cnObject auxiliary class. And given that same applies many of the other attributes (e.g., (dc=*) => object is domain related)), the latter is the better choice. That is, I think it would be better to have ( 1.1.1 NAME 'untyped' ) and a set of appropriate AUXILIARY classes for naming and other uses (such as allowing/requiring attributes which divide the class). I'm not even convinced that description, seeAlso, and owner don't divide the class and might be better brought in by auxiliary classes, describedObject, relatedObject, ownedObject. It seems this is more consistent with (my perception of) the use model for the untypedObject class. The use model seems that objects of this class should belong to some number of auxiliary classes. This number should be non-zero. >>>It seems that it would be more appropriate to use DIT content >>>rules/auxiliary object classes (including possibly extensibleObject) >>>to require/allow any desired attributes, including those used for >>>naming. >>> >> >>I don't get this. Plenty of other object classes can be used for a >>number of different scenarios and provide a bunch of attributes that >>just might be useful, e.g. the MAY attributes to 'person'. That's >>partly what MAY is for in the first place. How is this different? >>The major thing wrong I can see with this class is that it must be >>structural but doesn't really deserve to be, not which attributes it >>has. I think its a bad idea to include attributes because they might be used in naming some objects of the class. I think its far better to use an auxiliary class or DIT content rule to allow a naming attribute other than those attributes used to represent the object. For instance, use of dcObject to allow 'dc'. >>And quite possibly it has too many naming attributes. I can see >>moving the other naming attrs than CN to an aux class which would >>also be defined in the draft. Though I think it would be better to allow no attributes, I could see an (untyped) object having a (common) name, uuid, and description. I could even see owner and seeAlso being generic enough for to all for a class suitable for holding any object. But userid? If the object has a user id, I would think the object represents an user entity of some sort. Adding 'uid' suggests a type of object, and hence, I think inappropriate for 'untyped' objects. Likewise for 'dc', 'l', 'o', etc.. >For the purposes I use this Object Class in Isode software I need cn, uid and dc. What need can you not fulfill by using: untypedObject+cnObject untypedObject+uidObject untypedObject+dcObject untypedObject+extensibleObject untypedObject+... untypedObject+ DIT content rule where untypedObject has no allowed attributes? >The description attribute seems to be a good idea for describing why an entry of this class is present in DIT. >I don't have strong opinion about other attributes. > >>extensibleObject and DIT content rules may both be unsupported. >> >Right. Yes, but there always regular auxiliary classes to allow in desired attributes. You can argue, I guess, that there might be implementations that don't support auxiliary object classes. There might even be such implementations (as LDAP doesn't require implementation of the X.500 schema model). But such implementations should be ignored as you are defining an X.500 schema element (for use in LDAP). >>But it might be an idea to suggest them in the draft, in particular >>if most/all attributes are deleted. >> >> >>>I don't like the name of this class, but the alternatives don't seem >>>much better (if better at all), 'unclassifiedObject', >>>'structurallessObject', 'unstructuredObject' (at present, I prefer the >>>latter). >>> >> >>Yeah, they are all equally bad:-( I could go for either. >> >>structurallessObject... hmm, it sounded absolutely wrong at first >>glance, but maybe not... >> >I like the name Container, which is used by Microsoft AD for similar purposes. I dislike the name Container as that implies it represents objects that contain other objects. >>Or namedObject, which this version of the draft steals some text from. >>Don't know where the namedObject draft is going or if this would be OK >>with the author of that one. >> >I think Luke Howard has agreed to my idea of having a single merged draft. > >>>A few misc. comments (mostly editorial, but some of >>>substance). >>> >> >>Leaving most for Alexey. >> >Yes, comments look straightforward. > >>> "This document raises no known security issues." >>> Well, given RFC 2256 discussions security considerations >>> for attributes such as CN, I would think there are >>> known security issues impacting this specification. >>> (...) I suggest >>> the authors read Section 7 of draft-zeilenga-ldap-ext >>> and attempt to satisfy its requirements/recommendations >>> here. >>> >> >>Good tip. >> >Ok, I will think about Security Considerations for the next revision. > >Alexey > > >_______________________________________________ >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 Sun Jan 29 10:34:22 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3EZK-0007qs-T6; Sun, 29 Jan 2006 10:34:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3EZA-0007qF-EV for ldapext@megatron.ietf.org; Sun, 29 Jan 2006 10:34:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04995 for ; Sun, 29 Jan 2006 10:32:28 -0500 (EST) Received: from pat.uio.no ([129.240.130.16] ident=7411) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3EjY-0002le-0H for ldapext@ietf.org; Sun, 29 Jan 2006 10:44:58 -0500 Received: from mail-mx7.uio.no ([129.240.10.52]) by pat.uio.no with esmtp (Exim 4.43) id 1F3EYn-0000Oo-Tz; Sun, 29 Jan 2006 16:33:50 +0100 Received: from bombur.uio.no ([129.240.186.42]) by mail-mx7.uio.no with esmtp (Exim 4.43) id 1F3EYl-00053W-U7; Sun, 29 Jan 2006 16:33:47 +0100 Received: from hbf by bombur.uio.no with local (Exim 4.44) id 1F3EYl-0004ba-Sy; Sun, 29 Jan 2006 16:33:47 +0100 From: Hallvard B Furuseth MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: Date: Sun, 29 Jan 2006 16:33:47 +0100 To: "Kurt D. Zeilenga" Subject: Re: [ldapext] Re: I-D ACTION:draft-furuseth-ldap-untypedobject-01.txt In-Reply-To: <7.0.0.16.0.20060123213208.0393f0f0@OpenLDAP.org> References: <7.0.0.16.0.20060120132200.0223e9a8@OpenLDAP.org> <43D418FD.7010309@isode.com> <7.0.0.16.0.20060123213208.0393f0f0@OpenLDAP.org> X-Mailer: VM 7.18 under Emacs 21.4.1 X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, autolearn=disabled, UIO_MAIL_IS_INTERNAL -5.00) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Content-Transfer-Encoding: 7bit Cc: Alexey Melnikov , 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 OK, I finally got to this... Kurt D. Zeilenga writes: >At 03:45 PM 1/22/2006, Alexey Melnikov wrote: >>Hallvard B Furuseth wrote: >>>Kurt D. Zeilenga writes: >>>> I don't see way this class would have any MUST/MAY attributes >>>> (other than 'objectClass' as required by the SUP top). >>>> >>> Well, the rationale is in Appendix A, except: > > Yes, I just don't agree with the rationale. I would rather > the class be defined not to allow any attribute that if > present, irregardless of value, be indicative of a particular > type of object. That is, the allowed attributes should not > 'type' the untyped object. For instance, the presence of > 'dc' implies the object can be typed as being domain related. I've finally realized I left unsaid part of my own reason for including other naming attributes than "cn": 1) "ou=people", "ou=users" etc is almost a de-facto standard for "container" entries, so I wanted to support it. Just replacing the object class so a filter (objectClass=organizationalUnit) will not return ou=people, is likely a fairly small fix compared to renaming the tree to cn=people and fixing the base DN in a bunch of clients. The latter might not get done as quickly in an existing installation, if ever. Also, I have seen clients that "knew" what naming structure was used in the directory even if they didn't know the actual attribute values - like "ou" for container objects, and "o" for the top object. So if such a client happens to be the motivation for setting up a quick LDAP installation... That's a while back now though, we have mostly played with our own clients lately:-) 2) Since I included ou, it seemed reasonable to be a little consistent about it, and include other "official" naming attributes as well. While I don't know what Alexey's reasons for wanting dc and uid, I prefer to have at least "cn" and "description". Still, auxiliary classes would work fine for me as well - as long as we define and publish them. The reason ou did become widely used is probably just that there wasn't a more suitable standard class. > You note this in the I-D: > Use of the [other attributes] may be an indication that the > entry should have a more descriptive object class > instead of or in addition to this one. > > But I note that as attributes used for naming are also > descriptive of the object, your note should not only > apply to "[other attributes]", but to all attributes > of the class. Well, the attribute used for naming might just be descriptive in the sense "we once used organizationalUnit for this object, lacking a better class". > Even presence of cn can be viewed as typing the object as > being 'named'. Instead of dividing the class by presence > of cn, I rather do this by class, either have namedObject > & unnamedObject structural classes, or untypedObject structrual > class and a cnObject auxiliary class. And given that same > applies many of the other attributes (e.g., (dc=*) => object is > domain related)), the latter is the better choice. > > That is, I think it would be better to have > ( 1.1.1 NAME 'untyped' ) > and a set of appropriate AUXILIARY classes for naming > and other uses (such as allowing/requiring attributes which > divide the class). Here I disagree. One purpose of this class is to satisfy a requirement of the X.500/LDAP model, that entries need a structural class, even when there is no interesting type to assign the object. The purpose of a class with naming attributes will also be to satisfy requirements of the model, that the RDN must have an attribute and the entry must have an object class which allows that attribute. (Unless a DIT content rule is used.) In this sense, the structural class and the class which allows the naming attribute really has the same function - just to satisfy the model's reqirement. The person who inserts the attribute and the class(es) does not intend to convey anything interesting in doing so. At least with attribute "cn" or a backwards-compatibility "ou", I don't know about other cases. Why add two uninteresting classes to the entry instead of one? That said, I don't feel all that strongly about it. > I'm not even convinced that description, seeAlso, and owner > don't divide the class and might be better brought in by > auxiliary classes, describedObject, relatedObject, ownedObject. > It seems this is more consistent with (my perception of) the > use model for the untypedObject class. The use model seems > that objects of this class should belong to some number of > auxiliary classes. This number should be non-zero. Well, I disagree there too, but could go either way. Except I'm still wondering about one detail, see below:-) (..snipping, would just repeat stuff..) >> For the purposes I use this Object Class in Isode software I need cn, >> uid and dc. > > What need can you not fulfill by using: > untypedObject+cnObject > untypedObject+uidObject > untypedObject+dcObject > untypedObject+extensibleObject > untypedObject+... > untypedObject+ DIT content rule > > where untypedObject has no allowed attributes? Why a bunch of classes that just allow one attribute, instead of one that allows several - even for auxiliary classes? Same with your describedObject, relatedObject, ownedObject. In particular for this purpose - an ouObject class in the entry would actually look to someone reading the directory like intended to be informative - that the entry is some kind of organizational unit. A more general class, auxiliary or structural, would not imply that. >>>> I don't like the name of this class, but the alternatives don't >>>> seem much better (if better at all), 'unclassifiedObject', >>>> 'structurallessObject', 'unstructuredObject' (at present, I prefer >>>> the latter). >>> >>> Yeah, they are all equally bad:-( I could go for either. >>> >>> structurallessObject... hmm, it sounded absolutely wrong at first >>> glance, but maybe not... >> >> I like the name Container, which is used by Microsoft AD for similar >> purposes. > > I dislike the name Container as that implies it represents > objects that contain other objects. Metoo, though not more than the other names. I kind of like namedObject, actually. Or uninterestingObject:-) -- Hallvard _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-bounces@ietf.org Mon Jan 30 00:49:12 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3Rua-0007xO-00; Mon, 30 Jan 2006 00:49:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3RuZ-0007wx-Be for ldapext@megatron.ietf.org; Mon, 30 Jan 2006 00:49:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28313 for ; Mon, 30 Jan 2006 00:47:28 -0500 (EST) Received: from boole.openldap.org ([204.152.186.50] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3S59-0008KF-1J for ldapext@ietf.org; Mon, 30 Jan 2006 01:00:07 -0500 Received: from gyspy.OpenLDAP.org (24-205-218-53.dhcp.crcy.nv.charter.com [24.205.218.53] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.13.3/8.13.3) with ESMTP id k0U5mkHA033485 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Jan 2006 05:48:46 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <7.0.0.16.0.20060129212243.03d22148@OpenLDAP.org> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Sun, 29 Jan 2006 21:48:20 -0800 To: Hallvard B Furuseth From: "Kurt D. Zeilenga" Subject: Re: [ldapext] Re: I-D ACTION:draft-furuseth-ldap-untypedobject-01.txt In-Reply-To: References: <7.0.0.16.0.20060120132200.0223e9a8@OpenLDAP.org> <43D418FD.7010309@isode.com> <7.0.0.16.0.20060123213208.0393f0f0@OpenLDAP.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.1 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: Alexey Melnikov , 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 At 07:33 AM 1/29/2006, Hallvard B Furuseth wrote: >> That is, I think it would be better to have >> ( 1.1.1 NAME 'untyped' ) >> and a set of appropriate AUXILIARY classes for naming >> and other uses (such as allowing/requiring attributes which >> divide the class). > >Here I disagree. > >One purpose of this class is to satisfy a requirement of the X.500/LDAP >model, that entries need a structural class, even when there is no >interesting type to assign the object. That purpose is met by the above. The object has the structural class untyped. >The purpose of a class with naming attributes will also be to satisfy >requirements of the model, that the RDN must have an attribute and the >entry must have an object class which allows that attribute. Yes, but nothing in the model as that the attribute must be allowed directly by the structural object class of the attribute type. >(Unless a DIT content rule is used.) Well, since you assuming use of auxiliary classes to allow other attributes, you are (in the X.500 model) assuming use of a DIT content rule. >In this sense, the structural class and the class which allows the >naming attribute really has the same function - just to satisfy the >model's reqirement. Again, the X.500 model doesn't require the structural class to directly allow the naming attribute. The model allows these to be allowed through use of a DIT Content Rule (allowing the particular attribute, or allowing an auxiliary class that allows the attribute). >The person who inserts the attribute and the >class(es) does not intend to convey anything interesting in doing so. >At least with attribute "cn" or a backwards-compatibility "ou", I don't >know about other cases. Why add two uninteresting classes to the entry >instead of one? My understanding of your intent is to use one structural and some non-zero number of auxiliaries. If you want to make it usable without a DIT content rule (hence no additional attributes, no auxiliaries allowed), then yes you would need at least one attribute type. As I noted before, I could see allowing 'cn'... but I see no reason to add 'all common naming attributes'. >That said, I don't feel all that strongly about it. Well, as I don't intend to use this class, I certainly don't feel strongly about this either. You could say I am just playing the devil's advocate. >> I'm not even convinced that description, seeAlso, and owner >> don't divide the class and might be better brought in by >> auxiliary classes, describedObject, relatedObject, ownedObject. >> It seems this is more consistent with (my perception of) the >> use model for the untypedObject class. The use model seems >> that objects of this class should belong to some number of >> auxiliary classes. This number should be non-zero. > >Well, I disagree there too, but could go either way. Except I'm still >wondering about one detail, see below:-) > >(..snipping, would just repeat stuff..) > >>> For the purposes I use this Object Class in Isode software I need cn, >>> uid and dc. >> >> What need can you not fulfill by using: >> untypedObject+cnObject >> untypedObject+uidObject >> untypedObject+dcObject >> untypedObject+extensibleObject >> untypedObject+... >> untypedObject+ DIT content rule >> >> where untypedObject has no allowed attributes? > >Why a bunch of classes that just allow one attribute, instead of one >that allows several - even for auxiliary classes? >Same with your describedObject, relatedObject, ownedObject. Because each of these auxiliaries defines a distinct interface. Of course, if you just want to allow everything, you only need one class, it's called extensibleObject. >In particular for this purpose - an ouObject class in the entry would >actually look to someone reading the directory like intended to be >informative - that the entry is some kind of organizational unit. A >more general class, auxiliary or structural, would not imply that. > >>>>> I don't like the name of this class, but the alternatives don't >>>>> seem much better (if better at all), 'unclassifiedObject', >>>>> 'structurallessObject', 'unstructuredObject' (at present, I prefer >>>>> the latter). >>>> >>>> Yeah, they are all equally bad:-( I could go for either. >>>> >>>> structurallessObject... hmm, it sounded absolutely wrong at first >>>> glance, but maybe not... >>> >>> I like the name Container, which is used by Microsoft AD for similar >>> purposes. >> >> I dislike the name Container as that implies it represents >> objects that contain other objects. > >Metoo, though not more than the other names. > >I kind of like namedObject, actually. If you define namedObject consistent with its current use in the wild, no problem... _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext