We have been living with a similar situation here but the catch for us is that what is really happening is that Joebob logs in to CCA, uses the laptop for 10 minutes, then closes the cover. Then he walks over to another building on campus and opens the cover (this is true also if he shuts down and restarts in the same scenario). When he gets to the next building, he attaches to the wireless SSID, gets a DHCP address in the same vlan he was in previously (but a DIFFERENT IP address and that is KEY) and the CCA agent doesn't know what to do with him. It sees that Joebob is logged in with address blah 10.105.0.150 10 minutes ago, and so the agent thinks he is logged in - but now his address is 10.105.0.151 and so while the agent THINKS he is logged in, he has no network access using the 10.105.0.151 address.
Our lease times on the DHCP server are long - the practical problem is that the laptop (Lenovo using their wireless software) actually sends a DHCP release to the DHCP server when the lid is shut or when windows is turned off, so he released 10.105.0.150 when he left building A (and some other user got it before he got back on the network). Clean access agent (4.1.3.1) doesn't seem to clue in to the IP address changing underneath it. The user has to log out of the agent manually (and then it pops up and prompts for login just like it is supposed to) and then he is back on the network in his appropriate role at 10.105.0.151. Where this is scary is when user A has one role at 10.105.0.100 and user B has a different role at 10.105.0.101 (based on their user identities, not their IP addresses) but if user A and B both shut down their laptops, and user B opens his first and happens to get 10.105.0.100, the CCA agent treats him like user A as far as agent behavior is concerned (the screen he gets, etc) without him authenticating as user A or B under that 2nd address. From our testing, users in this scenario have no real network access, it's just that the agent is a little confused about which role they occupy. We were told in January that this was a huge bug but required a fix in the server software not the agent and was somewhere on their roadmap. In the meantime, our workaround is that this summer we will create almost 1000 DHCP reservations to lock down a given laptop to a specific IP address so that our users can move around campus without having to constantly kick the agent and let it know it needs to ask them to log in. (We can't ditch the Lenovo software because our users are attached to it) DHCP reservations. Sucks, huh? -faith -----Original Message----- From: Cisco Clean Access Users and Administrators [mailto:[EMAIL PROTECTED] On Behalf Of Miller, Paul Sent: Wednesday, July 09, 2008 8:52 AM To: [email protected] Subject: Re: Clean Access Agent Logout Issues I have also seen this. What happens here is that when the user goes from one vlan to another, they are not able to login until I clear their previous connection. I setup the heartbeat timer and it seems to help, but is not 100%. Paul Miller Network Administrator Dominican University -----Original Message----- From: Cisco Clean Access Users and Administrators [mailto:[EMAIL PROTECTED] On Behalf Of Jay Patel Sent: Wednesday, July 09, 2008 10:35 AM To: [email protected] Subject: Re: Clean Access Agent Logout Issues I seem to see this, though it is hard to trace as most users don't roam. Please keep us updated. ---- -----Original Message----- From: Cisco Clean Access Users and Administrators [mailto:[EMAIL PROTECTED] On Behalf Of Anthony DeCerbo Sent: Wednesday, July 09, 2008 11:05 AM To: [email protected] Subject: Clean Access Agent Logout Issues Has anyone experienced issues with the agent not logging users off when they do a restart, shutdown or logoff in Windows? We have several people who have experienced the issue however it seems to be intermittent. We are very concerned about this because we have several shared machines and we don't want people to remain logged into them when they leave. I have opened a TAC case with Cisco about the problem but they have not been much help. Thanks, Anthony
