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