Awesome Phil, that was exactly the kind of example that is awesomely
useful :)
I see that by default the username is stored along with this.
[peap] Adding cached attributes to the reply:
User-Name = "jd187"
Cached-Session-Policy = "vlan=316"
Do you know exactly how the session resumption is determined? In the
debug output I see:
[peap] eaptls_process returned 3
[peap] EAPTLS_SUCCESS
[peap] Session established. Decoding tunneled attributes.
[peap] Peap state TUNNEL ESTABLISHED
[peap] Skipping Phase2 because of session resumption
[peap] SUCCESS
Would ANY authentication for "jd187" get the cached applied or does
freeradius have some concept of uniqueness when it comes to different
sessions by the same user?
The documentation (in eap.conf states):
# The cache contains the following information:
#
# session Id - unique identifier, managed by SSL
# User-Name - from the Access-Accept
# Stripped-User-Name - from the Access-Request
# Cached-Session-Policy - from the Access-Accept
#
#
# On session resumption, these attributes are copied from the cache,
and placed into the reply list.
So I am assuming that session id is some combination of attributes that
uniquely describe a single particular connection/authentication (I would
hope). In my environment, if the cache is purely based off username,
this would break our entire system.
Figured I would bring this to see if anyone has any insight on how this
session ID is created, managed, and applied to the subsequent
session/authentications. I'll be running some experiments on this early
next week but figured I might ask if anyone has any ideas on how/when
the caching is applied (as configured by the eap.conf variables).
Thanks in advance,
- John Douglass, Georgia Tech
On 04/20/2011 07:18 PM, Phil Mayers wrote:
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
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
