post-auth for proxied peap inner

[Alan DeKok]

Phil Mayers wrote:
> 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".

  The proxy handler is independent of authorize / authenticate, IIRC.

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

  I'll have to take a look.  I've been finalizing 3.0.1, and haven't
looked at 2.2.x for a while.

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

  Yes.

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

  Hmm... if that's so, it needs to be fixed.  But likely in 3.x, because
that code is enormously better.

  Some changes for 3.1 should make this much easier to do, and remove
all of the weird issues around proxying inner tunnel stuff.

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

  Hmm... not nice.  That could be fixed another way, but I understand
what you're trying to do.

  v2.x.x has some fixes which let you manually set the timeout for exec
/ ntlm_auth.  If that doesn't work well, there are other fixes.

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

  The load of fork / exec shouldn't be a problem.

  Perhaps a better solution would be to run ntlm_auth in "pipe" mode.
That would remove the fork/exec issue, and perhaps allow for greater
concurrency.

  Alan DeKok.