configuring proxy base on eap-type
Hello freeradius-users, Is there any way to proxy freeradius unsupported eap-type to an external radius ? I have a working setup using inner-tunnel. If I understand correctly, in this case, inner-eap are tunneled to localhost on port 1814 by default. My goal is to have eap-juac (Juniper/Funk Software) tunneled to a Juniper UAC device. I try to avoid my actual proxy setup where a specific real is tunneled to UAC. The problem is that end-users can bypass UAC proxying by simply changing their domain identity ... Best regards Fred MAISON
Fred MAISON wrote:
Is there any way to proxy freeradius unsupported eap-type to an external radius ?
EAP does not allow this. By the time EAP has decided on an EAP type, the EAP conversation is well underway. Changing it mid-stream to another server won't work.
I have a working setup using inner-tunnel. If I understand correctly, in this case, inner-eap are tunneled to localhost on port 1814 by default.
Sort of. It's not really proxied, but the basic idea is the same.
My goal is to have eap-juac (Juniper/Funk Software) tunneled to a Juniper UAC device.
Does that appear inside of a TLS tunnel? If so, the *inner* session can be proxied. Otherwise... no, it can't be proxied.
I try to avoid my actual proxy setup where a specific real is tunneled to UAC. The problem is that end-users can bypass UAC proxying by simply changing their domain identity ...
Then how will they be authenticated locally? *Why* would you authenticate them locally? Alan DeKok.
Le lundi 24 mai 2010 à 11:49 +0200, Alan DeKok a écrit :
Fred MAISON wrote:
Is there any way to proxy freeradius unsupported eap-type to an external radius ?
EAP does not allow this.
By the time EAP has decided on an EAP type, the EAP conversation is well underway. Changing it mid-stream to another server won't work.
I have a working setup using inner-tunnel. If I understand correctly, in this case, inner-eap are tunneled to localhost on port 1814 by default.
Sort of. It's not really proxied, but the basic idea is the same.
My goal is to have eap-juac (Juniper/Funk Software) tunneled to a Juniper UAC device.
Does that appear inside of a TLS tunnel? If so, the *inner* session can be proxied. Yes, JUAC is an inner EAP protocol, inside ttls or peap. In our setup, It must be prefered because I have powerfull client-side host-checking features allowing to deeply control a lot of things mainly on Microsoft and Apple workstations (update level, antivirus, and so on ...) Customer tried to make it work with the help of Juniper's engineers using SteelBelted in front doing proxy to UAC for inner JUAC, but they failed because there is some other EAP protocols present in the production network they have not been able to support after many weeks of efforts. I have proposed to replace SteelBelted by freeradius, and I succeed to pass initial testings, but my current setup was without inner-tunnel modules correctly configured, which makes there is a lot of unneeded ldap access (anonymous identities which does not exist in ldap backend and so on ...) and impossibility to configure seperately outer and inner (when present) author/authent ...
Otherwise... no, it can't be proxied.
I try to avoid my actual proxy setup where a specific real is tunneled to UAC. The problem is that end-users can bypass UAC proxying by simply changing their domain identity ...
Then how will they be authenticated locally? *Why* would you authenticate them locally?
Until I am not to sure I correctly manage all existing protocols present in the network, I can't harden by simply rejecting this case ; I must be sure ... Any way, in case of outer+inner, it seems identities are not consistently configured, so using reals is very weak. I think I did not gave you enough information : * All NAS point to freeradius * All EAP protos without inner tunnel must be authenticated by freeradius using a ldap backend (I found existing devices on able to do EAP-LEAP for example, but may be there is some other insecure eap types) * juac is an innner protocol, it can be EAP-TTLS/EAP-JUAC or EAP-PEAP/EAP-JUAC (outer/inner) * for all other tunneled EAP-TTLS/* or EAP-EAP/*, I have to validate inner identity against ldap for authorize (ldap radiusgroupname membership) and authenticate (most common seems to be mschapv2 using ntpassword recovered in ldap during authorize). outer identity will not be checked because of encoutered client-side configuration inconsistencies. Best regards Fred MAISON
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Hi,
Yes, JUAC is an inner EAP protocol, inside ttls or peap. In our setup, It must be prefered because I have powerfull client-side host-checking features allowing to deeply control a lot of things mainly on Microsoft and Apple workstations (update level, antivirus, and so on ...) Customer tried to make it work with the help of Juniper's engineers using SteelBelted in front doing proxy to UAC for inner JUAC, but they failed because there is some other EAP protocols present in the production network they have not been able to support after many weeks of efforts. I have proposed to replace SteelBelted by freeradius, and I succeed to pass initial testings, but my current setup was without inner-tunnel modules correctly configured, which makes there is a lot of unneeded ldap access (anonymous identities which does not exist in ldap backend and so on ...) and impossibility to configure seperately outer and inner (when present) author/authent ...
hmmm...apart from the Apple OSX support I'd be tempted to point you to the SVN of FreeRADIUS that contains microsoft NAC support - which lets you check windows stuff (anti virus present/up to date, windows updates, firewall etc) just using the built in supplicant in XP SP3, Vista and 7. it should be present in FreeRADIUS 2.2.x - but no OSX support yet...because I think that'll need additional program/supplicant code on the client. regarding you query though.....hmmm, you should be able to see the EAP-Type and do something in unlang to update the control socket....but as its the inner type that might be too late in the process. or maybe not. in inner-tunnel itself you can allow extra proxying to occur. its nasty and you'd be treading down a path that less people have worn...so take care. alan
Fred MAISON wrote:
Yes, JUAC is an inner EAP protocol, inside ttls or peap.
Then you should be able to proxy it by just proxying the inner tunnel data.
I have proposed to replace SteelBelted by freeradius, and I succeed to pass initial testings, but my current setup was without inner-tunnel modules correctly configured, which makes there is a lot of unneeded ldap access (anonymous identities which does not exist in ldap backend and so on ...) and impossibility to configure seperately outer and inner (when present) author/authent ...
I don't know what you mean by that. It shouldn't be much of a problem to configure it.
I think I did not gave you enough information : * All NAS point to freeradius * All EAP protos without inner tunnel must be authenticated by freeradius using a ldap backend (I found existing devices on able to do EAP-LEAP for example, but may be there is some other insecure eap types)
Uh... don't use LEAP. Use TTLS or PEAP.
* juac is an innner protocol, it can be EAP-TTLS/EAP-JUAC or EAP-PEAP/EAP-JUAC (outer/inner) * for all other tunneled EAP-TTLS/* or EAP-EAP/*, I have to validate inner identity against ldap for authorize (ldap radiusgroupname membership) and authenticate (most common seems to be mschapv2 using ntpassword recovered in ldap during authorize). outer identity will not be checked because of encoutered client-side configuration inconsistencies.
So... figure out who's supposed to do EAP-JUAC, and proxy them. Authenticate everyone else inside of the tunnel. Alan DeKok.
Fred MAISON wrote:
Yes, JUAC is an inner EAP protocol, inside ttls or peap.
Then you should be able to proxy it by just proxying the inner tunnel data.
Yes, how can I do that ? May I activate proxy-inner-tunnel site along with inner-tunnel site ? EAP-JUAC EAP-Type seems to be 254. May this help along with ignore unknown eap type flag ?
I have proposed to replace SteelBelted by freeradius, and I succeed to pass initial testings, but my current setup was without inner-tunnel modules correctly configured, which makes there is a lot of unneeded ldap access (anonymous identities which does not exist in ldap backend and so on ...) and impossibility to configure seperately outer and inner (when present) author/authent ...
I don't know what you mean by that. It shouldn't be much of a problem to configure it.
I think I did not gave you enough information : * All NAS point to freeradius * All EAP protos without inner tunnel must be authenticated by freeradius using a ldap backend (I found existing devices on able to do EAP-LEAP for example, but may be there is some other insecure eap types)
Uh... don't use LEAP. Use TTLS or PEAP.
I agree with you. And the main goal of the current setup is to catch enough information to force user/workstations migration to TTLS when possible ; some devices will remain on LEAP since they seems to be hardcoded to do LEAP and only LEAP ...
* juac is an innner protocol, it can be EAP-TTLS/EAP-JUAC or EAP-PEAP/EAP-JUAC (outer/inner) * for all other tunneled EAP-TTLS/* or EAP-EAP/*, I have to validate inner identity against ldap for authorize (ldap radiusgroupname membership) and authenticate (most common seems to be mschapv2 using ntpassword recovered in ldap during authorize). outer identity will not be checked because of encoutered client-side configuration inconsistencies.
So... figure out who's supposed to do EAP-JUAC, Yes, but based on what ? I currently use a real, but this can be changed by end-user to bypass JUAC host checking capabilities ... and proxy them. Authenticate everyone else inside of the tunnel.
Yes, it's what I need, but I don't fully master how to do that. May be the first point related to enable site proxy-inner-tunnel ? If so, it seem to be very unselective (I meen ALL protocols doing inner-tunnel will be proxied to UAC, leaving only EAP-LEAP on freeradius. This could be a good solution for me. Best regards Fred MAISON
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Fred MAISON wrote:
Yes, how can I do that ? May I activate proxy-inner-tunnel site along with inner-tunnel site ?
No. It's an example. You can set "Proxy-To-Relam" to force proxying. See raddb/proxy.conf
So... figure out who's supposed to do EAP-JUAC, Yes, but based on what ? I currently use a real, but this can be changed by end-user to bypass JUAC host checking capabilities ...
Check the user name? Put the users into groups? This shouldn't be hard. You are *already* determining which users do JUAC, and which don't: the machines are configured to do it. Now just write down those rules for FreeRADIUS..
Yes, it's what I need, but I don't fully master how to do that. May be the first point related to enable site proxy-inner-tunnel ? If so, it seem to be very unselective (I meen ALL protocols doing inner-tunnel will be proxied to UAC, leaving only EAP-LEAP on freeradius. This could be a good solution for me.
So... configure that. Alan DeKok.
participants (3)
-
Alan Buxey -
Alan DeKok -
Fred MAISON