java version "1.3.0_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0_01)
Java HotSpot(TM) Client VM (build 1.3.0_01, mixed mode)

We have spent some time investigating this one. It seems as though Sun's
implementation of the Java Plugin for all browsers is unable to authenticate
with MSProxy Server (v2) and  customer 's Proxy Server using NT Authentification.

This is a massive short fall in our opinion as this therefore make it extremely
difficult to use the rich features of Java 2 within a browser/web environment
(within the enterprise).

As you might have guessed the  customer  VM can authenticate (but the VM is not a Java 2 compliant implementation).

- Exact steps to reproduce the problem.

Compile the following code
import java.io.*;
import java.awt.*;
import java.net.*;
import javax.swing.*;

public class Test extends JApplet{

	JLabel jLabel;
	ImageIcon imageIcon;
	JPanel jPanel = new JPanel();

	public void init() {

		try{
			imageIcon = new ImageIcon(new URL(this.getCodeBase ().toString() + "test.gif"));
		}catch(IOException ioe){
			ioe.printStackTrace();
		}

		jLabel = new JLabel(imageIcon);
		jPanel.add(jLabel, BorderLayout.CENTER);
		this.getContentPane().setLayout(new BorderLayout());
		this.getContentPane().add(jPanel, BorderLayout.CENTER);
		Image image = imageIcon.getImage();
		System.out.println("width: " + image.getHeight(null));
		System.out.println("height: " + image.getWidth(null));


	}

}

place it on a webserver and create the associate HTML file. Convert the HTML
file using HTMLCOnverter for 1.3.

On the client side using  customer  IE 4 setup the browser to use  customer 
Proxy server configured as follows:

Software Running on Computer:
Windows Small Business Server 4.5
NT Build 4.00.1381
SP6a

 customer  Proxy 2.0
Build number 2.0.389
SP1

Proxy NAT..

The only bit of information I can get for you is this..

External IP Address is: 213.xx.xx.xx (public ip)
Internal IP Range recognised by proxy is: 192.168.0.0 to 192.168.255.255

at the moment there are no dissallowed ports.

Authentication is via windows NT.

Then call the url for the html page mentioned early( making sure it is routing
through the proxy). The java consol reports that the GIF is -1 by -1 pixels
wide (i.e. does not exist).

Replicate all this not going through the proxy server, console reports that the
gif if x by y (none negative).

A similar problem occurs when using URLConnection and a
java.io.FileNotFoundException is thrown.

Additional Information
We have an Applet. It calls a servlet via http and the servlet returns a
serialized java  customer  to the applet. The servlet is on the same domain (and
server) from which the applet it loaded from.

This works fine without a Proxy server. It also works fine though a number
of proxy servers. However it does not work through a proxy server that uses
NT Authentification. The  xxxxx  Plug-in does not seem to be able to use
this scheme of authentification.

I have appended an extract below which describes a work around. However this
work around is not acceptable for us but it may help to explain the problem
some more.

Hope we can solve this one!

Andy Hedges

// Extract Starts

How to get MS Proxy Server 2.0 to work with non- customer  products

When MS Proxy Server is installed, it allows two authentication methods by
default:

.       Anonymous access
.       NT challenge / response (aka CHAP)

A third method (Basic Authentication) is turned off.

Anonymous access allows any user to access internet content via the proxy
server, whereas CHAP requires that they authenticate themselves, and
therefore requires that the client they use supports CHAP. This may be
invisible to the user as their normal NT logon credentials are used.

Internet Explorer with the  customer  JVM supports CHAP, but Netscape and IE
with the Sun Java plug-in do not. The Proxy Server picks whichever
authentication method will allow the user through when processing a request.

Unfortunately, the default configuration of anonymous access is broken,
causing the proxy server to force the use of CHAP. Anonymous access is
supposed to work by authenticating each anonymous request using a
non-privileged user which is created during installation. Unfortunately the
proxy server then sets up the wrong details for this user, causing
authentication to fail (and the NT Event Log to fill up rapidly).
To fix the problem:

.       Open IIS console
.       Open properties for "Default web site" (not "Web proxy")
.       Select the "Directory security" tab
.       Click on "Edit" in the "Anonymous Access and Authentication Control"section
.       Click on "Edit" next to "Allow anonymous access"
.       Change the username to include the domain (e.g. from IUSR_MYHOST toMYDOMAIN\IUSR_MYHOST)
.       Click OK, and ignore the warning about password replication not working
.       Click OK twice more
.       Open "User Manager"
.       Double-click on the name of the user (e.g. IUSR_MYHOST)
.       Click on the "Hours" button.
.       Select all the time, and click "Allow"
.       Click OK twice
.       Wait a few minutes for the user information to be replicated across the
domain
// End extract
(Review ID: 118274) 
======================================================================

Use the Microsoft Plugin and try to replicate the functionality of Sun's Java 2
plugin as best you can (for example using swing.jar as in the old days).
======================================================================

JPI currently doesn't support NT challenge. Change it to RFE.

  xxxxx@xxxxx   2001-03-14

---------------------------------------------------------
For 1.4, we now support standard RFC2617 digest authentication.
We have no plans to support the Microsoft proprietary schemes.
However, Microsoft ISA server, which is the successor to Proxy server
does supports digest.

  xxxxx@xxxxx   2001-07-10
-------------------------------------------------------------

NTLM support will be built into the networking library. See #4626557. Mark it as duplicate.

