[Date Prev][Date Next]
Re: Server Side sort and the cn attribute
- To: email@example.com
- Subject: Re: Server Side sort and the cn attribute
- From: Edward Capriolo <firstname.lastname@example.org>
- Date: Wed, 6 Jan 2010 11:28:07 -0500
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=xwba1rg2DnXS+m1fbbWt0ZfGpfZWehL1AxXm1IXR57Y=; b=Gc4opWD7OLLIPABuadU4jaWWOGVA8UhlG++bIMCmj0qxrP49O5TzeO3XGSDQ1WXmCW 3G4DYHpA91UzJHkcTTa2ZqZodQTs3LVuNdB+7EMMXM5NDFFbLlVRRNtJKpruNeEEPotv NkKXruVyO5i/EkvoxfNPLcIER31jV+mBHHYw8=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=V9bEO5BtSzZz7irY+RR1MipejqrS/bpP/rmU3CPO7EL+Z8Hbc+lqsN+1hrBu71WKVE B+/Vrj4l3ipgndF2f0Fd/s/Nw0s8O8ya+AUlaceL3j+2tMCUVlWCFWrbga1y81JgR1Hb 3rNq815VCfrBNWSEp5+a5MXJ6dlgiD3iANfhM=
- In-reply-to: <email@example.com>
- References: <firstname.lastname@example.org>
On Fri, Dec 11, 2009 at 1:31 PM, Edward Capriolo <email@example.com> wrote:
> We use openldap as a back end for many things. One of the thing, it
> can be used for is an address book for outlook. Recently we upgrade to
> 2.4.16->2.4.20 from 2.(who knows how old).
> Outlook 2003 clients stopped working:
> So I followed the instructions here to enable server side sorting:
> I was able to add the ordering to the sn attribute.
> attributetype ( 22.214.171.124 NAME ( 'sn' 'surname' )
> DESC 'RFC2256: last (family) name(s) for which the entity is known by'
> ORDERING caseIgnoreOrderingMatch
> SUP name )
> Unfortunately outlook is looking at the cn attribute
> @400000004b21316a0e808064 sssvlv: no ordering rule specified and no
> default ordering rule for attribute cn
> @400000004b21316a0e808834 <= get_ctrls: n=1 rc=18 err="serverSort
> control: No ordering rule"
> That unfortunately is not defined in the core.schema
> # system schema
> #attributetype ( 126.96.36.199 NAME ( 'cn' 'commonName' )
> # DESC 'RFC2256: common name(s) for which the entity is known by'
> # SUP name )
> I am sure there is a good reason why cn does not have an ordering, but
> I am guessing it used to have this in the distant past since this
> previously worked. So how would I go about changing the system schema?
> Or does anyone have a better way to deal with this.
> (I know I could play with client registry (kb) article but I would
> like to handle this server side)
> Thank you for your insights.
To follow up, does anyone know why CN does not have any ordering rule?
Is their a way to add an ordering rule?