From: cg <aub...@gm...> - 2011-01-31 13:48:00
|
Hi Jake, Thank you for the tip about a FR proxy. We don't need to do it now, but it is valuable info in case of a future need. Personally, I am *not* expert in FR and was happy to set it up and have it just work for us. The university *does* have a dedicated FR server but I wasn't certain what effect the PF perl module might have on its general functioning - so the simplest, most direct way seemed to be to set up a small FR installation on the PF server itself. I suppose that wouldn't be an issue for a FR guru. Thanks again & best wishes, Chris On Fri 28.Jan'11 at 17:50:01 +0000, Sallee, Stephen (Jake) wrote: > >This, of course, doesn't address your point of traffic between PF and radius but I think that it's another encrypted channel between radius and the ldap side of ?>things ... > > Usually the traffic between FR and the LDAP backend is encrypted, but it is not necessary to make it function ... highly advisable, but not a requisite ...unless your LDAP only stores encrypted user account info (I believe MS AD is this way) > > >We have a dedicated radius installation on the PF server itself ; all traffic between the two is therefore loopback and I don't think it can at all be seen from outside >the box. (Please let me know if this is a misconception !) > > You are correct the loopback traffic will not be visible on the wire, however in our deployment the FR server and the PF server are not the same, they are on a dedicated server vlan so that mitigates our risk but if someone else deploys the same setup and the data must traverse vlans that may not be for servers only the data would be easily stolen. Think if a branch office deployed PF and wanted to use a FR server at the main branch to do the captive portal auth, they would be sending that info across public links ... vary bad idea in this case : ). An easy work around would be to setup a FR server on the PF box that would then proxy encrypted requests to the correct FR server, but that could be difficult for someone who is not well versed in FR. > > My more immediate concern is that anyone looking at the debug output of the FR server will be able to watch user names and passwords scroll by in completely clear text, again in a complex environment where the same people may not manage the FR server and the PF server that may be an issue. Not to mention the regulatory concerns, I am speaking of regulations like Sarbanes-Oxley, HIPA, FIRPA, etc. BTW: even if your FR server is the same as your PF server, this still applies. > > Jake Sallee > Godfather Of Bandwidth > Network Engineer > > Fone: 254-295-4658 > Phax: 254-295-4221 |