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?
>>>>>