It's pretty fundamental for any multi-enterprise 
implementation using Java Plug-In 1.3 over the Internet 
that it works with the most commonly used Proxy Server.  

This is not only a problem with the plug-in, but with 
applications as well.

How are Java applications supposed to become commonplace if 
they can't work through the most widely used proxy server?

Yes, it is important to note that this issue is not 
effecting applets but all java code that needs to pass 
though a proxy server.

_Undo_
Last comment should have read.

Yes, it is important to note that this issue is not _just_
effecting applets but all java code that needs to pass 
though a proxy server.

So much for the idea of java based web services!
Better to go .NET!

Why do you not use your own implementation of java.net.Authenticator or what about using JAAS.
I think the problem is that your using NT challenge authentication. This is special in the Microsoft
domain and not a standard.

Agreed.  Use of NT challenge/response is a request for 
incompatibility.

On the other hand, a free supply of a good number of 
pluggable JAAS login modules would go a long ways to making 
Java's handling of authentication challenges more seamless.

OK, I can appreciate your stand against using proprietary 
schemes but this doesn't not help the vast number of 
developers out there who need write applications that run 
through MS Proxy Server. At the end of the day, especially 
with the number of 'Microsoft Houses' out there it will be 
Sun that looses out (at least in the short term, who knows 
about long term). 

Whilst I appreciate that ISA does support RFC2617 digest 
format AFAIK this is not the default. Incidentally it is 
also possible to setup MS Proxy server so that the 1.3 JRE 
can 'see through' but it is not the default.

It used to be the case that Sun would persue these matters 
with M$ have you given up on that? It seems to me that Sun 
would have a strong case especially as it's partners are 
effected by this (Netscape won't run through MS Proxy 
configured in the way described (default settings) above)) 
and could approach them together.

In summary I respect that none standard schemes should not 
be supported but this does not help me or the other 
developers in the Java community.

We are currently having to look into the legal and 
technically viability of implementing CHAPS ourselves. If 
anyone is think of doing this also the SAMBA source code is 
a good starting point.

End of diatribe.

My customers use MS Proxy Server. If my product doesn't 
work with their proxy server, then they will buy my 
competition's product instead. I cannot force my customers 
to stop using a proprietary authentication scheme, even if 
I don't like it.

The evaluation is really amusing, since the 1.4 plugin is
still in beta and no downloadable codebase for the plugin is
available. So the client has to install the 1.4 beta (and
rip out any other plugins he has) to get the security stuff
to work. So much for the myth of platform independence!

A workaround we use for applets is to have users access 
them using SSL. This forces the Java plug-in to route 
communication through the browser (which can authenticate 
just fine). However, this workaround will go away for 1.4 
when as Java-based SSL has been added.

I think it would be a good idea to add a plugin option to 
route all http traffic through the browser. Users have a 
difficult time understanding why one part of a page loads 
and another doesn't. I believe that the Shockwave plugin 
takes this approach.

IN the mean-time, you can ask your clients to enable both NTLM 
authentication AND basic authentication.  If they don't like
that, then they can install the Microsoft Proxy client and
use the WinSock proxy (which happens on a lower level than
an HTTP proxy).  This is how we've been handling the problem
in my company.

As Sun suggests, we are using MS ISA server. However this 
only supports digest authentication on a Windows 2000 
domain, not on an NT domain. I am unable to get the 1.4 
plugin to run a single applet, and have had to revert back 
to 1.3.

Since IE 'knows' NTLM, would it be possible to write a java 
wrapper class that uses the 'IE dll' for port 80 
communications? I am no expert, so I don't think I could do 
it. If this is possible, we could piggy back on M$ and not 
need to make modfication to the java runtimes.

This is a real killer for us - we have a legacy (Java 1.1) 
application incorporating both a Java applet and a server, 
running under IIS and happily using NT authentication.  We 
now want to upgrade the technology to Java 2 or .NET but NT 
authentication is a SHOWSTOPPER for many of our customers.  

This lack of desire on the part of Sun to support "non-
standard" but widely used technologies (out of spite???) is 
forcing teams like mine to abandon Java and move to 
technology more in line with our customers' requirements - 
i.e.

It seems that the web proxy part of our ISA Server (the 
only way we have access to the outside) also supports basic 
authentication (I've got GetRight and UD Agent running fine 
with basic authentication), but I haven't got the slightest 
why the JRE pluggin (I have 1.4.0 installed) doesn't see 
that. It may be that the proxy only responds with an NTLM 
authentication requirement.
Does HTTP support alternative authentication schemes via an 
appropriately structured response?
Questions, questions... Too bad I don't have access to the 
ISA Server's configuration :(

I believe I have the same problem.
If I use a shared directory
<PARAM NAME="codebase" VALUE="file:/p:/appletdir/">
it works, but fails to load from URL

should add this to the comment above

Didn't have this problem with 1.3.1 but do with 1.4.
Told my clients to put the whole webapp  on thier intranet 
but that did not fix it. Yes they use Windows NT 4.0, and 
no, there is no proxy inside thier intranet.

Would there be a way to tell the java vm to use another class 
for its basic IP services?  It is my understanding, that just 
linking with the MS WebClient.dll or one of their libraries 
would handle the authentication automagically.  Then 
someone could write a JNI based wrapper for the sockets and 
we could just modify a system property

I have the same problem with MS ISA Server. Is there ever 
likely to be a fix?