10:04 a.m.
Hi,
On 25/03/2021 09:51, Ralf Paffrath wrote:
In my case, it's a real that is both reachable via the fallback
path and
the primary path, yet the authentication fails.
Hi,
I had no Paul's log so I produced my own log.
Happy to send it, Fabian asked it
off-list but I'll forward,
On 24 Mar
2021, at 18:09, Fabian Mauchle <fabian.mauchle(a)switch.ch
<mailto:fabian.mauchle@switch.ch>> wrote:
Hi,
On 24.03.21, 08:49, "Fabian Mauchle" <fabian.mauchle(a)switch.ch
<mailto:fabian.mauchle@switch.ch>> wrote:
This first request is implicitly placed in the queue for the
dynamic server (before the lookupCommand has even been called).
I have to corret myself here. Seems I've misunderstood that code
block, and Pauls log (thanks!) clearly shows this. Reading it the
right way, it looks quite intentional, not a bug.
The first request is _not_ placed on the dynamic servers queue.
And therefore it doesn’t break the first authentication. It is
important to know that no request is lost and the first conversation is
going via one fallback path and the next request later on via the
dynamic path But anyway we we will run into trouble. dynamic and
fallback servers
might include different realm blocks. So for dynamic realms which are
not configured on the fallback servers the conversation might results
in an Access-Reject for the first request and might results in an
Access-Accept only in a second request via dynamic.
This would break the service.
Well it breaks for me.
I must admit that when Fabian asked for a pointer in the documentation,
I don't really have one. I just more or less assumed this is how it
worked, because that made sense to me. If you lookup realms dynamically,
they may be only reachable via a dynamic path after all. So you're not
sending something to fallback if the dynamic path is not resolved yet.
And yes that is slow, but noone said dynamic lookups are fast - they
aren't in Radiator either. That's why you need carefull tweaking of DNS
settings too.
Anyway. I'll just use my workaround,
Regards,
Paul
Best regards,
Ralf
I read that one wrong, it only triggers the
dynamic lookup, but the
server selection is run again after the new realm structures have
been set up. On this second (and any subsequent) passes, the dynamic
server is ignored until its connection is established.
On 23.03.21, 13:04, "Paul Dekkers" <paul.dekkers(a)surf.nl
<mailto:paul.dekkers@surf.nl>> wrote:
and whether we can have the dynamic lookup blocking
for the request?
I will add it as a feature request. However, this might have quite
some implications: if the lookup and connection setup is slow, this
might block a realm for quite some time.
That would allow fallback "as documented".
Could you point me to that documentation? (I couldn’t spot it in the
manpages; just so I can keep any documentation up to date).
Best regards,
Fabian
_______________________________________________
radsecproxy mailing list -- radsecproxy(a)lists.nordu.net
<mailto:radsecproxy@lists.nordu.net>
To unsubscribe send an email to radsecproxy-leave(a)lists.nordu.net
<mailto:radsecproxy-leave@lists.nordu.net>
--
Dipl. Inform. Ralf Paffrath
Phone: Tel.: 030 884299-0 (DFN-GS Berlin: Sekretariat)
Mail: paffrath(a)dfn.de <mailto:paffrath@dfn.de>
Fax: 030 88 42 99 370 | http://www.dfn.de <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