Security

I have a need to time out a user who is in the default role of a aaa profile. Basically I need to have auth re-try every min. Unfortuately the reauthentication interval is not triggered unless a user had been authenticated. 

I have changed the Logon user lifetime to be 1 min and this appears to work. The user auth is re-attempted every min. 

So far from what I can tell is that this affects users who fall into the initial role or fail the auth on a aaa profile.

There isn't a lot of comprehensive info on this timer setting.

So, what if anything will break by changing this timer value?

We are seeing alot of our Guest users are staying on the logon role as well and they are consuming alot of the IP addresses available.

To test it I associated to the guest SSID and didn't authenticate.  So my device in on the Logon role.  The age on the user states 22 mins. but it's still there.  

How can we control the amount of time that a user sits in the logon role before his session is dropped?  This controller that I'm testing on has the Logon user lifetime set to 5 mins.

---

@turner wrote:

I have a need to time out a user who is in the default role of a aaa profile. Basically I need to have auth re-try every min. Unfortuately the reauthentication interval is not triggered unless a user had been authenticated. 

I have changed the Logon user lifetime to be 1 min and this appears to work. The user auth is re-attempted every min. 

 

So far from what I can tell is that this affects users who fall into the initial role or fail the auth on a aaa profile.

 

There isn't a lot of comprehensive info on this timer setting.

 

So, what if anything will break by changing this timer value?

---

Turner, 

The "logon-lifetime" timer will affect only the unauthenticated users and will have no effect on the authenticated users. 

The "aaa timers logon-lifetime" applies ONLY to users in the "logon" role.  It does not apply to users in other "initial roles" - only the role specifically called "logon".

The behavior of the feature is that any user in the logon role will have the L3 session deleted if transition to another role has not happened within the configured time interval.

So the Logon User Lifetime (min) setting under Configuration> Security> Authentication> Advanced only applies to the logon role?

If so, I should be able to test it by associating to an SSID with the initial role set to logon and not authenticate.  This should drop my session within 5 minutes since that's what I have it set to correct?

I tested connecting to an SSID that uses the initial role as "logon" and it has been 13 mins, but the user is still present.  Does this setting overwrite the DHCP scope lease time?

I tested the idle timeout, which is set to 5 mins, and that did work.  

The user should not still be present.  The controller should have deleted the L3 entry in the datapath.  Note that it won't disconnect the user at L2, but there should be no entry in "show datapath session" for the IP address of the user.

I don't believe it does anything to the DHCP lease time.

Well - this turned out to be a timely question.  We just finished a 30 minute discussion involved 4 developers and one product manager to figure a few things out. :)

First, we're not going to be changing the behavior in 6.2 as I previously stated.  After pointing out all the places where that would break existing networks, the developers have decided to revert that change and leave it alone.

Second, we're trying to figure out if this logon-lifetime is even useful, or if it should be removed from the product entirely.  Their feeling is that idle-timeout can take care of the problem, and that there's no need to have two different cleanup timers running concurrently.  So to that end - could you tell me more about your original requirement, which was to time out a user who is in the default role of an aaa profile?  What are you trying to do?

Thanks

-Jon

I dont want to hijack this thread but was wondering if a solution was found for guests sitting in the initail role.  I have hundreds of IP's consumed with users camping in the initial role and never authenticating as well.

Thanks

What we and the original poster is trying to do is avoid the users stuck in the logon role to use/waste ip addresses from the dhcp scope.  Sometimes we have even 70+ users stuck in this role and using ip addresses.

I've tested the logon-lifetime setting and it doesn't seem to kick users off.  The idle timeout does work, but only when the user doesn't ping anymore.  So this issue would still be present if the user is reponding, but not authenticating.

What we need is a better way of kicking users off fromthe logon role so they don't use up ip addresses.

Well this is actually a conversation that has come over from the S3500 side of things, so hopefully it is still relevant.

So far the logon lifetime timer being set to 1 min is working for us.
 
What Brandeis is trying to accomplish is to have a user in a mac auth profile re-attempt authentication every min after a failure. Why? Because we have device registration server that uses a captive portal to register the users mac addr. Once the registration is successful the user needs to have the role changed. When a user is in the default role for the aaa profile the re-auth timer won't trigger.

What I have seen is that this DOES work. (we are on AOS 7.1.1 (mobility switch))
Feb 14 12:11:36 :522005: <INFO> |authmgr| MAC=00:24:e8:a9:55:6a IP=10.64.129.105 User entry deleted: reason=logon role lifetime reached
Feb 14 12:12:36 :522005: <INFO> |authmgr| MAC=00:24:e8:a9:55:6a IP=10.64.129.105 User entry deleted: reason=logon role lifetime reached

That user was not in the logon roll but a default roll from the aaa profile.

Here is a time diagram of what happens.