Hi,

The same problem reported here.

Any suggestion?

Regards,
Mehboob

Not sure what the solution is, but I have some observations:

1. Why would you use both proxies? IM Manager is a proxy itself and does the filtering/policy application. No need to proxy twice.
2. Authentication for that version of Yahoo does not go through IM Manager - only the actual messages themselves do. You cannot force all of the traffic to IM Manager. If you insist on using another proxy like this, it needs to be able to route traffic based on port used and destination. Authentication must go directly to the Yahoo servers. Messages must go to IM Manager.

I do wish you luck though. And if you find a solution, please post it here for the benefit of other posters. Thanks.

We are also fasing same problem
any suggestion please

The newer Yahoo clients (much like the latest AIM clients and like MSN client) need to do authentication direct with the Yahoo home servers.

When a yahoo client attempts to connect it has 2 places it needs to talk to, IM Manager and the external yahoo authentication servers. 

It is talking to IM Manager to send messages through and all that normal work.  The client is talking to the Yahoo authentication servers to make sure that the user is an actual yahoo login and that the Yahoo Network is allowing them to login.

It could easily be that when the web proxy is being used that it is routing the traffic to the IM Manager server, which it shouldn't.  Or that the web proxy is editing the packets that are being sent between the client and the external servers and the client doesn't like it.

Instant Messengers have more than just negative security effects. You should consider lost productivity due non-business related "chatting" and interruptions to the normal work flow. While Instant Messaging is useful for pre-teen girls checking up on the status of their Hello Kitty, they don't have much use in a business environment.

The exception to this is when Instant Messengers are used to allow employees to communicate with each other on the corporate network. Instant Messengers can be put to good use on the internal corporate network as a supplement to phone calls and email messages.

We need some way to prevent these applications from interacting with Internet users. The best way to handle this is to devise a network usage policy that forbids the use of these applications and have the management back up this policy. Management support is a must if you want the usage policy to have some teeth in it.

After the network usage policy is in place, you can use the ISA Server Firewall service log and application inventory reports to determine who has been using forbidden programs. You can create a report based on these resources and present the information to the user's supervisor. This is usually quite effective in getting the offender to stop forbidden behavior.

However, not all businesses are able or desire to prevent dangerous application usage in this sort of "up front" manner. Companies have different corporate cultures. You may find yourself with no support for a network usage policy. If this is your situation, you'll need to implement "stealth" measures to prevent users from compromising network security.

A great way to do this is by taking advantage of the Firewall client. The Firewall client software can be installed on all Microsoft network capable operating systems except for Windows 3.x. You can still take advantage of the Firewall Service for Win 3.x clients by installing the Proxy Server 2.0 Winsock Proxy client on them. In fact, I recommend installing the Firewall client on all operating systems that the Firewall client can be installed on.

Blocking Network Applications Using Firewall Client Configuration

You can make changes to the mspclnt.ini file on the ISA Server. This file contains configuration information for Firewall client machines. It is downloaded from the ISA Server to the ISA clients every six hours by default. This file is stored in different locations on the client machines depending on the operating system.

Your first step is to figure out what the name of the executable file is for the offensive application. The following list includes the common dangerous applications and their .exe files:

* AOL Instant Messenger - AIM.EXE
* MSN Instant Messenger - MSMSGS.EXE
* Yahoo Instant Messenger - YPAGER.EXE and YUPDATER.EXE
* ICQ - ICQ.EXE

After you figure out the executable file name you can configure the mspclnt.ini file to block network communications from the application.

Perform the following steps to configure the mspclnt.ini file:

1. Open the ISA Management console, expand Servers and Arrays and expand your server. Click on the Client Configuration node, and then double click on the Firewall Client entry in the right pane.
2. You will see the Firewall Client Properties dialog box as seen in the figure below. Click the New button.

3. After clicking the New button you will see the Application Entry Settings dialog box as seen below. Type in the name of the application without the file extension in the Application text box. Type the letter D in the Key list so that Disable appears. In the Value list, type the number 1. Click OK after making these changes.

4. After making the changes to block the application, you need to wait until all clients have downloaded the new mspclnt.ini file. You either have to wait for 6 hours, or you can force the clients to download the file by going to each client and clicking on the Update Now button in the Firewall client configuration dialog box.
5. After each Firewall client machine has downloaded the updated mspclnt.ini file, you must disconnect all Firewall Client sessions from the ISA Server. You can do this by going to the ISA Management console and manually disconnecting the sessions (as seen in the figure below), or you can restart the Firewall Service. Restarting the Firewall Service will cause all Firewall client connections to drop.

