Hi,
2010/1/15 Quanah Gibson-Mount quanah@zimbra.com
--On Friday, January 15, 2010 12:06 PM -0500 Edward Capriolo < edlinuxguru@gmail.com> wrote:
Diego,
You and I have the same issue. UID and CN are not in the schema they are compiled into LDAP some how, so there is no way to apply an ordering rule. I can not find if this is possible, or what is involved in making it happen.
I'm currently testing a quick and dirty hack that I made to servers/slapd/schema_prep.c:
--- schema_prep.c.ori 2010-01-15 13:28:04.000000000 -0200 +++ /root/openldap-2.4.21/servers/slapd/schema_prep.c 2010-01-15 13:04:56.000000000 -0200 @@ -915,6 +915,7 @@ static struct slap_schema_ad_map { offsetof(struct slap_internal_schema, si_ad_name) }, { "cn", "( 2.5.4.3 NAME ( 'cn' 'commonName' ) " "DESC 'RFC4519: common name(s) for which the entity is known by' " + "ORDERING caseIgnoreOrderingMatch " "SUP name )", NULL, 0, NULL, NULL, @@ -924,6 +925,7 @@ static struct slap_schema_ad_map { "DESC 'RFC4519: user identifier' " "EQUALITY caseIgnoreMatch " "SUBSTR caseIgnoreSubstringsMatch " + "ORDERING caseIgnoreOrderingMatch " "SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )", NULL, 0, NULL, NULL,
By making these changes I've been able to get around my current problem, but it might not be as stable as you expect.
You can find these attributes defined in the code in servers/slapd.
However, I will note, the definitions of these attributes are RFC defined. They have no ORDERING rule on purpose.
--Quanah
Thanks for the input Quanah, but the problem is we have some legacy applications that used a really old LDAP server where this was allowed. I'm trying to migrate the server (that's a fedora directory from fedora 6) to a new openldap-based one. I must, however, maintain compatibility with the existing applications.
Is there any problem (despite not being RFC-compliant) on enabling ordering on these attributes?
One problem, is that old versions did support this ordering on uid and cn. So upgrade caused something that was working to no longer function. Specifically this effect anyone using openldap as outlook 2003 address book.
Maybe there should be a configure switch here.
Edward
On Fri, Jan 15, 2010 at 1:30 PM, Diego Lima lists@diegolima.org wrote:
Hi,
2010/1/15 Quanah Gibson-Mount quanah@zimbra.com
--On Friday, January 15, 2010 12:06 PM -0500 Edward Capriolo edlinuxguru@gmail.com wrote:
Diego,
You and I have the same issue. UID and CN are not in the schema they are compiled into LDAP some how, so there is no way to apply an ordering rule. I can not find if this is possible, or what is involved in making it happen.
I'm currently testing a quick and dirty hack that I made to servers/slapd/schema_prep.c: --- schema_prep.c.ori 2010-01-15 13:28:04.000000000 -0200 +++ /root/openldap-2.4.21/servers/slapd/schema_prep.c 2010-01-15 13:04:56.000000000 -0200 @@ -915,6 +915,7 @@ static struct slap_schema_ad_map { offsetof(struct slap_internal_schema, si_ad_name) }, { "cn", "( 2.5.4.3 NAME ( 'cn' 'commonName' ) " "DESC 'RFC4519: common name(s) for which the entity is known by' "
- "ORDERING caseIgnoreOrderingMatch "
"SUP name )", NULL, 0, NULL, NULL, @@ -924,6 +925,7 @@ static struct slap_schema_ad_map { "DESC 'RFC4519: user identifier' " "EQUALITY caseIgnoreMatch " "SUBSTR caseIgnoreSubstringsMatch "
- "ORDERING caseIgnoreOrderingMatch "
"SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )", NULL, 0, NULL, NULL,
By making these changes I've been able to get around my current problem, but it might not be as stable as you expect.
You can find these attributes defined in the code in servers/slapd.
However, I will note, the definitions of these attributes are RFC defined. They have no ORDERING rule on purpose.
--Quanah
Thanks for the input Quanah, but the problem is we have some legacy applications that used a really old LDAP server where this was allowed. I'm trying to migrate the server (that's a fedora directory from fedora 6) to a new openldap-based one. I must, however, maintain compatibility with the existing applications. Is there any problem (despite not being RFC-compliant) on enabling ordering on these attributes?
-- Diego Lima
On Fri, Jan 15, 2010 at 1:30 PM, Diego Lima lists@diegolima.org wrote:
Hi,
2010/1/15 Quanah Gibson-Mount quanah@zimbra.com
--On Friday, January 15, 2010 12:06 PM -0500 Edward Capriolo edlinuxguru@gmail.com wrote:
Diego,
You and I have the same issue. UID and CN are not in the schema they are compiled into LDAP some how, so there is no way to apply an ordering rule. I can not find if this is possible, or what is involved in making it happen.
I'm currently testing a quick and dirty hack that I made to servers/slapd/schema_prep.c: --- schema_prep.c.ori 2010-01-15 13:28:04.000000000 -0200 +++ /root/openldap-2.4.21/servers/slapd/schema_prep.c 2010-01-15 13:04:56.000000000 -0200 @@ -915,6 +915,7 @@ static struct slap_schema_ad_map { offsetof(struct slap_internal_schema, si_ad_name) }, { "cn", "( 2.5.4.3 NAME ( 'cn' 'commonName' ) " "DESC 'RFC4519: common name(s) for which the entity is known by' "
- "ORDERING caseIgnoreOrderingMatch "
"SUP name )", NULL, 0, NULL, NULL, @@ -924,6 +925,7 @@ static struct slap_schema_ad_map { "DESC 'RFC4519: user identifier' " "EQUALITY caseIgnoreMatch " "SUBSTR caseIgnoreSubstringsMatch "
- "ORDERING caseIgnoreOrderingMatch "
"SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )", NULL, 0, NULL, NULL,
By making these changes I've been able to get around my current problem, but it might not be as stable as you expect.
You can find these attributes defined in the code in servers/slapd.
However, I will note, the definitions of these attributes are RFC defined. They have no ORDERING rule on purpose.
--Quanah
Thanks for the input Quanah, but the problem is we have some legacy applications that used a really old LDAP server where this was allowed. I'm trying to migrate the server (that's a fedora directory from fedora 6) to a new openldap-based one. I must, however, maintain compatibility with the existing applications. Is there any problem (despite not being RFC-compliant) on enabling ordering on these attributes?
-- Diego Lima
So I have implemented this patch.
Now my client greats me with: Unavailable critical extension I see this in the log
@400000004b5a1ea4146c62cc => get_ctrls: oid="1.2.840.113556.1.4.473" (noncritical) @400000004b5a1eb912121b34 => get_ctrls: oid="1.2.840.113556.1.4.473" (critical)
I find this as advice:
http://www.openldap.org/lists/openldap-software/200408/msg00321.html
access to dn.exact="" attrs=supportedControl val=1.2.840.113556.1.4.319 by * none
Yet this does not work:
@400000004b5a2339219ce584 /usr/local/openldap/etc/openldap/slapd.conf: line 44: attr "supportedControl" does not have an EQUALITY matching rule.
This address book thing is totally whipping my rear.
I am configured like so:
addConfOpt "--prefix=/usr/local/openldap" #base of the installation addConfOpt "--enable-debug=yes" addConfOpt "--enable-ip6=no" addConfOpt "--enable-crypt=yes" addConfOpt "--enable-wrapper=yes" addConfOpt "--enable-module=yes" addConfOpt "--enable-bdb=yes" addConfOpt "--enable-shell=yes" addConfOpt "--enable-null=yes" addConfOpt "--enable-overlays=yes" addConfOpt "--enable-shared=yes" addConfOpt "--with-threads=yes" addConfOpt "--with-tls" addConfOpt "--enable-sssvlv" # need this for server side sorting outlook address book
Unless someone else can tell me they have this working I will give up.
Thanks, Ed
openldap-technical@openldap.org
-
Diego Lima -
Edward Capriolo