Is it possible to terminate EAP/Authentication on an entirely different radius box through freeradius?
Hi all, I have a question that some coworkers and I have been unable to answer in the last few weeks and we are hoping to have your insight. Here are the details (if I leave something important out, please let me know): We are running radiusd: FreeRADIUS Version 1.1.7, for host sparc-sun-solaris2.10 Currently we have TTLS/PAP authentication setup and working just fine. Some authentication occurs locally, while other realms are proxied off to another radius server that share a secret with us, but all TTLS tunnels are terminated by our freeradius box and then proxying is done radius to radius server. In the near future we will have some AD servers (LDAP) which will authenticate enterprise-wide credentials that are being issued to everyone on campus. In lab, we have made PEAP terminate on freeradius and then have used ntlm_auth & samba to proxy ms_chap out to the AD server for authentication. What we are wondering is if its possible to still have requests come through to our freeradius box, and instead of providing the certificate and proxying the contents of the inner tunnel to the AD box.. if its possible to simply proxy the entire request, PEAP/MSCHAP and all directly to their AD servers? They are hesitant to allow our freeradius box to join the domain, and if its doable, a workaround would be the preferred route. I hope this makes sense and thanks for any help offered. Sincerely, Max
What we are wondering is if its possible to still have requests come through to our freeradius box, and instead of providing the certificate and proxying the contents of the inner tunnel to the AD box.. if its possible to simply proxy the entire request, PEAP/MSCHAP and all directly to their AD servers? They are hesitant to allow our freeradius box to join the domain, and if its doable, a workaround would be the preferred route.
No, domain controler is not a radius server. They would need to set up IAS. Freeradius can proxy to that thing. Ivan Kalik Kalik Informatika ISP
Thanks for the quick reply and your help. Setting up IAS/NPS is not a problem. Assuming this is set up on the AD box, can we simply terminate PEAP type connections or connections for a certain realm at their IAS/NPS instead of at radiusd? That is to say, all we want freeradius to do is recognize a certain trigger and simply send the connection to IAS/AD for the entire authentication and authorization process. We do not want to use samba and ntlm_auth if such a thing is feasible for TTLS/MSCHAP, we simply want the entire radius access-request from the NAS to go through to their IAS from us. Sincerely, Max Ivan Kalik wrote:
What we are wondering is if its possible to still have requests come through to our freeradius box, and instead of providing the certificate and proxying the contents of the inner tunnel to the AD box.. if its possible to simply proxy the entire request, PEAP/MSCHAP and all directly to their AD servers? They are hesitant to allow our freeradius box to join the domain, and if its doable, a workaround would be the preferred route.
No, domain controler is not a radius server. They would need to set up IAS. Freeradius can proxy to that thing.
Ivan Kalik Kalik Informatika ISP
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Hi,
What we are wondering is if its possible to still have requests come through to our freeradius box, and instead of providing the certificate and proxying the contents of the inner tunnel to the AD box.. if its possible to simply proxy the entire request, PEAP/MSCHAP and all directly to their AD servers? They are hesitant to allow our freeradius box to join the domain, and if its doable, a workaround would be the preferred route.
yes, sure you can - they'll have to run IAS or NPS (ad2003 or ad2008 etc) and then you simply proxy the whole shaboodle off to them to deal with - then you dont need to play around with ntlm_auth etc etc. of course, they'll have to put required certs onto their auth system but thats a minor issue. alan
I can't believe it. We had a line in our hints file that was totally screwing us up -- I had no idea it was there until just now: DEFAULT Prefix == "anonymous", Strip-User-Name = No Realm = "LOCAL" This is why I couldn't understand what you guys were talking about, since we always use anonymous as our outer-identity for TLS type connections, I could not for the life of me figure out why adding a server to the proxy.conf would ever work. Is it possible to select based on EAP-type (i.e. if TTLS, do LOCAL authentication?) Right not we are doing it based on prefix/suffix. Regardless, I think we have this solved now. This problem was way easier than we thought once we got a grasp on all of the processing we were doing. Argh! Thank you Ivan & Alan for pointing us in the right direction. Sincerely, Max A.L.M.Buxey@lboro.ac.uk wrote:
Hi,
What we are wondering is if its possible to still have requests come through to our freeradius box, and instead of providing the certificate and proxying the contents of the inner tunnel to the AD box.. if its possible to simply proxy the entire request, PEAP/MSCHAP and all directly to their AD servers? They are hesitant to allow our freeradius box to join the domain, and if its doable, a workaround would be the preferred route.
yes, sure you can - they'll have to run IAS or NPS (ad2003 or ad2008 etc) and then you simply proxy the whole shaboodle off to them to deal with - then you dont need to play around with ntlm_auth etc etc. of course, they'll have to put required certs onto their auth system but thats a minor issue.
alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Is it possible to select based on EAP-type (i.e. if TTLS, do LOCAL authentication?) Right not we are doing it based on prefix/suffix.
Stick to it. Since radius server has no say in what authentication protocol is used (that is determined between NAS and supplicant) such policy would be easily defeated. Ivan Kalik Kalik Informatika ISP
participants (3)
-
A.L.M.Buxey＠lboro.ac.uk -
Ivan Kalik -
Max Palatnik