Gotchas of LDAP Server Side Sort controls
a.cudbardb at freeradius.org
Thu Mar 16 01:18:41 CET 2017
> 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.
> 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:
radiusAttribute: reply:Reply-Message := 'Hello staff member'
radiusAttribute: reply:Service-Type := NAS-Prompt
radiusAttribute: reply:Session-Timeout := 300
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.
FreeRADIUS Core Developer
FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
More information about the Freeradius-Users