On 23 Mar 2021, at 12:19, Paul Dekkers <paul.dekkers@surf.nl> wrote:

Hi,

If you have this realm block:

realm /@.+\..+$/ {
        server dynamic
        server fallback.server.here
        accountingResponse on
}

radsecproxy will start to send the request to fallback.server.here because the dynamic part didn't resolve yet: it's not blocking. Only as soon as the config for the dynamic realm is in place, when the dynamicLookupCommand had a result, it will continue with that host.

This results in part of the conversation going via one path, part of it via another.

This breaks "the first" authentication for a realm.

Unless there is no fallback of course: or if the fallback is done in the lookup script (else at the end, which is what I'm using now). So, while this not being problematic for me ;-) I was wondering if someone else stumbled upon this, and whether we can have the dynamic lookup blocking for the request? That would allow fallback "as documented".

Regards,
Paul


_______________________________________________
radsecproxy mailing list -- radsecproxy@lists.nordu.net
To unsubscribe send an email to radsecproxy-leave@lists.nordu.net