Non-Windows Clients Working Behind MS Proxy?

ikekrull asks: "I am, like many, stuck behind an MS Proxy Server 2 'firewall'. MS Proxy Server 2, refuses to route anything that doesn't go through a Windows-only MS Proxy Client. Supposedly it supports SOCKS5, but I have heard from various people that this support is also broken except for Windows clients. Is there a way, short of replacing the MS Proxy server with something a little more sane, to make non-Windows Operating Systems work behind this 'firewall'? Can I run another piece of proxying software alongside Proxy Server 2 just to service my Linux machines?"

"Has anyone reverse-engineered the MS Proxy client and made a version that works with Linux? Would it be possible to run the windows proxy client under WINE (very doubtful i know). I would ideally like seamless access, the kind i get with my ipchains-based Linux box at home, but something that let me surf the Web, ftp, and telnet and SSH around would be ok.

I am real pissed off with the way that MS Proxy Server 2 has been deliberately engineered to work only with Windows clients, I didn't notice this mentioned in the anti-trust case, but it sure as hell should be.

Any help would be appreciated."

If Microsoft expects their server OS to be used as servers in heterogeneous environments, they really should start look at supporting clients that aren't Microsoft. Would it really be all that difficult?

Comments

Use Junkbuster

[phil reed]

You can have Junkbuster substitute the User Agent header with something that the proxy finds more to it's liking.


...phil

Is MS-Proxy really refusing to route?

[Remote]

I've recently had a similar problem, maybe it will shed some light on this long discussion :) : I'm in an NT network (which works damn fine, except for this problem I'm describing) and we used to have a proxy firewall. I used Netscape to browse. The sysadmin gave me a fixed IP and allowed me to ftp (which is not needed for my job but the guy is very nice and monitors everything). He asked me it I wanted to telnet outside our organization also but I declined. Everything was running ok. One day they switched the proxy software to MS-Proxy and I couldn't use Netscape any more. I talked to him and he told me that he suspected NS sends the password as plain text, whereas MS-Proxy expect them to be encrypted. It was kind of a wild guess from him, as I'm probably the only one in this 5,000 people organization that uses NS. He said he could go after the cause and a fix but I told him to let it be, he's pretty overloaded already.

I did my own search and what I found is that it is probably an authentication issue, having to do with MS-Proxy expecting NT hashes instead of LAN hashes, which your Linux client is probably sending. I read in more than one place (unfortunately I can't give you a link) that it *can* be fixed, but nobody seems to know how!

I'm not an NT network administrator, I'm probably missing something, I may be downright wrong, but if I am I would like to hear from more enlightened people.

Re:Is MS-Proxy really refusing to route?

[david-currie]

I'm not sure if this is the same problem I have with the local HTTP proxy here running on NT/IIS, but a technical description of what is happening and how to implement the authentication for HTTP proxies is here and here respectively.

Dave

Re:Is MS-Proxy really refusing to route?

[SEWilco]

Yes, the usual problem with non-MS tools and MS Proxy is the NT Challenge/Response (NTLM) authentication, which is on by default. IE knows how to deal with it, but not others.

The MS Support KB articles Q245237 and Q218484 try to describe how to change configuration settings to allow Netscape to work with MS Proxy (I'd give links, but the MS KB web format has broken links in the past -- and even the MS Home Page doesn't have the correct link to the current MS Support home page).

Re:Is MS-Proxy really refusing to route? (url fix)

[Jim Buzbee]

The first link in the above paragraph should be this

Jim