We are trying to evaluate a 3rd party software and have installed it on one
of the XP PRO workstations.
We are now receiving an 'Error 407 - Proxy Authentication Required' on this
workstation and * only * when running this software.
Basically (according to their Tech Support) it is trying to use HTTP on port
5080 to connect to their server and is receiving the error message from *
our * server.
We have configured the s/w according to the instructions provided which
includes inputting a user name and password.
We used 'administrator' with the password that is used to login to the
network in addition to other usernames/passwords that have administrator's
privileges.
Is there a setting(s) on the server that we need to modify or something we
are missing?
TIA.
--
Regards,
Allan C
The destination port of 5080 doesn't mean anything and isn't the
problem. You are still connecting to port 80 of the proxy and the
proxy is connecting *from* port 80 to the destination port of 5080,
which is fine.
Their software may not be CERN compliant. In order to work it must
"appear" to the Proxy as a CERN Compliant Web Browser. If it is does
not you are screwed as far as the Web Proxy Service goes. If it is
CERN Compliant it will have a place within its settings to give it
"proxy settings" for a "http proxy".
If any part of this thing uses HTTPS or SSL then it will only be able
to use port 443. Using other ports for SSL is a security risk, that's
why Proxy2 is hardcoded to only use SSL on 443. You can configure it
to use other ports only by "hacking" the registry, which I don't
recomment,...they built it the way it is for a reason :)
Tunneling SSL Through a WWW Proxy
http://muffin.doit.org/docs/rfc/tunneling_ssl.html
> We have configured the s/w according to the instructions provided
which
> includes inputting a user name and password.
> We used 'administrator' with the password that is used to login to
the
> network in addition to other usernames/passwords that have
administrator's
> privileges.
If you get a login popup, then their software is not capable of
Integrated Authentication. It will have to use Basic Authentication
which passes the credetials across in plain "clear text" for all
"sniffers" to see :).
You may want to forget using the Web Proxy Service with this thing and
use the Winsock Proxy Service instead. This is done by running the
software as if there is *no* proxy server and then install the WSP
Client on the machine and give the user permission to HTTP & HTTPS in
the Winsock Proxy Permissions.
--
Phillip Windell [CCNA, MVP, MCP]
WAND-TV (ABC Affiliate)
www.wandtv.com
Phillip,
Yes, there is a configuration area where we set the parameters for the
proxy.
They told us to use Basic Authentication.
When you refer to 'sniffers' ... do mean outside of the internal network?
I would have assumed that the username/password info stops inside and
doesn't actually get transmiited out?
Is it possible that I am missing a setting in the Web Proxy Service?
Other than resolving the problem (we hope) are there any pros/cons to using
the Winsock Proxy vs Web Proxy?
Also, changing the proxy would affect all applications running on that XP
PRO workstation, correct?
Thank you once again.
--
Regards,
Allan C
I meant inside the private network only. Obviously not as much of a
risk, but I was just letting you know that a "sniffer" on the inside
can do that. Many "Trojans" that get on people's machine via web
browsing to sites they should be at or opening junk mail they
shouldn't open are designed to do this. The "Trojans" often look for
this stuff on the private wire and then phone home to mama and pass on
what it finds.
> Is it possible that I am missing a setting in the Web Proxy Service?
Probably not. It is most likely a problem in the way they implemented
this with the code of the App.
> Other than resolving the problem (we hope) are there any pros/cons
to using
> the Winsock Proxy vs Web Proxy?
Only Web Proxy does web caching. Winsock Proxy doesn't take advantage
of web caching. That wouldn't bother me here since I have web caching
completely disabled on the proxy anyway.
> Also, changing the proxy would affect all applications running on
that XP
> PRO workstation, correct?
"Changing the proxy"? You are not changing any proxy. Now if you
mean installing WSP Client would effect other Apps, then yes, no,
maybe, kinda sorta, probably not, but might. It depends on what you
mean by "effect" and what context you mean it in. The WSP Client
simply intercepts all "calls" made to Windows Sockets (Winsock) and
compares the destination to the LAT. If the destination is in the LAT
then nothing happens. If the destination is not in the LAT, the
"request" is passed on to the Winsock Proxy Service running on Proxy2.
That is all it does. None of the Apps on the machine are ever
"conscious" that the WSP Client even exists.
The WSP Client is the best hope of getting this working. The App will
be run just as if there was no proxy server, so leave all "proxy
settings" blank. This way you are not at the mercy of wether or not
they implemented the App's "proxy abilities" properly because you
simply aren't using its "proxy abilities".
Phillip,
In their documention they mention that the app is not compatible with
'socks'.
I stopped the service as part of the debugging process yesterday and it
didn't help.
Should I start the service again or does the fact that it is running mean
that it is can cause problems with app (assuming of course that I follow
your recommendations above)?
Socks is not the same thing as Winsock (Windows Sockets).
The Winsock Proxy is what you need to use, not the Socks Proxy
Service.
The Socks Proxy Service is not relevant to any of this we're dealing
with.
--
Phillip Windell [CCNA, MVP, MCP]
WAND-TV (ABC Affiliate)
www.wandtv.com
"Allan C" <all...@hotmail.com> wrote in message
news:W0iNb.150937$AAe1....@news01.bloor.is.net.cable.rogers.com...
Phillip,
Got it (I think).
Will try your suggestions later this week or early next.
Thanks again.
>
>
>
> "Allan C" <all...@hotmail.com> wrote in message
> news:W0iNb.150937$AAe1....@news01.bloor.is.net.cable.rogers.com...
>> In their documention they mention that the app is not compatible with
>> 'socks'.
>> I stopped the service as part of the debugging process yesterday and
>> it didn't help.
>> Should I start the service again or does the fact that it is running
>> mean that it is can cause problems with app (assuming of course that
>> I follow your recommendations above)?
--
Regards,
Allan C
If this helps, here's a quick run down of the different "services"
that make up Proxy2 and what each is primarily for.
Proxy Services
1. Web Proxy Service controls the user's Browsers. (No Client software
is required). This Service only handles HTTP, HTTPS, Gopher,
FTP(Download only).
2. Winsock Proxy Service controls everything else but the Browsers.
Ports are opened and closed "on the fly" as needed. Web Browsers can
use it if Web Proxy fails. (The WSP Client must be installed on the
workstation). This Service handles all types of TCP or UDP based
internet traffic but does not involve "web caching" which can only be
done with the Web Proxy Service. It also does not do VPN since VPN
uses GRE packets and not just simply TCP or UDP.
3. Socks Proxy Service is mainly for Non-Windows machines behind the
Proxy. Rarely used....I can't think of anyone I know that uses it. It
does require the user's application to be a "socksified" application
(very rare) or it requires a "socks client" similar to the WSP Client.
MS does *not* produce such a client.
4. Packet Filters are only for "services" that run on the Proxy
machine itself . They are not for clients to use.
I have been corresponding with someone else who had exactly the same
problems with the same software.
He is also running SBS 4.5.
He ended up connecting the XP PRO pc directly to the router and thus
bypassing the proxies, etc on the server.
Then he assigned a static IP to the 2nd nic on the pc.
Then he redirected port 5080 (s/w requirement) to this static IP.
However, our ISDN modem only has one Ethernet connection.
He suggested buying a 4 port router, connecting the output of the current
ISDN modem to the router's input, connecting one output port of the ISDN to
the 2nd nic on the server (to replace the ISDN modem's input) and another
output port to a 2nd nic on the XP PRO pc.
I would then assign a static IP to the 2nd nic on the pc.
Lastly, I would have to ask our ISP to do the port redirection.
Do you think that this would work (in theory)?
TIA.
--
Regards,
Allan C
"Phillip Windell" <none> wrote in message
news:%23S0tHL3...@TK2MSFTNGP10.phx.gbl...
That's it! You're done!
If the permissions prove not good enough then temporarily granting the
user the "Unlimited Access" permission from the dropdown list and go
with it until you can figure out what this application is really doing
behinds the scenes.
Read on below......
"Allan C" <all...@hotmail.com> wrote in message
news:I0ZNb.57019$ZuL1....@twister01.bloor.is.net.cable.rogers.com...
> I have been corresponding with someone else who had exactly the same
> problems with the same software.
> He is also running SBS 4.5.
> He ended up connecting the XP PRO pc directly to the router and thus
> bypassing the proxies, etc on the server.
This is the equivalent of standing out in the middle of the highway
with your pants around your ankles and hoping you won't get hit. His
XP Pro machine is now a perfect target to hack into the network from
outside. It is practically a "super-highway" for the hacker.
> He suggested buying a 4 port router, connecting the output of the
current
> ISDN modem to the router's input, connecting one output port of the
ISDN to
> the 2nd nic on the server (to replace the ISDN modem's input) and
another
> Lastly, I would have to ask our ISP to do the port redirection.
? ISP's don't "Port Forward",...there isn't anything to Port Forward
*to* anyway. You still only have one IP# and that is all you would
ever have. There is no way around that with ISDN. All that does is
"replace" the proxy with the Router while the proxy gets moved one
subnet inward. You would have two private address subnet blocks, one
between the proxy and the router, and one on the internal side of the
proxy.
> Do you think that this would work (in theory)?
In theory yes,...in pactice, unjustified. You would be creating a
"Back-to-Back DMZ". You think you have trouble geting things out the
proxy now,....boy you just wait till you have to deal with a B2B DMZ
where *both* the Proxy and the Router must agree together on
everything that is allowed through. If either "denies" then things
"quit" and you may have a chore on your hands finding out which one is
causing the problem. You would also be moving the workstation into the
DMZ (untrusted) network from the internal (trusted) network. If you
put two nics in the workstation so it can see the internal network,
then you are almost nullifying the existence of the proxy to an
extent.
To make it short, you are trying to avoid a very simple task (WSP
Client) by doing a very complex task instead (B2B DMZ).
You are right.
I left out some of the gory details - not intentionally.
The WSP was * already * installed on the XP PRO pc.
The settings were enabled and not forced to IPX/SPX protocol.
Changing the last setting did not seem to make any difference.
We were testing using both 'Administrator' logged onto the local computer
and to the domain.
Tried the privileges in the proxies as per your suggestions and ran the app.
as if there we no proxy.
But, as I mentioned in previous posts, my knowledge is limited so I might
have misunderstood.
The ISDN h/w is leased and we have no control over its ports.
From the s/w manufacturer's test guide:
'For communication to the Cleo AS2 System test site, open zzz.zz.zz.zzz
(Cleo's IP) to port 5080.'
What are they saying that we should do?
I would include snippets from their error log but they are rather verbose.
However, if I configure with no proxy in the Cleo s/w one key line reads:
'Host address:port not accessible; firewall may be blocking connection'
With proxy one key line reads:
'407 Proxy authentication required'
We are fast approaching desperate because this s/w is required to continue
doing business with one of my client's major accounts (EDI) and the deadline
is approaching.
Thank you so much for all of your assistance!
--
Regards,
Allan C
"Phillip Windell" <none> wrote in message
news:Ox7v%23YI3D...@TK2MSFTNGP12.phx.gbl...
You have to make sure the WSP Client actually works.
And you have to make sure the user account has the right permissions.
There is no such thing as an "administrator" to Proxy2. *Nobody* has
permissions by default. You have to specifically grant them
permissions,...even the Admin.
Test the WSP Client from a command prompt on the workstation at a
command line with this command:
"chkwsp32 /f"
The result that comes back should say:
"Client control protocol matches the server control protocol"
> The ISDN h/w is leased and we have no control over its ports.
> From the s/w manufacturer's test guide:
> 'For communication to the Cleo AS2 System test site, open
zzz.zz.zz.zzz
> (Cleo's IP) to port 5080.'
> What are they saying that we should do?
It means they don't have a clue as to how an advanced proxy server
works (incuding the older Proxy2). You don't open ports,...it doesn't
work that way. You give permissions to user,...it is a "permissions
based" system.
Even besides that, even if you simply "opened a port", there is more
to it than that in some cases....you have Initial Connections,
Sebsequent Connections, Source Ports, Destination Ports, Dynamic Port
Ranges (RFC) and other Dynamic Ranges (non-RFC),...and then there are
special "encapsulations" that some software uses (such as
http-tunneling) and then throw into the mix the special HTTP Header
Extensions such as SOAP headers that is often used by XML. Let's not
even get into HTTPS and SSL (which the two aren't really the same
thing).
Now Proxy2 may not require anything special for some of these, but my
point is that there is a whole world of "stuff" out there involving
software at one location communicating with a server that is across
the Internet somewhere else. And when they give you an over simplistic
instruction of how to use their stuff you need to understand that it
may be up to you to figure out how to get it to work because they may
not actually know.
I will be on-site tomorrow and try what you suggested.
Tks.
--
Regards,
Allan C
"Phillip Windell" <none> wrote in message
news:ecqWrJq3...@TK2MSFTNGP10.phx.gbl...
Here is an update.
I have been working with a 'firewall & proxy specialist' at the s/w
manufacturer.
He has been unable to get us through the proxies on our Small Business
Server 4.5.
Their notes on working with proxies cover ISA Proxy 2 (not sure if correct
terminology), but they have no info on what is included with SBS 4.5.
What he was trying to do was add 'basic authentication'.
He did this by right clicking on the server name, properties, master
properties www server/edit, directory security, anonymous access and
authentication control/edit, check mark basic authentication.
We then reconfigured the s/w on the XP PRO pc to use basic authentication
with the administrator's password.
The 'administrator' account had been configured long ago for full access to
the proxies protocols.
The above did not help and the message returned to the client s/w was still
'407 Proxy Authentication required'.
Is ISA Proxy 2 something that can be added to the SBS 4.5? Would it replace
what we have?
Is it a good/bad idea, etc?
Thank you very much for your assistance as our deadline is fast approaching.
Regards,
Allan C
"Phillip Windell" <none> wrote in message
news:Ox7v%23YI3D...@TK2MSFTNGP12.phx.gbl...
MS Proxy1 (old, old version)
MS Proxy 2 (old version & also comes with SBS4.5)
MS ISA 1 (effectively Proxy 3 - but not called that) Runs on 2000.
>> What he was trying to do was add 'basic authentication'.
>> -------<shortened for space> --------------
>> The above did not help and the message returned to the client s/w
was still
> '407 Proxy Authentication required'.
Just forget all that and use the WSP Client and run their software as
if there is *no* proxy, then you don't have to depend on the "proxy
abilities" of their software . You're just gonna have to quit wasting
time and trust me on that. It *will* work assuming there isn't
something else unrelated that is wrong with the proxy.
If the client was willing to pay by the hour for remote assistance, would
you be interested?
We can set-up GoToMyPc on both the server and XP PRO pc, but only one at a
time.
If yes, what would be your policy if we could not get it to work?
--
Regards,
Allan C
"Phillip Windell" <none> wrote in message
news:%23cvMRvP...@TK2MSFTNGP11.phx.gbl...
--
Phillip Windell [CCNA, MVP, MCP]
WAND-TV (ABC Affiliate)
www.wandtv.com
"Allan C" <all...@hotmail.com> wrote in message
news:1RSPb.86705$7JB1....@news04.bloor.is.net.cable.rogers.com...
Thank you so much. Yes, the phone is near both.
I will probably call this afternoon.
--
Regards,
Allan C
"Phillip Windell" <none> wrote in message
news:u04UK5Q4...@TK2MSFTNGP09.phx.gbl...
Sincere thanks for your telephone help today.
Now, I am having some problems that I think might boil down to one issue.
I placed icons on the taskbar for both NICs.
The AS2 app that we were discussing is using the correct NIC (the new one).
Internet Explorer is using the original NIC (correctly). I set-up IE6 to use
10.0.0.2 port 80 for the proxy on the LAN connection tab.
However, another 3rd party EDI app is incorrectly using the new NIC and
therefore bypassing the server's proxies.
Another problem is that pc's are not available in Explore. Therefore I can't
use their printers.
Right click on Start/Explore ... the only computers in the domain are the pc
that we have been discussing and the server with the proxies on it.
The AS2 NIC was set-up, as we discussed, with an IP of 192.168.1.3, subnet
255,255,255,0 and gateway 192.168.1.1
WSP client was unchecked.
I am quite sure that I observed something else 'strange' ... I think that
when you try to browse the icon for the AS2 NIC briefly flashes (left
monitor). Maybe the original NIC's icon also flashes briefly when using the
AS2 program.
Thank you once again.
--
Regards,
Allan C
"Phillip Windell" <none> wrote in message
news:u04UK5Q4...@TK2MSFTNGP09.phx.gbl...
Part #1
Right-click on "My Network Places", select Properties, select Advanced
from the menu at the top, select Advance Settings from the menu that
drops down, select the "Adapters and Bindings" Tab. In the Connection
box (top one) use the arrows on the right to make sure that the old
nic (10.x.x.x) is the one at the top. "OK" you way out of everything
till you are back at the Desktop.
Part #2
Now again, right-click on "My Network Places", right-click on the
"old" Nic, select Properties, select TCP/IP and select Properties.
Make sure it has a DNS settings that points to your internal Active
directory DNS server (typically it is the Domain Controller). If you
run an internal WINS Server, make sure it has the WINS Server entered
in the WINS section. The Default Gateway must remain blank, do not
give it a DF.
> However, another 3rd party EDI app is incorrectly using the new NIC
and
> therefore bypassing the server's proxies.
You may come to a point where you need a separate workstation for each
EDI App. It is the old "can't have your cake and eat it too" thing.
Except for browsers which have their own "proxy settings, *any* App,
no matter what it is, will use the Default Gateway to get to any
resource that is not on the same subnet that the internal system is
running on. That is the way TCP/IP works, that is just the way it is.
It is possible to create a situation that is an exception to this.
You keep the WSP Client running, but create an exception in it that
tells it to not interferre with the AS2 App while still routing all
others to the regular proxy.
Find the WSP Client's "mspclnt.ini" file on the workstation. Typically
it is in
C:\MSPCLNT
Open the INI file in Notepad. You should see a section that looks
similar to this:
[Internal]
scp=9,10
Build=2.0.372.12
[wspsrv]
Disable=1
[inetinfo]
Disable=1
----- CUT -----
Now let's say for the sake of discussion that the AS2 App that need to
go out the special Nic runs from an executable file called "AS2.EXE".
You'll have to find out the real filename yourself. You then enter a
section for it into the INI file that tells WSP Client to ignore the
AS2 App. The tile of the section will be the filename without the
extension, so the INI file would then look like this:
[Internal]
scp=9,10
Build=2.0.372.12
[AS2]
Disable=1
[wspsrv]
Disable=1
[inetinfo]
Disable=1
------CUT------
You should now be able to run the WSP Client on the machine for the
sake of all other Apps, but it should ignore the AS2 App and let it
run on its own independently