Re: Adding proxying to our EAP setup
Dave Mussulman wrote: 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?) You need something like this: alocaluser User-Password := "astring", MS-CHAP-Use-NTLM-Auth := 0 ...which lets you use ntlm_auth for some users, but override it on a case-by-case basis. 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 Hmm. Yes, that would occur, and in many cases copy_request_to_tunnel is highly desirable. Not sure how to handle that. 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. Yes again. Hmm. Not really optimal - the ideal situation would be copy_request_to_tunnel to give the original NAS IPs/ports/etc. to the upstream server, but as you say that breaks the match for the inner eap. I guess inner/outer should really be a FreeRadius internal attribute. From the look of the code however, fake requests will have Client-IP-Address set to 127.0.0.1 by the "preprocess" module, and that's a FreeRadius internal/not-on-the-wire attribute - you should be able to replace matching on NAS-IP-Address with Client-IP-Address and set copy_request_to_tunnel and all would be well Thanks again for the help, and great product! Dave - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Adding proxying to our EAP setup
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
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Adding proxying to our EAP setup
Dave Mussulman <[EMAIL PROTECTED]> wrote:
> 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".
That's a little difficult to do, because the "do proxy" code isn't
tied into the "authenticate" section. Instead, you could look the
user up in LDAP, and if they're not found, set "Proxy-To-Realm :=
foo", where "foo" is a normal realm.
> Right now, I'm doing that via the default config realm 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?
Yes.
> 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?
Yes. You can proxy the inner EAP-MSCHAPv2 session as MS-CHAPv2.
Read "eap.conf".
Alan DeKok.
--
http://deployingradius.com - The web site of the book
http://deployingradius.com/blog/ - The blog
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Adding proxying to our EAP setup
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
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Adding proxying to our EAP setup
Hello,
I've been using FreeRADIUS for years to do PEAP/MSCHAP2 WPA
authentications, and it's worked well enough to be a
set-it-and-forget-it solution. I'm currently running 1.0.4, but would
upgrade if it would help me accomplish the goals in this message.
However, changing environments bring me back into the config, and I'm
not sure how to do what I want. We've been using ntlm_auth against the
AD for our primary authentication, with a fallback to sql and plaintext
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.
>From a few trial/error tests, I have two questions about proxying and
EAP.
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
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?
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?
How would you recommend I configure this?
Dave
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
