6:10 a.m.
Hi Paul,
On 23 Mar 2021, at 12:19, Paul Dekkers
<paul.dekkers(a)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.
I can’t notice this behaviour. But maybe I misunderstand you.
What is your dynamic server block configuration? Which radsecproxy version are you
running?
This breaks "the first" authentication for a
realm.
Do you mean the first realm request is lost?
Regards,
Ralf
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(a)lists.nordu.net
To unsubscribe send an email to radsecproxy-leave(a)lists.nordu.net
--
Dipl. Inform. Ralf Paffrath
Phone: Tel.: 030 884299-0 (DFN-GS Berlin: Sekretariat)
Mail: paffrath(a)dfn.de
Fax: 030 88 42 99 370 | http://www.dfn.de
Verein zur Förderung eines Deutschen Forschungsnetzes e.V.
Alexanderplatz 1, D - 10178 Berlin
Vorstand: Prof. Dr. Odej Kao (Vorsitzender) | Dr. Rainer Bockholt | Christian Zens
Geschäftsführung: Dr. Christian Grimm | Jochem Pattloch
VR AG Charlottenburg 7729NZ | USt.-ID. DE 1366/23822