On 04/20/2011 10:13 PM, John Douglass wrote:
What exactly am I supposed to store into the attribute
"Cached-Session-Policy"? Is this referring to a policy within the file
"policy.conf" that will run and extract attributes according to the
function there or is it something else?
Based on a quick glance at the source: You store anything you want, and
then you write policy to act on it. The server doesn't do anything
specific with the attribute beyond storing it and allowing you to read it.
For example:
post-auth {
if (reply:Cached-Session-Policy =~ /group=(.+),building=(.+)/) {
update reply {
My-Vlan = "%{sql:...some sql based on the %{1} and %{2} values}"
}
} else {
# do your policy work, then
update reply {
Cached-Session-Policy := "group=staff,building=admin"
}
}
}
The notes also say:
# You probably also want "use_tunneled_reply = yes" when using fast
session resumption.
And I have turned that on everywhere I could find, but it doesn't appear
to be even saving the 1st values of Tunnel-Private-Group-Id.
Hmm.
AFAICT from the source, the common TLS code (used by EAP-TLS and
PEAP/TTLS too) will only cache User-Name, Stripped-User-Name and
Cached-Session-Policy. Arbitrary valuepairs aren't stored in the cache.
In some respects, this makes sense - you might set the VLAN based on the
switch they're on; you need to re-calculate those values because you
can't guarantee that session resumption takes place on the same switch.
Basically, if you set reply variables based on some kind of lookup (e.g.
SQL) the safe option is to store the "key" in Cached-Session-Policy,
then set the reply variables (vlan etc.) in post-auth based on the key.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
