cancel
Showing results for 
Search instead for 
Did you mean: 

VSE 8.7i Crypt32 errors when using Proxy / ISA Server

Hi,

Does anybody know why all McAfee VSE8.7 clients try to connect to the following internet IP address.

Destination: External (65.55.21.250:80) Microsoft Corp.
Destination: External (81.23.243.136:80) Akamai Technologies.
Destination: External (87.248.201.177:80) Limelight Networks Inc.
Destination: External (92.122.216.185:80) Akamai Technologies.

Our ISA Server action is 'Denied Connection' because:

1. VSE 8.7i connects on port 80 instead on port 8080.
2. Also VSE 8.7i does not give a Client Username.

As result we have to wait for a long time at the "Applying computer settings" screen.
The only resolution is to give all the client anonymous access to all these sites!!!
After one succesfull connection the problem is gone?
Is this some kind of Spyware?
The Documentation/Manual doesn't tell anything about this.
Also the System requirements do not tell you need a direct internet connection.
There isn't an option for Proxy settings in VSE 8.7i.
[C:\>PROXYCFG -u] can get the Internet Explorer settings but this isn,t an option for a lot of clients.
Also the client default gateway isn't always the Proxy server.

McAfee told that it is a Microsoft problem?
Give the computer direct internet access or uninstall Root Certificate Service on all your clients!!!
Thats a bit of a problem for more then 100 clients!

Look at McAfee Corporate KnowledgeBase ID: KB53970
Published: October 16, 2008

https://kc.mcafee.com/corporate/index?page=answerlink&url=https%3A%2F%2Fkc.mcafee.com%3A443%2Fcorpor...
17 Replies
Reliable Contributor rmetzger
Reliable Contributor
Report Inappropriate Content
Message 2 of 18

Recurring problem. Could this be Artemis?



Spyware? I am not convinced.

I wonder if the Artemis Technology is kicking in, testing connectivity at startup. Just a thought.

If it is Artemis kicking in at startup, possibly forcing it off might be a solution. Under Heuristic network check for suspicious files, set the desired Sensitivity level to OFF. Locate this setting in On-Access, On-Demand, and eMail Scan:

From https://kc.mcafee.com/corporate/index?page=content&id=KB53732&pmv=print points out that the Artemis Technology is by default Off.

Solution 1
By default Artemis Technology is disabled in VirusScan Enterprise (VSE). To enable Artemis Technology for On-Demand Scan and On-Delivery Email Scan:

VirusScan Enterprise 8.7i -

On-Demand Scan policy:

1. Click Start, Programs, McAfee, VirusScan Console.
2. Double-click On-Demand Scan and select the Performance tab if necessary.
3. Under Heuristic network check for suspicious files, set the desired Sensitivity level.
4. Click OK.

On-Delivery Email Scan policy:

1. For On-Delivery Email Scan mode, Artemis Technology is enabled via a dialog box as described below and in a corresponding ePO configuration screen.
2. Click Start, Programs, McAfee, VirusScan Console.
3. Double-click On-Delivery Email Scan and select the Scan Items tab if necessary.
4. Under Heuristic network check for suspicious files, set the desired Sensitivity level.
5. Click OK.

On-Access:

Enabled via a SuperDAT. Customers who wish to obtain this should contact their Technical Account Manager (TAM) or Support Account Manager (SAM).

Solution 3
ePolicy Orchestrator (ePO)

Platinum customers can roll out Artemis Technology using ePolicy Orchestrator (ePO) 3.6 or later. When checking in packages to ePO, there are three options; Current, Previous and Evaluation. The default is for all clients to use Current . To stage roll outs, you can assign a group of machines to update from evaluation. You can then check in the SuperDAT as evaluation.


To enable Artemis Technology for On-Demand Scan:and On-Delivery Email Scan using ePO:

ePolicy Orchestrator 4.0 - On-Delivery Email Scan policy

1. From ePolicy Orchestrator, click the Systems tab, the Policy Catalog tab and select the VirusScan Enterprise 8.7.0 On Delivery Email Scan Policy.
2. Select to edit the policy for Server or Workstation.
3. Select the Scan Items tab and under Heuristic network check for suspicious files, select the Sensitivity level.
4. Save the policy.

ePolicy Orchestrator 4.0 - On-Demand Scan task.

