post-auth for proxied peap inner
p.mayers at imperial.ac.uk
Sat Oct 26 21:15:36 CEST 2013
On 26/10/2013 19:39, Alan DeKok wrote:
> Phil Mayers wrote:
>> I'm having a *really* hard time understanding how this works at all; I
>> don't get how the code in peap.c:~1126 actually causes a proxy request
>> to be sent; ultimately it's all called via rad_authenticate, which only
>> seems to check/process request->proxy after authorize, when rlm_eap does
>> all it's work in authenticate.
> Yes. That's exactly it. The PEAP module bails out of the
> authenticate section. The packet is proxied. When the proxy reply
> arrives, the PEAP is called again.
Sure; it's not strictly relevant here, but what confused me is how the
middle bit works - peap bails, but what causes the proxy packet to be
emitted? I see how this happens if you bail in "authorize", but not
(This is not hugely important however, it must be said)
> See rlm_eap.c, eap_post_proxy() for more magic.
>> Put another way - the original PEAP request containing the PEAP inner
>> comes into rad_authenticate via listen.c - I don't see how, once TLS is
>> decoded and peap.c has run the fake request via the inner tunnel server,
>> how the proxy packet gets sent and replied to.
>> (The reason for wanting to know this is to understand where to put the
>> processing code so that the "fake" can be pushed through post-auth
>> correctly without breaking "proxy as non-EAP" workaround)
> That was done in rad_authenticate, IIRC. See commit 860dd99c9d
I'm not seeing that, or I'm doing something wrong. AFAICT
rad_virtual_server only calls post-auth if request->reply->code is set,
and for packets which are proxied, it is==0 because the reply hasn't
been generated yet.
The post-proxy/post-auth code for eap/peap ultimately ends up in
eappeap_postproxy and AFAICT only calls post-auth if "fake" is found in
REQUEST_DATA_EAP_MSCHAP_TUNNEL_CALLBACK, which is only set for the
"proxy inner as non-eap" case?
In other words, I think post-auth works for peap proxied inner only if
"proxy_tunneled_request_as_eap = no", which is not the case for what I'm
trying to do.
The thing I'm actually trying to do is cause the inner eap-mschapv2
requests to be proxied [to another FR process] to free up the outer
processing thread ASAP - this relates to the recent issues we and others
have been having with peap/ntlm_auth timeouts under load spikes, which
seem to be some sort of Samba concurrency issue - I've used packet
captures to time the on-wire response times for the MS-RPC calls from
winbind, and they're completing in a timely fashion, but something in
the fork/exec/ntlm_auth/winbind-pipe sequence is going slow and blocking
the request thread pool :o(
Throwing hardware at the problem is the other solution, but I have no
way of knowing if this will solve or hide the problem - it could come
back at any time, and I really want to understand the cause (e.g. is it
the load of fork/exec or does ntlm_auth/winbind have some kind of
built-in concurrency issue?)
More information about the Freeradius-Devel