We're still struggling with an ongoing problem to get the caching behaviour we want with FreeRADIUS 3.1.x. With a resumed session, we want to know the User-Name from the inner tunnel. What's the recommended way to do this? With the config we're running (based on the sample config files in the 3.1.x branch in git to enable the tls-cache server) and various calls to stuff attributes in session-state, the session-state can't be grabbed back in the outer post-auth, which is where the decision about user VLAN is made. In packet 13 you can see the inner User-Name is undefined. Any help figuring out our probably-simple mistake would be greatly appreciated. Full debug including server startup and two authentications - the first not resumed, the second is resumed: http://pastebin.com/Ey0PAVBY Sorry about the pastebin - I know that this debug log will be too big to be accepted by the mailing list server. Thanks, Jonathan
With the config we're running (based on the sample config files in the 3.1.x branch in git to enable the tls-cache server) and various calls to stuff attributes in session-state, the session-state can't be grabbed back in the outer post-auth, which is where the decision about user VLAN is made. In packet 13 you can see the inner User-Name is undefined.
Update the session state in inner-tunnel with the username? With Regards Stefan Paetow Moonshot Industry & Research Liaison Coordinator t: +44 (0)1235 822 125 gpg: 0x3FCE5142 xmpp: stefanp@jabber.dev.ja.net skype: stefan.paetow.janet jisc.ac.uk Networkshop44, University of Manchester. Save the date: 22-24 March, 2016. #NWS44 Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800. Jisc Collections and Janet Ltd. is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under Company No. number 2881024, VAT No. GB 197 0632 86. The registered office is: Lumen House, Library Avenue, Harwell, Didcot, Oxfordshire, OX11 0SG. T 01235 822200.
On 24/02/16 12:03, Stefan Paetow wrote:
Update the session state in inner-tunnel with the username?
I think we already are: server inner-tunnel { ... post-auth { ... update { &outer.session-state: += &reply: &outer.session-state:User-Name = &User-Name } } } As recommended in the example inner-tunnel virtual server distributed with 3.1.x, on line 319 https://github.com/FreeRADIUS/freeradius-server/blob/v3.1.x/raddb/sites-avai... Thanks, Jonathan
On Feb 24, 2016, at 8:49 AM, A.L.M.Buxey@lboro.ac.uk wrote:
update outer.session-state { User-Name = &User-Name }
Or, cache the inner User-Name as a *different attribute*. e.g. Inner-User-Name. There's already a User-Name outside of the tunnel, so the cached User-Name is... what, exactly? Inner or outer? It's best to give things explicit names. Alan DeKok.
On 24/02/16 13:49, A.L.M.Buxey@lboro.ac.uk wrote:
Hi,
update { &outer.session-state: += &reply: &outer.session-state:User-Name = &User-Name }
update outer.session-state { User-Name = &User-Name }
?
what does debug show?
With your suggested change, for some reason it does a noop (8) update outer.session-state { (8) &outer.session-state:User-Name = &User-Name -> "iser-linauth@bris.ac.uk" (8) } # update outer.session-state (noop) The outer User-Name should at this point be anonymous@bris.ac.uk so I would expect this update operation to make a change and set &outer.session-state:User-Name to iser-linauth etc. I'm not sure if I'm tying myself in knots here. Basically, in the past we've decided on the user's VLAN in outer post-auth based on their inner username, which we access like %{reply:User-Name} with use_tunneled_reply=yes. This doesn't work with resumed sessions in FR3 like it did on FR2 and we haven't been able to figure out why. We don't want to cache the VLAN number itself, i.e. don't want to make the VLAN decision in the inner post-auth but we do want to cache the inner User-Name so it can be easily accessed later to do the VLAN calculation on resumed sessions. Cheers, Jonathan
update outer.session-state { User-Name = &User-Name }
The outer User-Name should at this point be anonymous@bris.ac.uk so I would expect this update operation to make a change and set &outer.session-state:User-Name to iser-linauth etc.
No. It wouldn't. Because the User-Name is already set, the '=' operation does nothing. Using ':=' instead will overwrite the existing value in the session-state. But, like Alan D says, it's probably best to use your own internal variable (such as Inner-User-Name as per his suggestion) to store the username independently of the session-state one set from the outer session. :-)
We don't want to cache the VLAN number itself, i.e. don't want to make the VLAN decision in the inner post-auth but we do want to cache the inner User-Name so it can be easily accessed later to do the VLAN calculation on resumed sessions.
Which is fair enough. Stefan Paetow Moonshot Industry & Research Liaison Coordinator t: +44 (0)1235 822 125 gpg: 0x3FCE5142 xmpp: stefanp@jabber.dev.ja.net skype: stefan.paetow.janet jisc.ac.uk Networkshop44, University of Manchester. Save the date: 22-24 March, 2016. #NWS44 Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800. Jisc Collections and Janet Ltd. is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under Company No. number 2881024, VAT No. GB 197 0632 86. The registered office is: Lumen House, Library Avenue, Harwell, Didcot, Oxfordshire, OX11 0SG. T 01235 822200.
On Feb 24, 2016, at 9:24 AM, Jonathan Gazeley <Jonathan.Gazeley@bristol.ac.uk> wrote:
With your suggested change, for some reason it does a noop
That's fine.
(8) update outer.session-state { (8) &outer.session-state:User-Name = &User-Name -> "iser-linauth@bris.ac.uk" (8) } # update outer.session-state (noop)
The "update" section isn't a module, and doesn't have the normal module return codes.
The outer User-Name should at this point be anonymous@bris.ac.uk so I would expect this update operation to make a change and set &outer.session-state:User-Name to iser-linauth etc.
I'm not sure if I'm tying myself in knots here. Basically, in the past we've decided on the user's VLAN in outer post-auth based on their inner username, which we access like %{reply:User-Name} with use_tunneled_reply=yes. This doesn't work with resumed sessions in FR3 like it did on FR2 and we haven't been able to figure out why.
We reworked some of the SSL cache, which was required for new features. It *should* continue to work, though. But if you're putting attributes into the session-state list, they will remain there for the lifetime of the authentication session. i.e. NOT the SSL session. The "session-state" list is NOT an SSL cache, and has nothing to do with SSL. The SSL cache remains the same in v3.0 as in v2.2. But again, putting things into session-state does NOT put them in the SSL cache. Alan DeKok.
On 24/02/16 14:38, Alan DeKok wrote:
On Feb 24, 2016, at 9:24 AM, Jonathan Gazeley <Jonathan.Gazeley@bristol.ac.uk> wrote:
With your suggested change, for some reason it does a noop
That's fine.
(8) update outer.session-state { (8) &outer.session-state:User-Name = &User-Name -> "iser-linauth@bris.ac.uk" (8) } # update outer.session-state (noop)
The "update" section isn't a module, and doesn't have the normal module return codes.
The outer User-Name should at this point be anonymous@bris.ac.uk so I would expect this update operation to make a change and set &outer.session-state:User-Name to iser-linauth etc.
I'm not sure if I'm tying myself in knots here. Basically, in the past we've decided on the user's VLAN in outer post-auth based on their inner username, which we access like %{reply:User-Name} with use_tunneled_reply=yes. This doesn't work with resumed sessions in FR3 like it did on FR2 and we haven't been able to figure out why.
We reworked some of the SSL cache, which was required for new features. It *should* continue to work, though.
But if you're putting attributes into the session-state list, they will remain there for the lifetime of the authentication session. i.e. NOT the SSL session. The "session-state" list is NOT an SSL cache, and has nothing to do with SSL.
The SSL cache remains the same in v3.0 as in v2.2. But again, putting things into session-state does NOT put them in the SSL cache.
Alan DeKok.
Thanks, this helps with the clarity. What I think I need to do is store the Inner-User-Name in the SSL cache so when the session later gets resumed, we can use the Inner-User-Name to make a VLAN decision. How can I add specific attributes to the SSL cache? Thanks, Jonathan
Hi,
Thanks, this helps with the clarity. What I think I need to do is store the Inner-User-Name in the SSL cache so when the session later gets resumed, we can use the Inner-User-Name to make a VLAN decision.
why does the VLAN change btw? based onwhere they are connected at the time? alan
On 25/02/16 12:12, A.L.M.Buxey@lboro.ac.uk wrote:
Hi,
Thanks, this helps with the clarity. What I think I need to do is store the Inner-User-Name in the SSL cache so when the session later gets resumed, we can use the Inner-User-Name to make a VLAN decision.
why does the VLAN change btw? based onwhere they are connected at the time?
Based on: - whether they are a Bristol user or a visitor to the campus - whether they have been suspended for being naughty - whether they have authenticated with machine credentials
Hi,
Based on: - whether they are a Bristol user or a visitor to the campus
that wont change vlan from the first auth....
- whether they have been suspended for being naughty
you can clear the cache entry for that user/session :)
- whether they have authenticated with machine credentials
that wont change the vlan either from the first auth. policy should be in the inner-tunnelwhere you deal with the real user info......and if its an external user then the outerid can shove them onto other vlan alan
On 25 February 2016 at 12:19, Jonathan Gazeley < Jonathan.Gazeley@bristol.ac.uk> wrote:
- whether they have been suspended for being naughty
This is the one which means we're reluctant to cache the vlan attribute between authentications. We want to be able to drop people into our "containment" vlan promptly when we get wind of abusive behaviour, and if we're caching the vlan itself they won't get put in the new vlan until the cache entry expires. To make the decision about whether or not the user needs to be "contained" we need their actual username (ie from the inner) and not whatever they happen to tell us their username is in the outer. Which is when we have a "resumed" session which doesn't run the inner (because it's being resumed from the tls cache) we're failing to do the right vlan calculations. Does that make more sense? -Paul -- ---------------------------------------------------------------------- Paul Seward, Senior Systems Administrator, University of Bristol Paul.Seward@bristol.ac.uk +44 (0)117 39 41148 GPG Key ID: E24DA8A2 GPG Fingerprint: 7210 4E4A B5FC 7D9C 39F8 5C3C 6759 3937 E24D A8A2
This is the one which means we're reluctant to cache the vlan attribute between authentications. We want to be able to drop people into our "containment" vlan promptly when we get wind of abusive behaviour, and if we're caching the vlan itself they won't get put in the new vlan until the cache entry expires. If your equipment supports Change of Authorization (CoA) you should be able to handle these cases quite elegantly by putting an "update coa" snippet into the accounting section of the server section that is responsible for those particular NASes. The examples in
sites-available/originate-coa look pretty instructive (sorry, haven't yet done what you intend to do in our environment, so I'm pretty useless with helping you with the exact details put I still think that in theory CoA is the best way to do this). If you have the cached inner user-name, you can use unlang to determine if you want to send a CoA packet for that particular user at that point of time and what VLAN assignment it should contain. The only use case that you mentioned that really needs CoA or some alternative is banning "naughty" users. If CoA is no option, you could also lower the re-authentication interval on your NASes so that the maximum time until the VLAN assignment can be changed is the re-auth interval. I hope that I understood you correctly and that what I write makes sense. :) Christian
On 25 February 2016 at 13:01, Christian Strauf <strauf@rz.tu-clausthal.de> wrote: snip CoA stuff which all looks nice but... If you have the cached inner user-name, you can use unlang to determine if
you want to send a CoA packet for that particular user at that point of time and what VLAN assignment it should contain.
The cached inner user-name is precisely the bit of information we're struggling to obtain :( -Paul -- ---------------------------------------------------------------------- Paul Seward, Senior Systems Administrator, University of Bristol Paul.Seward@bristol.ac.uk +44 (0)117 39 41148 GPG Key ID: E24DA8A2 GPG Fingerprint: 7210 4E4A B5FC 7D9C 39F8 5C3C 6759 3937 E24D A8A2
Hi Paul,
The cached inner user-name is precisely the bit of information we're struggling to obtain :( yes, I was referring to the Jonathan's approach to introduce a separate RADIUS attribute e.g. "Inner-Tunnel-User-Name" or something similar that you could set with the inner user name during the authentication process. That together with CoA very likely solves your problem.
Christian
On 25/02/16 13:22, Christian Strauf wrote:
Hi Paul,
The cached inner user-name is precisely the bit of information we're struggling to obtain :( yes, I was referring to the Jonathan's approach to introduce a separate RADIUS attribute e.g. "Inner-Tunnel-User-Name" or something similar that you could set with the inner user name during the authentication process. That together with CoA very likely solves your problem.
Yes, I introduced a new attribute Inner-User-Name and I am setting a value in the inner tunnel server. However, this does not get saved to the SSL/TLS cache so when there is an authentication for a resumed session, we can't access that attribute. I'm trying to figure out how to cache other stuff with the TLS attributes that can be pulled back later on. Thanks, Jonathan
On Feb 25, 2016, at 8:28 AM, Jonathan Gazeley <Jonathan.Gazeley@bristol.ac.uk> wrote:
I'm trying to figure out how to cache other stuff with the TLS attributes that can be pulled back later on.
The TLS caching in v2 is (a) just a few hard-coded attributes, or (b), files on disk. The explanations in the EAP module work. For v3.0, the same largely applies. We've re-worked the on-disk TLS cache a bit, but it *should* work identically. We've also added a cache module, which can cache just about anything. In 3.1, we've gotten rid of the on-disk TLS cache, and expanded the cache module to cache to just about anywhere... including disk. So the functionality is at least equivalent, if a little different. So... what's going wrong? Alan DeKok.
On 25/02/16 13:42, Alan DeKok wrote:
On Feb 25, 2016, at 8:28 AM, Jonathan Gazeley <Jonathan.Gazeley@bristol.ac.uk> wrote:
I'm trying to figure out how to cache other stuff with the TLS attributes that can be pulled back later on.
The TLS caching in v2 is (a) just a few hard-coded attributes, or (b), files on disk. The explanations in the EAP module work.
For v3.0, the same largely applies. We've re-worked the on-disk TLS cache a bit, but it *should* work identically. We've also added a cache module, which can cache just about anything.
In 3.1, we've gotten rid of the on-disk TLS cache, and expanded the cache module to cache to just about anywhere... including disk. So the functionality is at least equivalent, if a little different.
So... what's going wrong?
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 } 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... In outer post-auth we are doing this to copy the session-state back before acting upon the information: update { &reply: += &session-state: } Here's today debug log: http://pastebin.com/ZD1nmAvC 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. Contrast to line 4014 which is a non-resumed session and the debug clearly shows that session-state contains useful things which are then copied to the outer. Thanks, Jonathan
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.
On 25/02/16 15:15, Alan DeKok wrote:
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.
Yes, this is an artifact of debugging (I added Inner-User-Name as you suggested, and didn't (yet) remove the other User-Name).
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...
We are.
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 think there is some odd behaviour going on here. Inside cache_tls we've tried several configs with different results: First we tried uncommenting the section that adds the session-state to the TLS cache: update { &session-state:TLS-Session-Data := &session-state:TLS-Session-Data &session-state: += &session-state: } The debug log did not show any mention of the session-state being copied. We tried a different syntax that Arran had used previously [1]: update { &session-state:TLS-Session-Data := &session-state:TLS-Session-Data &session-state: += &session-state:[*] } The debug log did not show any mention of the session-state being copied. We tried explicitly setting Inner-User-Name to a string update { &session-state:TLS-Session-Data := &session-state:TLS-Session-Data &session-state:Inner-User-Name := "banana" } This worked and we were able to retrieve the string "banana" from the TLS cache in a resumed session. So we tried populating Inner-User-Name from a variable: update { &session-state:TLS-Session-Data := &session-state:TLS-Session-Data &session-state:Inner-User-Name := &session-state:Inner-User-Name } This didn't work as it seems the cache_tls module is called in packet 4, i.e. before the server has started to process the inner tunnel (which is where Inner-User-Name is assigned). How can we place the Inner-User-Name into the TLS cache? Arran's email [1] suggests that anything you wish to place in the TLS cache must be stored in session-state before the TLS session is frozen. However what seems to be happening is the TLS cache entry is created at the beginning of the TLS session and then not updated. Please can you shed some light on this behaviour, and whether it is possible to add an attribute to an existing cache entry in the inner post-auth section?
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.
Thanks. I understand the differences between the TLS cache and the session-state cache. It's hard to use one without the other and I think I'm having difficulty explaining myself. Thanks, Jonathan [1] http://lists.freeradius.org/pipermail/freeradius-users/2016-January/081598.h...
On Feb 25, 2016, at 11:16 AM, Jonathan Gazeley <Jonathan.Gazeley@bristol.ac.uk> wrote:
This didn't work as it seems the cache_tls module is called in packet 4, i.e. before the server has started to process the inner tunnel (which is where Inner-User-Name is assigned).
The cache_tls module is there so that it can cache / replay the TLS attributes. So that you can use the TLS-Cert-* attributes on the resumed session. You can add a cache module which is specific to your needs. Put it into post-auth, so that it caches the Inner-User-Name.
How can we place the Inner-User-Name into the TLS cache?
Update the "cache" module configuration to cache Inner-User-Name. Then, ensure that the cache is updated when the Inner-User-Name is available. While there are a lot of moving pieces, a careful approach to system design helps. If the Inner-User-Name is only available in post-auth... well... put a cache module there to cache it.
Arran's email [1] suggests that anything you wish to place in the TLS cache must be stored in session-state before the TLS session is frozen. However what seems to be happening is the TLS cache entry is created at the beginning of the TLS session and then not updated.
That's not how the module && virtual server are supposed to work. They *were* tested before being put into git, so they should work.
Please can you shed some light on this behaviour, and whether it is possible to add an attribute to an existing cache entry in the inner post-auth section?
You can always cache a new attribute. Just add it to the configuration for the cache module. Alan DeKok.
On 25/02/16 13:42, Alan DeKok wrote:
On Feb 25, 2016, at 8:28 AM, Jonathan Gazeley <Jonathan.Gazeley@bristol.ac.uk> wrote:
I'm trying to figure out how to cache other stuff with the TLS attributes that can be pulled back later on.
The TLS caching in v2 is (a) just a few hard-coded attributes, or (b), files on disk. The explanations in the EAP module work.
For v3.0, the same largely applies. We've re-worked the on-disk TLS cache a bit, but it *should* work identically. We've also added a cache module, which can cache just about anything.
In 3.1, we've gotten rid of the on-disk TLS cache, and expanded the cache module to cache to just about anywhere... including disk. So the functionality is at least equivalent, if a little different.
So... what's going wrong?
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 } 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... In outer post-auth we are doing this to copy the session-state back before acting upon the information: update { &reply: += &session-state: } Here's today debug log: http://pastebin.com/ZD1nmAvC 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. Contrast to line 4014 which is a non-resumed session and the debug clearly shows that session-state contains useful things which are then copied to the outer. Thanks, Jonathan
Yes, I introduced a new attribute Inner-User-Name and I am setting a value in the inner tunnel server. However, this does not get saved to the SSL/TLS cache so when there is an authentication for a resumed session, we can't access that attribute.
I'm trying to figure out how to cache other stuff with the TLS attributes that can be pulled back later on. Do you receive the inner User-Name in accounting packets (e. g. because you copied it with the "session-state" mechanism into the Access-Accept reply)? If so, you can do CoA without any caching because the NAS sends the correct username in accounting packets anyhow. You can work with those User-Names in the accounting section and hence to CoA there. Would that work for you?
Christian
On Feb 25, 2016, at 7:29 AM, Paul Seward <Paul.Seward@bristol.ac.uk> wrote:
On 25 February 2016 at 12:19, Jonathan Gazeley < Jonathan.Gazeley@bristol.ac.uk> wrote:
- whether they have been suspended for being naughty
This is the one which means we're reluctant to cache the vlan attribute between authentications.
In 3.1, you can update the cache remotely, especially if you use redis or memcached. That can be used to delete existing sessions. Or, use CoA, and if the server receives a CoA, delete the cache entry for that user. That way you can nuke the cache by sending a CoA or Disconnect-Request to the server.
To make the decision about whether or not the user needs to be "contained" we need their actual username (ie from the inner) and not whatever they happen to tell us their username is in the outer.
Exactly.
Which is when we have a "resumed" session which doesn't run the inner (because it's being resumed from the tls cache) we're failing to do the right vlan calculations.
If you cache the Inner-User-Name, and key off of that for all VLAN decisions, you should be safe. e.g. 1) authenticate user, update Inner-User-Name a) cache this b) in post-auth, send VLAN based on Inner-User-Name 2) on resumption a) get Inner-User-Name from the cache b) in post-auth, send VLAN based on Inner-User-Name Alan DeKok.
participants (6)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Christian Strauf -
Jonathan Gazeley -
Paul Seward -
Stefan Paetow