1. From ePolicy Orchestrator, select the Systems tab, then the System Tree tab.
2. Select the Client Tasks tab and click New Task.
3. Type a new name and select the On Demand Scan (VirusScan Enterprise 8.7.0) task type and click Next.
4. Select the Performance tab and under Heuristic network check for suspicious files, select the Sensitivity level.
5. To schedule the task to run, click Next.
6. To review and save the task, click Next again.


ePolicy Orchestrator 3.6.1 - On-Delivery Email Scan policy.

1. From the ePolicy Orchestrator directory structure, select the Policies tab and for the On Delivery Email Scan policy, click Edit.
Click New Policy if one does not exist; type a new name and click OK.
2. To edit a Policy, click the relevant Policy Name.
3. Select to edit the policy for Server or Workstation.
4. Select the Detection tab and under Heuristic network check for suspicious files, select the Sensitivity level.
5. Save the policy.


ePolicy Orchestrator 3.6.1 - On-Demand Scan policy.

1. From the ePolicy Orchestrator directory structure, select the Tasks tab, then right-click Schedule Task.
2. Type a new task name, select VirusScan Enterprise 8.7 On Demand Scan task, and click OK.
3. Right-click the task and select Edit Task.
4. Click Settings, select the Advanced tab and verify the Inherit check box is not checked.
5. Under Heuristic network check for suspicious files, select the Sensitivity level.
6. Click OK and then OK again


I might test this on 1 or 2 PCs and sense the network reaction during boot.

Since I do not currently have this problem, it is hard to replicate the problem. I have been reading about this issue for some time now, and I cannot think of any other item which would be in v8.7i that might cause this. I am curious if this suggestion helps (or at leasts helps diagnose the issue leading to a better solution).

Ron Metzger
Thanks,
Ron Metzger

Was my reply helpful?
If this information was helpful in any way or answered your question, will you please select Accept as Solution in my reply and together we can help other members?

Thanx

I will look at that new option!

Hope it is the problem.

Greetz,

Snarf

RE: Thanx

I've got the same problem, log on to restrictive domain account stops on "Applying computer settings" screen for about 2-4 minutes. I did what was mentioned above but with no result. Only rollback to 8.5 helps... It's strange becuase log on to administrator privileges account resolves the problem for 8.7i.
Reliable Contributor rmetzger
Reliable Contributor
Report Inappropriate Content
Message 5 of 18

RE: Thanx



Hi Dominik,

Since Snarf has not replied yet as to his/her results, I do not know if my suggestions helped.

However, since you have found that logging in as an Administrator resolves the delay, I would follow up with this and ask if you know why the Administrator account gets through quickly, but not other limited accounts?

For instance:
1) Are the client PCs accessing the Internet via a proxy server, such as ISA?
2) Are Firewall restrictions in place and are these restrictions relaxed for Administrators?
3) Can you review and identify any firewall or router 'failures or denials' in the appropriate logs?
4) If so, can you identify the ports used and possibly opening these up (based on whether they are incoming or outgoing traffic, using UDP or TCP as listed in the log)?

My suspicions is that (if my theory is in play) that VSE 8.7i (Artemis technology?) is checking 'Root Certificates' and failing (timing out) causing the delay. The question is why is it failing and how to overcome this challenge?

Hope this is helpful, and please let us know your results or additional questions.

Thanks,
Ron Metzger
Thanks,
Ron Metzger

Was my reply helpful?
If this information was helpful in any way or answered your question, will you please select Accept as Solution in my reply and together we can help other members?

RE: Thanx



Hi Ron

Thanks for your answer

Yes, the client PCs are accessing the Internet via proxy with user/password authorization (domain\username, password). I cannot check firewall logs because it is managed elswere by other company. I checked ip addressess pointed by Snarf and i cannot ping only 65.55.21.250 (i thing this address is invaild). I checked application log using limited account and administrator account. First difference is on administrator account there are no crypt32 errors. I tried to use proxycfg on limited account but this didn't resolve the problem.

Today i updated Virusscan to 8.7i on two pcs (notebook and desktop). I found that on notebook the problem didn't occur, the crypt32 errors are still there (so 1/5 works ok...., i've got 125 more to test). And i cannot find why it works...

RE: Thanx

I requested to give access on firewall to:

