Adding proxying to our EAP setup

[Dave Mussulman]

Thanks for the help, Phil and Alan.  This message is pretty much an
FYI/wrapup for the archives (and for me, since it might be a bit before
I get back to it.)

The users I want to proxy have a fairly programmatic username pattern,
so I think the best thing for me is to expression match in a users file
(as opposed to hints or realms.)  My setup looks like:

authorize {
  preprocess
  eap
  files
  Autz-Type EAPINNER {
    eapfiles
    mschap
}

files has a DEFAULT line that catches the RADIUS server stripping
through the tunnels, and applies it to the EAPINNER Autz-Type:

DEFAULT         NAS-IP-Address == "127.0.0.1", Autz-Type := EAPINNER

The eapfiles is a second instance of the users file with the line:

DEFAULT         User-Name =~ "^vpn[0123456789]+$", Proxy-to-Realm := "VPNaccts"

(I wonder if I couldn't combine the NAS-IP-Address, User-Name and
Proxy-to-Realm in the first users file.  Maybe I'll try that later.  If
I did it on the outer loop, it proxied the full EAP session, instead of
just the inner authentication.)

In eap.conf, setting peap's proxy_tunneled_request_as_eap toggle let me
control whether I sent on EAP messages or MSCHAP messages.  (My copy of
the config didn't have that option, but it worked when I added it from
the 1.1.3 eap.conf)  Unfortunately, my upstream RADIUS server doesn't
yet support MSCHAP or EAP, so I'm waiting on that.  But I'm pleased with
what I've been able to do so far.

The catch I ran into involved the mschap section not authenticating off
the User-Password in the users file if I had ntlm_auth line configured.
This is my test system, and I don't have samba/winbindd configured so
those attempts always failed, but it never seemed to fall back to
figuring out itself.  That made troubleshooting difficult when I
couldn't get the simple users file entry to work.  Commenting out the
ntlm_auth line did the trick.  I haven't changed anything on our
production servers, but it must do things differently as we have
ntlm_auth configured and authenticating from the AD or a sql database
with local passwords.  Maybe FreeRADIUS handles different ntlm_auth
failures differently (cannot bind versus bad user password?)

Until the upstream server gets the functionality I'm looking for, there
were a few possible future issues I wanted to document before I lost
them.  If I set copy_request_to_tunnel in peap to yes, my NAS-IP-Address
== 127.0.0.1 trick doesn't work.  I was also concerned that proxying
seems to keep the NAS-IP-Address set to 127.0.0.1, and I didn't know if
the upstream provider would be concerned about that.  I put a setting in
the preproxy_users file to set that to an allowed NAS IP, but didn't get
to fully test/confirm that worked.

Thanks again for the help, and great product!

Dave