[jcifs] NtlmHttpFilter: GUEST sometimes replaces username specified in web.xml due to session deserialization

Peter McKenzie petermcke at gmail.com
Thu Jul 7 11:16:18 GMT 2005


We have been having a problem under tomcat that when we restart the server we
sometimes cannot get it to work against Windows 2003 DCs. The problem turns out
to be caused by Tomcat session deserialization. This problem started after we
put in account details (jcifs.smb.client.{username,password,domain}) to handle
SMB signatures.

Workaround:

One workaround is to clear out the session information in the tomcat work
directory called SESSIONS.ser (assuming you have no other use for it).
Alternatively if the session information is older than your session timeout by
the time the tomcat server is restarted there will be no problem. For example,
in our case, waiting 30 minutes solved the problem too but did not make anyone
happy.

Details:

Problem tested under Tomcat 4.1.30 with jdk 1.5.0 (01 and 02) on RH 3.0 and
Windows XP using jcifs 1.2.1 and 1.1.11.

The class NtlmPasswordAuthentication is part of the tomcat session as it is put
in as part of the NTLM negotiation:

NtlmHttpFilter (1.2.1):
  req.getSession().setAttribute( "NtlmHttpAuth", ntlm );

On our fairly default Tomcat 4.1.30 setup the session is being saved on server
shutdown if an active session still exists. At startup I see that Tomcat
reinitializes the the static fields in the class. The problem with this is that
this results in the fields DEFAULT_USERNAME, DEFAULT_PASSWORD and DEFAULT_DOMAIN
being set to default values in NtlmPasswordAuthentication. Eg, DEFAULT_USERNAME
becomes 'GUEST':

    private static final String DEFAULT_USERNAME =
            Config.getProperty("jcifs.smb.client.username", "GUEST");


This is because the config Config has not yet had any properties set as the
filter init has not yet been called.


Here is a stack trace from inside NtlmPasswordAuthentication constructor which
shows the call from Tomcat on startup (ignore line numbers as I had some
additional debugging in jcifs):

	jcifs.smb.NtlmPasswordAuthentication.<init>(NtlmPasswordAuthentication.java:207)
	at
jcifs.smb.NtlmPasswordAuthentication.<clinit>
                                       (NtlmPasswordAuthentication.java:164)
	at java.io.ObjectStreamClass.hasStaticInitializer(Native Method)
	at java.io.ObjectStreamClass.computeDefaultSUID(ObjectStreamClass.java:1641)
	at java.io.ObjectStreamClass.access$100(ObjectStreamClass.java:47)
	at java.io.ObjectStreamClass$1.run(ObjectStreamClass.java:175)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.io.ObjectStreamClass.getSerialVersionUID(ObjectStreamClass.java:172)
	at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:515)
	at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1546)
	at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1460)
	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1693)
	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1299)
	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:339)
	at
org.apache.catalina.session.StandardSession.readObject
                                                    (StandardSession.java:1371)
	at
org.apache.catalina.session.StandardSession.readObjectData
                                                     (StandardSession.java:863)
	at org.apache.catalina.session.StandardManager.load(StandardManager.java:440)
	at org.apache.catalina.session.StandardManager.start(StandardManager.java:655)
	at org.apache.catalina.core.StandardContext.start(StandardContext.java:3590)
...

- Peter




More information about the jcifs mailing list