Hi Rich, >> with RADIUS we can do proper LDAP and inject an attribute meant for >> pf::vlan::custom. We did PoC this for a customer that finally decided to >> go with the easier category technique. > > In my non-PF freeradius 2.1.10 server, I use /etc/raddb/modules/ldap with > ldap.attrmap: > > replyItem Aruba-User-Role eduPersonPrimaryAffiliation > > But eduPersonPrimaryAffiliation hardly ever changes, so there is no real > reason to do an LDAP lookup every time. I could certainly fetch the info with > Net::LDAP upon first login, or even as a daily cron job, and cache the result > somewhere. I see that getNormalVlan sees $user_name. I hope that's the > Inner-Tunnel identity, not outer-tunnel? I'll find out shortly... >
I'm not sure but I think it's Outer actually since we run post-auth in the outer tunnel (NAS sees outer not inner). After my many many `radius -X` sessions, I've yet to see a different User-Name when comparing inner and outer tunnels. I would bet that radius would terminate an inner-tunnel with different User-Name characteristic than it's outer-tunnel. ... > For now, let's assume that some non-PF process will stuff the needed > information into a custom table in the local pf mysql database. Does > pf::vlan::custom inherit a global handle to the local database? If not, > should I call get_db_handle() myself? The "does this MAC address represent a > College-owned managed device" question can be answered with the existing node > table, but I don't think I can count on a direct mapping of $user_name to the > people table. Especially since pf::vlan::custom only gets a full hashref for > $node_info, not $user_name. See the recently added lib/pf/vlan/custom_example.pm for a pf::vlan::custom that access the database using our db layer: http://mtn.inverse.ca/revision/file/eec903620d67065d5c05c3cba4a7c15a104e3752/pf/lib/pf/vlan/custom_example.pm The db layer itself is a bit convoluted ("erreur de jeunesse" we say in french) but the example does all the boiler plate for you. Add your statements to the custom_db_prepare sub (like buildingnum_per_called_station_sql), query the database (like buildingnum_per_called_station_id sub). The rest is overloading pf::vlan's calls to make use of the queried building id. I could probably make your use case work in around two hours with server access and a helper on site to do the tests. Lastly if the info is in the node table you 'could' modify the statement in lib/pf/node.pm to add it in the SELECT's return, this way it would be automatically available in $node_info. But that customization would be overwritten on an upgrade. That's why we try to provide clear extension points where we give notices if we break the API (like pf::vlan vs pf::vlan::custom). Cheers! -- Olivier Bilodeau [email protected] :: +1.514.447.4918 *115 :: www.inverse.ca Inverse inc. :: Leaders behind SOGo (www.sogo.nu) and PacketFence (www.packetfence.org) ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ Packetfence-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/packetfence-users
