Gotchas of LDAP Server Side Sort controls

[Arran Cudbard-Bell]

> On Mar 15, 2017, at 6:08 PM, Michael Ströder <michael at stroeder.com> wrote:
> 
> Arran Cudbard-Bell wrote:
>> Ambiguous results result in the user being rejected unless you specify a SSS to make
>> the result deterministically ambiguous :)
> 
> There's one use-case where you can turn ambiguous search results into a single result:
> Use SSS toegether with sizelimit=1 for searching the highest or lowest ordered ID. ;-P

Ah, true, I should probably make sure that's done.

>> It's useful for pulling back multiple policy objects in a hierarchy. For example you
>> can represent port strings with LDAP objects, and hang policy off different levels
>> (line cards, ports etc...).
> 
> Hmm, but why can't you just do this by comparing the attribute values in FreeRADIUS?

In the C code you could definitely do that.  With unlang as it is currently not so much.

I'll admit some of this is laziness.  I don't want to have to reimplement all the comparators
for the various value types.  I guess now we have boxed values it's easier to create a
generic API to do that.

>> For that you need the entries to be sorted by DN.
> 
> Nitpicking:
> You can only use SSS on attributes with LDAP syntax for which an ORDERING matching rule
> is defined (see RFC 2891). There is no ORDERING matching rule defined for DN syntax (see
> RFC 4517).

Yeah, yeah, but in practice: !sss=entryDN:caseIgnoreOrderingMatch - works fine.

>> It can also be useful for doing the same thing with nested groups.
> 
> Hmm, frankly I don't get it.

Where you pull back policy fragments from every member of the hierarchy:

cn=staff,ou=groups,dc=freeradius,dc=org
radiusAttribute: reply:Reply-Message := 'Hello staff member'
radiusAttribute: reply:Service-Type := NAS-Prompt
radiusAttribute: reply:Session-Timeout := 300

cn=admin,cn=staff,ou=groups,dc=freeradius,dc=org
radiusAttribute: reply:Reply-Message := 'Hello administrator'
radiusAttribute: reply:Service-type := Administrative

and need the ordering to be deterministic... and yes using a horrible dynamically constructed
search filter (using entryDN), you can pull get all the objects in one search operation.

>> I guess I'll just add a note about resource exhaustion... But honestly, allocating
>> memory for one SSS per connection shouldn't cause any issues on modern systems?
> 
> Well, this depends very much on how many entries are returned.

Indeed.

-Arran


Arran Cudbard-Bell
FreeRADIUS Core Developer

FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20170315/6b5b2c7e/attachment.sig>