I'm hoping someone can assist with a knowledge gap I have within the area of Guest authentication. The scenario I have is that we have an SSID configured for use by Guests, which is using an ACS server with a Windows Database to provide the authentication.
From my understanding the connectivity runs as follows:
--A client connects to the SSID, receives an IP address and attempts to connect to a webpage. --The WLC will intercept the http(s) connection and provide the client with the configured authentication page. --Client will provide their Windows AD Username and password into the webpage, WLC will forward these credentials to the configured Radius server (a Cisco ACS device with a Windows external database configured), providing the details are correct, the authentication will be allowed, with the client set to run state on the WLC with the client forwarded to their original webpage. --Within our WLCs, we currently have the 'Enable Session Timeout' option unselected, which to my mind means once the client has authenticated, they will not be prompted for authentication again unless they logout via the https://*.*.*.*/logout.html webpage
What I'm trying to understand is, under what additional scenarios would a client then have to re-authenticate (if at all);
--A client roam between Access Points managed by different Controllers, but all controllers tunnelled to the same Anchor controller and all in the same Mobility Group. --When a client disconnects from the network, but reconnects with the same DHCP assigned IP address (Is there a separate timeout value within the WLC that would drop this connection, based on there being no activity ?). --When a client disconnects from the network, but reconnects with a different DHCP assigned IP address.
Ideally, and I've been unable to find this myself, is there any documentation that details the session connection from an end-to-end perspective. I'm looking to understand in greater detail what connection detail the Anchor WLC keeps so that it's able to identify the connected client, and how it keeps this client connection alive.
Your client shouldn't have ti login again on a roam. The only time they should have ti us if the exceed the user idle timeout which is 300 seconds(5 minutes) by default. So if they close their laptop or leave the facility for 5 mins or longer when they come back they would need to login again
Sent from Cisco Technical Support iPhone App
Please remember to rate useful posts, and mark questions as answered
The thing here is that various clients act differently. As far as what you have, you are correct on. The other thing is that you have an idle timeout which will remove the client if the wlc doesn't see anything from the client within 300 seconds (default). I have always been able to test various webauth pages by disabling the adapters and enabling them back on. Again, this might work on some devices and not others. If you increase the idle timeout, the device can be away for that set amount of time and not have to log back in.
It looks like it needs to be the User Idle timeout that we need to alter. Having read a little more regarding that, would this need to be set on the Controllers that manage the Access Points rather than Anchor Controller. It appears the Idle timeout is based on conmmunication between the AP and the Controller, but obviously the User session is held open on the Anchor controller. Or should I alter on all controllers?
IntroductionHow to use the Wireless LAN Controller Configuration Analyzer (WLCCA)
Javier Contreras is a Senior Tech Lead for the Wireless Business Unit in Cisco, with over 2 decades of experi...
< PRE >
(#)For this reason being that : - application that doesn't use multicast, sends one copy of each packet ( data unit of traffic at layer 3 ) to each client (" who seeks the traffic ).- application that does use multicast, sends ...
Transferring Crash file from standby:
Login to the Active WLC in HA.
(Cisco Controller) >transfer upload datatype crash
(Cisco Controller) >transfer upload filename <Desired filename>
(Cisco Controller) >transfer up...