If I had a better workaround I would have already given it to you and
the customer that was hitting it last time :)
I guess you could write a custom check to latch onto something for the
NSS defs, but that won't stop the fact that the agent latches onto NSS
and not the full Symantec version on the client.
Nate
Homer Manila wrote:
On the phone with TAC now, but if you have any suggestions for a quick
workaround that wouldn't force us to have to re-engineer our AV defs
requirement to not bother with NSS (which I believe would mean
re-creating checks for every supported AV the ANY AV rule currently
supports) or just outright stop requiring up-to-date defs...that would
be greatly appreciated :)
--Homer Manila
Information Security Administrator
Information Technology, American University
202-885-2209
Nathaniel Austin wrote:
Hey Homer,
Weird that it doesn't show there. It should.
As for a way to handle it, the only workaround is unfortunately to
uninstall NSS. The agent should be able to check for NSS definition
updates, but our database bases their defs off the same date as
normal SAV defs (which they are different and not updated that
frequently) so I have found that the date checks don't work well for
NSS.
Bug hasn't been assigned to a developer yet, so not sure of a
timeline on when it will be fixed, but it will need a new underlying
SDK for the agent, so it more than likely require a new agent to fix.
Nate
Homer Manila wrote:
Thanks Nate. Actually, the list I was going by was on the manager:
Device Managment -> Clean Access -> Clean Access Agent -> Rules ->
AV/AS Support Info
That list doesn't show it supported anyway, and if I remember
correctly, it updates with every new version of the agent being
deployed, yes?
Thanks for the bug info. Apparently, it's affecting more of our
users than I original thought. May have to call Cisco on best way
to handle this....
--Homer Manila
Information Security Administrator
Information Technology, American University
202-885-2209
Nathaniel Austin wrote:
Hey Homer,
It is on the supported list:
Norton Security Scan / 1.x / yes (4.1.3.0) / yes (4.1.3.0) / -
As to the problem, I repro'd this here a little while ago. We
should be able to detect both NSS and a normal Symantec AV at the
same time, but we don't. I filed CSCso76507 on the issue.
Nate
Homer Manila wrote:
We just forced an upgrade of the CCA agent this morning to
4.1.3.2, and began getting a few complaints from our users about
not being able to log in despite having very much up-to-date
definitions of Symantec AntiVirus. Turns out that the new agent
was now seeing a "Norton Security Scan," with differing product
version #s and defs versions(sometimes none). A quick google
found that this product was bundled with Google Pack a little over
a month ago, and would explain how the product got onto our
clients' machines without our knowledge. Apparently, the new
agent is seeing Norton Security Scan instead of our standard,
tested, supported SAV bundle. Removal of NSS fixes the problem
and allows the user onto the network.
Question: how is CCA seeing this product if it isn't even in the
supported list of AV?