6. If any of the clients are configured as SecureNAT clients, change their configuration by removing the default gateway address. The SecureNAT client will be able to get around the limitations you set in the wspclnt.ini file. You can configure the Windows 2000 Group Policy to block user access to the Network Connections Control Panel applet.

This is the first step in your access control configuration. Because some clients must be configured as SecureNAT clients, and because all of these applications can get around the mspclnt.ini configuration, there are some more steps you'll have to perform.

Application Specifics

It would be nice if we could configure all computers as Firewall clients and leave it at that. However, like all good malware, these dangerous applications can allow outbound connections through alternative means. Many of these applications allow the user to configure them as Web Proxy or SOCKS 4 clients (ISA Server does not support SOCKS 5 out of the box).

In addition to having to deal with users who reconfigure their applications, you also have to deal with applications that can scan the network and find a hole. Some of the applications can use stealth techniques and grab the browser's Web Proxy client configuration without your knowledge. Therefore, you'll have to do more than just configure the mspclnt.ini file

Yahoo Instant Messenger

Perform the following steps to block the Yahoo Instant Messenger:

1. Block the YPAGER.EXE and the YUPDATER.EXE executables in the mspclnt.ini file
2. Create a Site and Content rule that blocks http.pager.yahoo.com. Remember to create a Destination Set that includes this site so that you can create the Rule.
3. The SOCKS4 Application Filter must be disabled. Users can reconfigure the Yahoo IMer as SOCKS 4 or SOCKS 5 clients. ISA Server does not support SOCKS 5, but they can get out using SOCKS 4. Since few legitimate applications require SOCKS, you can safely disable the filter.

AOL Instant Messenger

Perform the following steps to block the AOL Instant Messenger:

1. Block the AIM.EXE executable in the mspclnt.ini file.
2. From my testing, the AOL IMer doesn't seem to be able to get around the mspclnt.ini file configuration, even if you set it up as a Web Proxy client in the AIM configuration dialog box. Therefore, you do not need to create a Site and Content Rule to block the aol.com domain.
3. Like the Yahoo IMer, AOLer can get around the mspclnt.ini file configuration by setting up the application to use SOCKS 4. Therefore, you will need to disable the SOCKS4 application filter to keep this application locked out.

MSN Instant Messenger

Perform the following steps to block the MSN Instant Messenger:

1. Block the MSMSGS.EXE executable in the wspclnt.ini file.
2. It appears that "sometimes" the MSN Instant Messenger is able to detect the proxy settings in the web browser. From my testing, it appears that it does not find the browser settings when IE 5.0 is the browser, but will find the browser settings on an IE 5.5 machine. It could also be an issue with "point" releases of the MSN IMer. This stealth discovery of the browser settings is not a configuration option. It is done in the background and without your knowledge.
3. Create a Destination Set that includes the IP address range 64.4.13.0 - 64.4.13.255. Then create a Site and Content rule that denies access to this Destination Set. Keep in mind that this network ID might change in the future. If you find users are able to connect using the MSN IMer in the future, review Firewall Service logs to determine the new network ID.
4. Note that creating a Site and Content rule that blocks services.msn.com will not prevent access.

ICQ 2000b

We only tested the latest version of ICQ, which appears to be ICQ 2000b. Perform the following steps to block this version of ICQ:

1. Block the ICQ.EXE file in the mspclnt.ini file.
2. Create a Destination Set that includes the following sites:
web.icq.com
ads.icq.com
login.icq.com
cb.icq.com
3. Create a Protocol Rule that denies access to the Destination Set you created above.
4. Setting the ICQ client to use SOCKS 4 does not appear to allow the client outbound access when the above steps are taken. However, it is still a good idea to disable the SOCKS 4 application filter in order to block the other IMers.

HTTP Redirector Configuration

Another thing you can do to help take a bite out of crime is to configure the HTTP Redirector Filter to drop all requests from Firewall and SecureNAT clients.

After configuring the HTTP Redirector Filter, go to the Outgoing Web Requests listener and force authentication.

Many of the IMers do not know how to send client credentials to the Web Proxy service. If the client cannot properly authenticate, it will not be able to gain access to the Web Proxy service. If it can't access the Web Proxy service, it won't be able to use HTTP to connect to the offending site.

Note that some of these IMers, such as the Yahoo Messenger, will not work if you require any sort of authentication. I ran into this when I was actually trying to make this work for a client who I could not convince regarding the security hazards of IMers (he ended up receiving a virus from a "friend" through the fire transfer later).

I had a Protocol Rule that allow all IP traffic and used the default Site and Content Rule. However, I couldn't get the dreaded Yahoo IMer to work. The problem was that my Bandwidth Rules were based on users and groups. The funny thing was that the rule governing HTTP access was configured to let everyone through. It was an NNTP Bandwidth Rule, which was not being used, that prevented access!