post-auth for proxied peap inner

[Phil Mayers]

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 
"authenticate".

(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?)