Hi Daniel,
Thanks for the lengthy post. You are correct, most issues are
resolvable. And we are looking at doing these, but they are wanting to
deploy faster then I would like until I have solutions for each of these
issues. We spent the money and had a Cisco Platinum partner do the
initial design and implementation, based on our network topology. So we
believe that our vlans and such are correct. But I will look at the
router tables on the CSA/CAM's to verify they are correct, thanks for
the tip. We have are login script(kix) waiting until it can reach a
server, prior to mapping the users drives. This seems to work
satisfactory. We too are looking for something to sense when a wired
connection and turn off the wireless. We have CSA installed in our
environment and believe an upgrade actually has this functionality that
we can leverage. However to upgrade is a longer process and does not
coincide with our implementation of our NAC. However maybe this should
be considered. So it sounds like we are on the same page. Mostly this is
a users perspective issue, and believe it is the hardest thing to
overcome. 
On a side note how did you deploy the agent to the users. Did you hide
the desktop and tray icons? We have not that ourselves.
Your input is much appreciated and provides me with some ammunition to
pass up the chain. 

-David

-----Original Message-----
From: Cisco Clean Access Users and Administrators
[mailto:[log in to unmask]] On Behalf Of Daniel Sichel
Sent: Tuesday, September 30, 2008 11:41 AM
To: [log in to unmask]
Subject: Suggestions on deployment, topology and agent issues

> 
> We are a medium commercial business, and currently trying to deploy
NAC
> =
> in our environment. We are running into various issues, mainly due to
=
> the fact that users do not want anything to interfere with the work. =

> Things like having to wait until the CCA completes is validation
checks
> =
> before they can start any applications is causing a headache. Also the

> = fact that users sometimes have there wireless enable when they 
> connect = to their docs and the CCA cannot connect to the CAM causes 
> and issue,
=
> and a reboot is required. (we dont want the user to see the icon so we

> = removed it, thus they cannot stop & start the agent themselves, thus

> the = reboot). There are other small issues but to a user is it big. 
> We are
=
> afraid that this will not go over well with the population but at the
=
> same time we want the security of what NAC an provide. So if anyone in

> a = similar situation has any ideas to make this go more smoothly 
> would be = helpful.
> 
> Thank you
> 
> David Maas
> Sr. Security Engineer
> Merkle Inc
> 

The connectivity to the CAM should be resolvable if you configure your
vlans properly and have some type of routing device available. Clean
Access does some weird stuff to Ethernet to work right and a proper
topology is critical.  Check the click router tables on the Clean Access
units, there used to be a bug that broke Clean Access (don't ask how I
know, just trust me) but the current version resolves that.
Connectivity, when properly set up does work. Finding the proper
topology for your environment to support it however, can be a real
journey of personal discovery. For the wireless part, we are looking for
a utility to sense a wired connection and turn off wireless when it is
connected. My Toshiba Portege does this automatically,  my Dell
Inspirons don't. 

As to your issue of starting applications there is one answer, but IMHO,
it sucks and we WON'T do it here. You allow access, rather than deny it,
during the Clean Access validation; thereafter removing any unqualified
machines to quarantine. This gives hackers about two minutes or so of
access each time they connect. Not OK. This is also the only way to have
log in scripts work normally. We are using a script (compiled to exe
format) that runs from the start up folder automatically to run the log
in script later in the process after validation, allowing the first
attempt to fail. The script also stops and then restarts file
synchronization. This is only a so so solution. I was going to have the
stub agent launch the script as part of remediation, but Cisco nailed me
there too. Everything the stub agent runs for non admin users seems to
run with the user SYSTEM credentials. That means that drive mappings, or
any other activity are done for user SYSTEM, not the logged in user.
This leads to the curious situation where a user sees all network drives
as disconnected, but they cannot be remapped by the user(error 53), and
oddly, when you click on them in Windows, they work. However any
application or automation that references them will almost certainly
fail, since they are reported as disconnected for the user (Some guy
named SYSTEM has already mapped those drives, so you can't). The Cisco
solution for the moment, is to use a fairly lame mechanism involving two
scripts and allowing unvalidated machines access to the SYSVOL share.  I
have heard there are supposed to be some fixes in an upcoming release
for this issue. BTW, the guys at TAC were incredibly patient and
persistent in helping me ascertain this information. 

It sounds like you can resolve your issues, but it may take some doing.
The manual is incredibly unhelpful on the topology issue, it seems
contradictory or at best, muddled. I would suggest calling TAC, but you
may need to be REALLY insistent that you are NOT going to reconfigure
your entire network for this, you just need them to make it work for
you. They are quite ingenious at getting it going. I also finally broke
down and took the CANAC class. It was really helpful, I had a good
instructor and seeing the other people in the class have their labs blow
up the way my test system at work did was most instructive. There are
work arounds for most issues, and a class can really help you find them.


Sorry for the long post, but there are big issues with Clean Access in
the corporate environment and I wanted to let you know you are not
alone, and that the issues are resolvable. 

Cheers,


Daniel Sichel, CCNP, MCSE,MCSA,MCTS (Windows 2008) Network Engineer
Ponderosa Telephone (559) 868-6367