12:04 p.m.
Hi,
In
my case, it's a real that is both reachable via the fallback path and the primary
path, yet the authentication fails.
According to your logs your are right. I expanded my tests to EAP-TLS and voilà the
conversation is ongoing via fallback (I tested different fallbacks) path and via
primary path in the first authentication, but authentication never fails and no request is
lost! To make it clear conversation starts with fallback path and is ongoing via dynamic
path.
I repeated the tests (stop the radsec etc.) and start again
and again always the same picture. There is a successfully ongoing EAP-authentication via
two path. Is that really surprising?
If I’m not completely mistaken we have a proof of concept that radsecproxy is transparent
to client and radius server.
As long as you do not change the radius server during conversation auth should not fail.
Could be the reason why authentication fails in your case.
Best regards,
Ralf
--
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
On 25 Mar 2021, at 10:04, Paul Dekkers
<paul.dekkers(a)surf.nl> wrote:
Hi,
On 25/03/2021 09:51, Ralf Paffrath wrote:
thx. :-)
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> wrote:
Hi,
On 24.03.21, 08:49, "Fabian Mauchle" <fabian.mauchle(a)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> 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
>> 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