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:[log in to unmask]] On Behalf Of Miller, Paul
Sent: Wednesday, July 09, 2008 8:52 AM
To: [log in to unmask]
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:[log in to unmask]] On Behalf Of Jay Patel
Sent: Wednesday, July 09, 2008 10:35 AM
To: [log in to unmask]
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:[log in to unmask]] On Behalf Of Anthony DeCerbo
Sent: Wednesday, July 09, 2008 11:05 AM
To: [log in to unmask]
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
|
