Adding proxying to our EAP setup

[Phil Mayers]

Dave Mussulman wrote:

> passwords for local accounts.  I'd like to change from maintaining my
> own sql copy/user database to RADIUS proxying to someone else's server.
> 
> What's the recommended way to configure failover proxying/realms when
> there's no realm-ish identifier?  When "user" logs in, I want them to
> check against ntlm_auth, and if that fails, resort back to a proxied
> realm as "user".  Right now, I'm doing that via the default config realm

Hmm. Do you have a list of the usernames which are local versus the ones 
that are not? If so, I'd so:

authorize {
   preprocess
   themodule
   files
   Autz-Type LOCALAD {
     mschap
   }
}

"themodule" (be it a files, SQL or rlm_passwd instance) should set a 
group on the to-be-proxied users e.g. REMOTE, and then the files module 
should say:

DEFAULT	My-Group == "REMOTE", Proxy-To-Realm := TheRealm

DEFAULT	Autz-Type := LOCALAD

...then configure TheRealm appropriately. You can invert the sense if 
you want to put the group on the local AD users.

> suffix {} module, and a realm NULL section in proxy.conf.  Is there a
> better way?  Hints or something?  Does this involve the
> configurable_failover documentation?

I don't think so - the mschap module will match during authorize if the 
request has the mschap attributes. It won't run "halfway" to see if the 
user is in AD, then run the "rest" of the way during authenticate to 
actually auth them. So mschap will always match

> 
> Second question involves proxies and EAP.  Since my upstream RADIUS
> server I'm proxying to doesn't seem to support EAP, is it even possible
> for my RADIUS server (in its PEAP/MSCHAPv2 decoding,) to create a
> 'normal' RADIUS packet to relay?  Or do I have to get the upstream
> server to support EAP?  It seems like if suffix (realm) module is
> anywhere in the authorize section, it proxies the entire EAP packet.
> Can I tell it only to do that at a certain stage in the process?

The MS-CHAPv2 request from inside the PEAP goes through the server a 2nd 
time, and you just need to configure the server to match that. Something 
like:

authorize {
   preprocess
   eap
   files
   Autz-Type EAPINNER {
     redundant {
       user2realm
       mschap
     }
   }
}

files' "users" needs to read:

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

user2realm needs to be an rlm_passwd instance like so:

   passwd user2realm {
     filename = user2realm
     format = "*User-Name:Proxy-To-Realm"
     hashsize = 100
   }

...and the contents of the file read:

username:TheRemoteRealm
user2:TheRemoteRealm

So processing goes:

1. preprocess
2. files - if from local, set autz-type
3. if autz-type==EAPINNER:
    3a. call user2realm
    3b. if "notfound" or "failed" call mschap



Both of the above techniques assume you have a list of the remote users. 
If you don't, you could obtain a list of local users either statically 
or dynamically via LDAP against AD and invert the sense of the matching.

If you can't do either, you may be out of luck