On 16.07.19 18:35, Alan DeKok wrote:
On Jul 16, 2019, at 7:17 AM, Sven Hartge <sven@svenhartge.de> wrote:
Do *I* need to do anything here to get the correct VLAN to the user on session resumption or is it just *magic* and will work automagically?
The rest of the documentation says:
# 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
So VLAN information is *not* in the cache.
Or do I need to add the Xeap.authenticate and Xeap.authorize policies somewhere?
No.
I'd like to understand the mechanism before playing with it.
You need to set Cached-Session-Policy in the original authentication session.
Then, when the session resumes, the server will automatically populate the 3 attributes mentioned above. You can then use those attributes to do VLAN assignment.
OK, understood. But: How? And what? My searches just found some old discussion from 2011 not really providing any example and soon trailing off and many discussions about the generic cache module, which is a completely different thing.
The reason for the confusion is that the session resumption generally is missing *lots* of information. The original authentication has a real User-Name available, certificates, etc. The resumed session has only the outer User-Name, and no certificates. Because it's authenticating the user with a cached session key, not a certificate or password.
The result is that if you want to apply policies to the resumed session, you generally can't. Because the User-Name, etc. are all missing. In order to fix that, FreeRADIUS uses the Cached-Session-Policy. Which lets you control what policy is applied.
We can't cache all of the attributes from the original Access-Accept, because they include things like Session-Timeouts, which will change over time.
Understood and quite logical, in concept. But what I am missing is a concrete example how a configuration would look, if you excuse my thickness. Also, side note here: the native Debian packages in Debian 9 and 10 have tls-caching disabled at the source level because of CVE-2017-9148. Which means without recompilation you can't use this feature. Grüße, Sven.