Panagiotis Georgopoulos <panos@comp.lancs.ac.uk> wrote:
Hmm, yes I think I do. So the server keeps the reply of an authentication and therefore if a client has authenticated successfully before, there should be a valid entry of his identity in the cache so that Phase 2 of TTLS in my case would be skipped.
FreeRADIUS asks the OpenSSL library to store some 'opaque' data so that if a session can be resumed, then OpenSSL will make this data available to FreeRADIUS which will convert it back into RADIUS attributes (for the inner 'reply' message). When FreeRADIUS grumblesthere is nothing in the cache session, it usually means "inner auth succeeded but you have no idea who the user is"; as typically all you want OpenSSL to return (from the *opaque* string of bytes) to FreeRADIUS is the 'User-Name'. Remember your inner User-Name does not match your outer one (which should be '@example.com'); if you do VLAN assignment based on inner username (rather than MAC address) then you need this data.
Residing in the cache, seems reasonable since it is a feature of SSL/TLS. What I don't get is that since this is a standard EAP-TTLS authentication, shouldn't resumption be working out of the box?
Well for it to work you really need to ask OpenSSL to store something like the User-Name otherwise you will find for the first (non-resumption) authentication things work, but for the second one authentication succeeds but the *authorisation* fails as your unlang/users policy has no idea what VLAN to assign as you need to know the inner User-Name attribute.
In my tests thought I get "Info: [ttls] WARNING: No information in cached session!".
As if you read what I said, you are *not* telling the inner virtual server to return in the reply packet the inner username.
I also recommend that you also do: ---- update outer.request { User-Name := "%{request:User-Name}" } ----
This means that when the authentication fails (as a quirk of the inner session, post-auth{} and the whole reply packet is no available when an inner request Reject's) you have access to the username that was used.
Oh.. wait a minute, unless you mean that there is no way for the inner session, post-auth{} to know the contents of the server's reply in a previous authentication, which seems like a design flow.
*sigh* Think about what is going on and that RADIUS is a *stateless* system. If you want state, put that state into a persistant database.
Would adding the outer.request part that you suggested add an entry in the cache for a successful auth of the inner session?
Reading what I wrote would probably help more.... Just do as I suggested in my previous email and look at the output of 'freeradius -X'. Cheers -- Alexander Clouter .sigmonster says: Alex Haley was adopted!