[squid-users] FW: Java authentication under SquidNT 2.6 STABLE 14 using NTLM

Under the advise of the 3rd party I have added the following to
squid.conf

    acl Java browser Java/1.4 Java/1.5 Java/1.6
    http_access allow Java

This appears to resolve the issue. However I would like to better
understand it the above line, and whether it is an acceptable full-time
solution, or merely a workaround.

Paul Cocker
IT Systems Administrator
IT Security Officer

01628 81(6647)

TNT Post (Doordrop Media) Ltd.
1 Globeside Business Park
Fieldhouse Lane
Marlow
Bucks
SL7 1HY

-----Original Message-----
From: Paul Cocker
Sent: 18 September 2007 19:52
To: squid-users@squid-cache.org
Subject: Java authentication under SquidNT 2.6 STABLE 14 using NTLM

Last week (Thursday/Friday) my organisation moved from SquidNT 2.5 to
SquidNT 2.6 STABLE 14. We use a Java applet which generates parcel tags
and prints them off. It was working fine... until today. We are running
Java 6 Update 2 and users connect using NTLM passthrough authentication,
squid looks to see that they are a member of group X before allowing
them access. Java is setup to use the same settings as the browser. We
are seeing the following in the console output

java.lang.NullPointerException
        at
sun.net.www.protocol.http.NTLMAuthentication.setHeaders(Unknown Source)
        at
sun.net.www.protocol.http.HttpURLConnection.doTunneling(Unknown Source)
        at
sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(Un
known Source)
        at
sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown
Source)
        at
sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(Unknown
Source)
        at sun.plugin.PluginURLJarFileCallBack$1.run(Unknown Source)
        at java.security.AccessController.doPrivileged(Native Method)
        at sun.plugin.PluginURLJarFileCallBack.retrieve(Unknown Source)
        at sun.net.www.protocol.jar.URLJarFile.retrieve(Unknown Source)
        at sun.net.www.protocol.jar.URLJarFile.getJarFile(Unknown
Source)
        at sun.net.www.protocol.jar.JarFileFactory.get(Unknown Source)
        at sun.net.www.protocol.jar.JarURLConnection.connect(Unknown
Source)
        at
sun.plugin.net.protocol.jar.CachedJarURLConnection.connect(Unknown
Source)
        at
sun.plugin.net.protocol.jar.CachedJarURLConnection.getJarFileInternal(Un
known Source)
        at
sun.plugin.net.protocol.jar.CachedJarURLConnection.getJarFile(Unknown
Source)
        at sun.misc.URLClassPath$JarLoader.getJarFile(Unknown Source)
        at sun.misc.URLClassPath$JarLoader.access$600(Unknown Source)
        at sun.misc.URLClassPath$JarLoader$1.run(Unknown Source)
        at java.security.AccessController.doPrivileged(Native Method)
        at sun.misc.URLClassPath$JarLoader.ensureOpen(Unknown Source)
        at sun.misc.URLClassPath$JarLoader.<init>(Unknown Source)
        at sun.misc.URLClassPath$3.run(Unknown Source)
        at java.security.AccessController.doPrivileged(Native Method)
        at sun.misc.URLClassPath.getLoader(Unknown Source)
        at sun.misc.URLClassPath.getLoader(Unknown Source)
        at sun.misc.URLClassPath.getResource(Unknown Source)
        at java.net.URLClassLoader$1.run(Unknown Source)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(Unknown Source)
        at sun.applet.AppletClassLoader.findClass(Unknown Source)
        at java.lang.ClassLoader.loadClass(Unknown Source)
        at sun.applet.AppletClassLoader.loadClass(Unknown Source)
        at java.lang.ClassLoader.loadClass(Unknown Source)
        at sun.applet.AppletClassLoader.loadCode(Unknown Source)
        at sun.applet.AppletPanel.createApplet(Unknown Source)
        at sun.plugin.AppletViewer.createApplet(Unknown Source)
        at sun.applet.AppletPanel.runLoader(Unknown Source)
        at sun.applet.AppletPanel.run(Unknown Source)
        at java.lang.Thread.run(Unknown Source)

Having spoken to a chap at the company behind the software he indicated
that this is a problem with the passthrough authentication, which is
further supported by the fact that if we take a workstation which runs
this application and give it a direct connection to the Internet,
everything works just fine. Yet, as I say, we upgraded last week and it
was working fine on Monday and nothing has been changed in the config
since, though the service was restarted this morning.

I am seeing quite a few TCP/DENIED entires in the access.log file
relating to the site in question:

TCP_DENIED/407 1789 CONNECT web.site.com:443 - NONE/- text/html
TCP_DENIED/407 2035 CONNECT web.site.com:443 - NONE/- text/html

I note from the logs that where we register NONE, there should be the
username of the individual in question.

Any help would be much appreciated.

Paul Cocker
IT Systems Administrator
IT Security Officer

01628 81(6647)

TNT Post (Doordrop Media) Ltd.
1 Globeside Business Park
Fieldhouse Lane
Marlow
Bucks
SL7 1HY

TNT Post is the trading name for TNT Post UK Ltd (company number: 04417047), TNT Post (Doordrop Media) Ltd (00613278), TNT Post Scotland Ltd (05695897),TNT Post North Ltd (05701709) and TNT Post South West Ltd (05983401). Emma's Diary and Lifecycle are trading names for Lifecycle Marketing (Mother and Baby) Ltd (02556692). All companies are registered in England and Wales; registered address: 1 Globeside Business Park, Fieldhouse Lane, Marlow, Buckinghamshire, SL7 1HY.
Received on Tue Sep 18 2007 - 13:33:10 MDT