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 ------------------------------------------------------------------------------ Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d _______________________________________________ Packetfence-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/packetfence-users