Destination: External (81.23.243.136:80) Akamai Technologies.
Destination: External (87.248.201.177:80) Limelight Networks Inc.
Destination: External (92.122.216.185:80) Akamai Technologies.

And for now this is the only way to resolve this problem. But from security point it is not acceptable... I cannot request to give access to whole company network. I still don't now why mcafee 8.7i on one of the laptops works ok... If i find something new i will post it here. Ron thanks for your help.
Reliable Contributor rmetzger
Reliable Contributor
Report Inappropriate Content
Message 8 of 18

Unwelcome Communications in question.



Dominik, You are quite welcome!

Actually, I was going to thank you for the information. As I suspected, VSE v8.7i is accessing these sites for some undocumented reason, quite early in the boot/login process. (Though the laptop that works has me wondering.) It would be nice to trap the communications that are taking place so we can see just what is going on. This would lead us to possible solutions or at least an explanation that tech support can use to make engineering change requests to the developers.

As for the working laptop . . . I wonder if the network driver is some how different (the most up to date, or even really out of date)? Is the gateway setting different or possibly DNS settings different? Again, trapping this communication and comparing this to those that fail might give us some idea to the root cause of the time out delays.

This is most interesting indeed. I wonder what is passing back and forth and what a High Security facility might think about this.

Ron Metzger
Thanks,
Ron Metzger

Was my reply helpful?
If this information was helpful in any way or answered your question, will you please select Accept as Solution in my reply and together we can help other members?

RE: Unwelcome Communications in question.

Just a wild guess:
Does 8.7 access/check these sites to accomodate the .DAT downloads done by the Common Framework?

These sites are mostly used for ESD:
http://www.akamai.com/html/solutions/electronic_software_delivery.html

reg, Henno.
Reliable Contributor rmetzger
Reliable Contributor
Report Inappropriate Content
Message 10 of 18

RE: Unwelcome Communications in question.



Henno, I think you are 'probably' correct. However, I would like to be Sure. From a security company, I think my security should be McAfee's focus. At this early stage of boot/logon, just what are they actually accessing. Certainly, when I schedule an update, I think it should be allowed, as I defined it. But this is happening before the prescribed scheduled update. This is where I believe (giving McAfee the benefit of the doubt) that this is establishing an early link to the Artemis technology (though I am not sure, which is why I would like to 'see' the communications taking place at this point).

Now, if I turn 'Off' the Artemis component, if my theory is in play, then this communications link should not be taking place. Or, could there be a bug that establishes this link before deciding that Artemis should not be active. At any rate, from a security standpoint, Nothing Should Be Communicating Without Documentation and Purpose. And I (or the Security Officer/Network Administrator) should control this communication.

If this communications is simply a DAT Update check, again, this should be happening at the prescribed and scheduled time and no earlier. (If scheduled to occur at logon, then a proxy server should not be causing a timeout delay or failure if properly tested.)

The login delay is a symptom of a much deeper problem with security. I assume McAfee is Not doing anything improper here, but . . . Nothing Should Be Communicating Without Documentation and Purpose.

Further, why can't the software look at a failure to communicate at this early stage and simply move on quickly (or handle the delay in the background)? Does an updated network driver correct this? If so, document this. Will VSE 8.7i 'SP1' fix this? How about a HotFix? How about documenting the problem to assure us that what is happening is by design and purpose? McAfee is in the Security business, Correct? I would like them to Lead By Example here.

Others Thoughts?

Ron Metzger
Thanks,
Ron Metzger

Was my reply helpful?
If this information was helpful in any way or answered your question, will you please select Accept as Solution in my reply and together we can help other members?
More McAfee Tools to Help You
  • Subscription Service Notification (SNS)
  • How-to: Endpoint Removal Tool
  • Support: Endpoint Security
  • eSupport: Policy Orchestrator
  • Community Help Hub

      New to the forums or need help finding your way around the forums? There's a whole hub of community resources to help you.

    • Find Forum FAQs
    • Learn How to Earn Badges
    • Ask for Help
    Go to Community Help

    Join the Community

      Thousands of customers use the McAfee Community for peer-to-peer and expert product support. Enjoy these benefits with a free membership:

    • Get helpful solutions from McAfee experts.
    • Stay connected to product conversations that matter to you.
    • Participate in product groups led by McAfee employees.
    Join the Community
    Join the Community