802.1x authentication - authenticated users not sonsitently showing as online

[Pack3tL0ss]

I agree, either 0 should in fact be unlimited, or it shouldn't be allowed (I can't imagine a valid use-case for effectively disabling authentication system wide... which can be done in more graceful ways).

I'll submit an enhancement request to see if we can get it changed.  For clarification when the sessions were expiring, it would just remove the session information from UAM, it would not actually send a disconnect?  Were the users still online and just not showing up in IMC as such?

Thanks,

PL

[NeilR]

correct - user sessions gone from imc, but switch shows users logged in. 

Switches are procurve 2910al-24g-4XG (W15.14.0007) & 2915-8G-PoE (A15.14.007)

I did a capture using the kick out function to test - I would think it would behave the same as a time based session expiration. (but not see below)

I also set up a show port-access authe clients on repeat. This also shows the port reset, then user reauth

I can see the accounting send the disconnect request and the switch acknowledge admin reset

Then there is an unreachable icmp from imc,

an accounting request w port disabled from switch,

then a disconnect-nak with error cause; unsupported service

The client then requests authentication

a reject message sent: E63018: The user does not exist or has not subscribed for this service.

then about 9 cycles of request/challenge, then accept

then some accounting

User is back on line on the switch and also shown online in imc.  

UPDATE: session expiration

I set session expiration to 180 secs (lock time is 90)

I disable the interface on the workstation to trigger authenctication

see the request challenge packets

then the accounting packets 

User now shows as online in imc

after session expires:

no disconnect requests from imc - switch just restarts access request/challenge

after acceptance, no accounting from imc, which signals user showing as online

some times an accounting interim update, depends on timing

then session expires and repeats

User never shows as online.

SO:

kick out is different then session expiration

radius continues to respond to switch/client requests to auth client, so user comes back online

Subsequent re-auths get no accounting acknowledge to add user to online

Neither kick or session expire really keeps user from re-authenticating anyway, at least on procurve

User session keeps session time from when they logged in - so I can change it w/o killing online sessions - but the expiration/reauth cycle does not reset the timer to a new value if I changed it in the meantime

[Pack3tL0ss]

Thanks for the effort and testing Neil.

I submitted the feature request to change the behavior of the field so that 0 is unlimited.  I'll have to gather some data against Procurve and other devices to see what it's doing at expiration and see if there is a difference and I'll update the request with the details if there is something that needs to be enhanced on the IMC side.

On the 2920 do you have dyn-authorization (required for Radius CoA) enabled against the radius (UAM) server?

radius-server host <UAM IP> dyn-authorization

It may be requesting a CoA to force the re-auth, if it's not enabled that may explain the "unsupported" response.

Again, enhancement request is in, and I'll give them more detail once I gather the data on the session expiration scenario (against multiple device types).

PL

[NeilR]

Thx for the enhancement request.

Yes dyn-authorization is set along with the key and time-window 0. These statements are added when I use the Deploy AAA configuration in User>User Access Policy>Access Device Management>Access Device section, along with the accounting update interval of 3 mins.

The procurves are shown as fully supported on the access device Details screen for Radius accounting

BTW my users are now peristing on line as I expected. Expiration and disconnect are rarely used, but still should work as designed. Good for now.

[Monty101]

Hi Neil,

 I am facing the exact same problem and have read the entire post. but am uncertain as to what you finaly put in place to resolve the issue

Authentication Lock Time(Seconds) = ?

Max. Session Duration(Seconds) = ?

I have a mixture of 2910s, 2920 and 3800 switches do I need to run "radius-server host <UAM IP> dyn-authorization"  on all of my 80 switches ? as i did not do the install and un certain if that was done ?

Thanks in advance

[NeilR]

Hi Monty,

For authentication lock time, I'm using 90 secs.

The help description of this param:

• Authentication Lock Time: A time range from the time the user is authorized to the accounting start time in which the authenticated user cannot be reauthenticated.

does make obvious as to what it does in IMC, which is the time needed to allow the authentication process to complete so UAM can register the user being logged in.

From my observation, this is the time needed once the switch has sent the request to IMC/Radius, for UAM to decide whether to authenticate, send response back to switch, then get the Radius accounting back from the swtich and count the user as logged in.

You probably want it short as possible, but for users to consistently show as logged in each time. Each form of authentication seems to take a different amount of time, ie mac vs 802.1x, and may vary by switch brand or model, and probably UAM load.

the Max. Session Duration param is acurately described in the help. After however many seconds UAM kills the session. Min is 0 (which is not unlimited, as in some other areas) and max is 315360000 which is equal to 10 years.

I'm using 315360000 because I'm using UAM for authenticating phones, network devices and users, so I want the majority of those to stay on-line for as long as needed - not to expire every day or whatever.

I would experiment - the procurve devices kill the session after time expires, and then reauthenticates it again, so the user is online but UAM doesn't show it. Other devices may work differently.  I want to see all the logged in sessions, so I set the max. I think this scenario is covered in my authentication test results post.

Regarding radius, dyn-auth,

When you add a switch as an access device under User > User Access Policy > Access Device Management > Access Device > Add Access Device, UAM adds the necessary statements to your devices. You will want to do this for any device that you plan to use for access control - other IMC features leverage this information.

Make sure you've configured snmp, telnet or ssh etc access previously. But note that if you alread have radius server specified, this step will NOT remove existing, only add IMC as an additional one. You will want to remove any existing entries.

Then when you deploy AAA configuration in

User > User Access Policy > Access Device Management > Access Device > Deploy Configuration- > AAA Configuration the commands for accounting update interval, mac format, 802.1x on/off, and 802.1x mode (EAP or CHAP ) is set on the switch.

Note that you will probably still need other 802 or mac related port commands for your specific switches.

That is what the

User > User Access Policy > Access Device Management > Access Device > Deploy Configuration- > Commands step is for.  You can use this to deploy port specific settings, or in my case I remove the extra Radius entries I was previuously using. Alternatively you could use a template in Service > Configuration Templates to make these settings first,

Then sync ports, and sync with Platform to insure IMC knows what the configuration is.

Sorry I should sum up better in those longer posts as to what the final conclusion was...

[Monty101]

Hi Neil,

Thankyou for the time and effort you put in in your very detailed response.

I will try your suggestions.

Monty