On Feb 25, 2016, at 9:39 AM, Jonathan Gazeley <Jonathan.Gazeley@bristol.ac.uk> wrote:
In inner post-auth we are doing this to populate session-state from the current set of attributes:
update outer.session-state { User-Name := &User-Name Inner-User-Name := &User-Name }
That will update the outer session state. But I'm wondering why you need to cache the User-Name twice.
Is this sufficient to ensure Inner-User-Name ends up in the TLS cache? This previous posting from Arran seems to suggest it is:
http://lists.freeradius.org/pipermail/freeradius-users/2016-January/081598.h...
If you're using 3.1...
In outer post-auth we are doing this to copy the session-state back before acting upon the information:
update { &reply: += &session-state: }
That should cause the User-Name in the Access-Accept to be the User-Name from the inner tunnel.
Here's today debug log: http://pastebin.com/ZD1nmAvC
Which shows that the cache_tls_session module is caching TLS-Session-Data, and not much else. Did you edit raddb/mods-available/cache_tls to cache the attributes you want cached?
I'm looking at line 4576 (a resumed session) where the outer post-auth is supposed to copy attributes to reply from session-state and fails to do so. The session-state list should be being populated in inner post-auth but the server seems to skip this for resumed sessions and the list is empty.
Again, the session-state list is for the *current* authentication session, and ONLY the current authentication session. The cache_tls_session module caches attributes across *multiple* TLS sessions. The session-state list is NOT cached across multiple TLS sessions. Stop looking at session-state. Go modify raddb/mods-available/cache_tls, and tell it to cache the attributes you want cached. Alan DeKok.