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 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html