On Mar 15, 2017, at 4:01 PM, Peter Lambrechtsen <peter@crypt.nz> wrote:

I wouldn't have thought SSS would be useful at all.. Normally you only care about SSS if you're getting back multiple records.

If you represent realms as OUs and do a 'sub' scoped search for an unqualified user, you get back multiple entries, which rlm_ldap counts as an ambiguous search result. Ambiguous results result in the user being rejected unless you specify a SSS to make the result deterministically ambiguous :)

But in a radius sense why would you want multiple records. Since you'll be authenticating or authorizating a single user so you only want a single record.

Struggling with a Radius use case here.

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...). For that you need the entries to be sorted by DN. It can also be useful for doing the same thing with nested groups. 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? Unless i'm missing something and the VLVs stick around after the query finishes? -Arran Arran Cudbard-Bell FreeRADIUS Core Developer FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2

On Mar 15, 2017, at 6:08 PM, Michael Ströder <michael@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