[jcifs] HTTP Authentication failing

[Scrumpy Jak]

Hi all

We have a setup where http auth was working fine, then stopped overnight - never
to work again. The environment is (Note: we have updated Tomcat and jCIFS since
the issue started). We are not aware of any environmental changes, but assume a
Microsoft Patch must had been applied. The DC referenced below was shut down for
other reasons and on restart this problem surfaced. :

Windows 2003 based Active Directory
Tomcat 4.1.30 Webserver
jCIFS 1.2.0 (Have tried many)
servlet containing the following simple filter:
<init-param>
<param-name>jcifs.smb.client.domain</param-name>
<param-value>xyzdomain</param-value>
</init-param>

The first user to connect to the website connects fine, subsequent attempts by
other users will fail. Swapping users confirms it is always the first. In
addition, periodically authentication will fail for all and againstart working
for the first user some time later.

Have tried setting:
jcifs.smb.client.{domain,username,password}
jcifs.smb.client.ssnLimit to 1

Have tried many versions of jCIFS and Tomcat

Etehereal capture show:
SMB Command: Session Setup AndX (0x73)
NT Status: STATUS_ACCESS_DENIED (0xc0000022)
for the second connection (This is to the webserver from the DC)

Browser shows:
jcifs.smb.SmbException: Connection refused: connect
at jcifs.smb.SmbTransport.send(SmbTransport.java:476)
at jcifs.smb.SmbTransport.negotiate(SmbTransport.java:664)

This is way out of my league so I'm hopeful someone might have some useful tips.

jCIFS 1.2.0 was my last hope - under some testing we get slightly different
results, but still no success. Additionally, we no longer get errors in browser
or logs and just end up with a blank page (The exception error above was from an
earlier version of jCIFS).

Does anyone know of any good tools or testing tips that might narrow this issue
down?

It seems to me that the initial connection is made from the Webserver to the DC
using the first user's credentials. Any subsequent connection is being refused
because the credentials don't match. How can I retain autologon functionality
yet have authentication succeed?

Thanks in advance!!!!!

Cheers
Paul

[Scrumpy Jak]

Scrumpy Jak <paul.pree <at> bmssolutions.com> writes:
Sorry - wrong cut and paste..... The web.xml contains:

<init-param>
<param-name>jcifs.smb.client.domainController</param-name>
<param-value>192.168.7.56</param-value>
</init-param>

I realise the earlier entry would require a matchin WINS setting - No Wins
is in use on that network.

Thanks
Paul

[Michael B Allen]

Paul,

When something is working fine and then suddenly stops working it is NOT a good idea to simply start changing parameters, containers, lib versions, etc. You should have isolated the source of failure when the problem first appeared.

Use jcifs-1.1.11.jar and set jcifs.http.domainController and jcifs.smb.client.{domain,username,password} to a known acct in that domain. Set NOTHING else. Restart the container and try it again.

We get about 1500 downloads a month and most people are using the filter so I think there's something fundamentally wrong with your setup (firewall?). Trying different versions of jcifs isn't going to help.

Mike

On Tue, 7 Jun 2005 03:52:41 +0000 (UTC)

Post by Scrumpy Jak
Hi all
We have a setup where http auth was working fine, then stopped overnight - never
to work again. The environment is (Note: we have updated Tomcat and jCIFS since
the issue started). We are not aware of any environmental changes, but assume a
Microsoft Patch must had been applied. The DC referenced below was shut down for
Windows 2003 based Active Directory
Tomcat 4.1.30 Webserver
jCIFS 1.2.0 (Have tried many)
<init-param>
<param-name>jcifs.smb.client.domain</param-name>
<param-value>xyzdomain</param-value>
</init-param>
The first user to connect to the website connects fine, subsequent attempts by
other users will fail. Swapping users confirms it is always the first. In
addition, periodically authentication will fail for all and againstart working
for the first user some time later.
jcifs.smb.client.{domain,username,password}
jcifs.smb.client.ssnLimit to 1
Have tried many versions of jCIFS and Tomcat
SMB Command: Session Setup AndX (0x73)
NT Status: STATUS_ACCESS_DENIED (0xc0000022)
for the second connection (This is to the webserver from the DC)
jcifs.smb.SmbException: Connection refused: connect
at jcifs.smb.SmbTransport.send(SmbTransport.java:476)
at jcifs.smb.SmbTransport.negotiate(SmbTransport.java:664)
This is way out of my league so I'm hopeful someone might have some useful tips.
jCIFS 1.2.0 was my last hope - under some testing we get slightly different
results, but still no success. Additionally, we no longer get errors in browser
or logs and just end up with a blank page (The exception error above was from an
earlier version of jCIFS).
Does anyone know of any good tools or testing tips that might narrow this issue
down?
It seems to me that the initial connection is made from the Webserver to the DC
using the first user's credentials. Any subsequent connection is being refused
because the credentials don't match. How can I retain autologon functionality
yet have authentication succeed?
Thanks in advance!!!!!
Cheers
Paul

[Scrumpy Jak]

Post by Michael B Allen
Paul,
When something is working fine and then suddenly stops working it is NOT a
good idea to simply start changing parameters, containers, lib versions, etc.
You should have isolated the source of failure when the problem first
appeared.
Use jcifs-1.1.11.jar and set jcifs.http.domainController and
jcifs.smb.client.{domain,username,password} to a known acct in that domain.
Set NOTHING else.
Restart the container and try it again.
We get about 1500 downloads a month and most people are using the filter so I
think there's something fundamentally wrong with your setup (firewall?).
Trying different versions of jcifs isn't going to help.
Mike

Thanks for your input Mike. I gave the Readers Digest version earlier - we spent
quite a bit of time trying to pinpoint the root cause to no avail. The manager
of the AD and Webserver insists no system change were made, so we were stuck
with that.

We were running Tomcat 4.1.24 and jCIFS 1.1.0. The problem had previously
occurred about 6 months ago, and the fix applied at the time was upgrading from
jcifs 0.7.3 to 1.1.0.

After trying to isolate the issue we chose to install a more current version of
Tomcat - 4.1.30 and jCIFS - 1.1.11 (Which we plan to stick with). We felt that
these version improved our chance of getting it working.

I have tried as you suggested - removing jcifs 1.2.0 and putting 1.1.11 back.

Post by Michael B Allen
<filter>
<filter-name>NtlmHttpFilter</filter-name>
<filter-class>jcifs.http.NtlmHttpFilter</filter-class>
<init-param>
<param-name>jcifs.http.domainController</param-name>
<param-value>192.168.20.101</param-value>
</init-param>
<init-param>
<param-name>jcifs.smb.client.domain</param-name>
<param-value>mydomain</param-value>
</init-param>
<init-param>
<param-name>jcifs.smb.client.username</param-name>
<param-value>validusername</param-value>
</init-param>
<init-param>
<param-name>jcifs.smb.client.password</param-name>
<param-value>validpassword</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>NtlmHttpFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>

The browser then comes back with
jcifs.smb.SmbException: Failed to negotiate
jcifs.smb.SmbException: Timeout trying to open socket
java.net.ConnectException: Connection Refused: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)

Note: This fails for all users (Not just the first)

I agree that there is something screwy with our environment - We just can't
pinpoint it! As you can also guess, my knowledge in this area is limited!

Thanks for your patience!
Paul

[Richard Caper]

This particular case looks to be failing to connect to the target
server on a lower level than jCIFS. Can you telnet from the Tomcat
server to 192.168.20.101 on port 139 (i.e. "telnet 192.168.20.101
139")? It looks to be a basic connectivity issue here (not sure about
the previous errors). I believe the newer versions of jCIFS use
whichever of 139 and 445 is available (which may be why you are
getting different errors with 1.2.0).

Post by Scrumpy Jak

Post by Michael B Allen
<filter>
<filter-name>NtlmHttpFilter</filter-name>
<filter-class>jcifs.http.NtlmHttpFilter</filter-class>
<init-param>
<param-name>jcifs.http.domainController</param-name>
<param-value>192.168.20.101</param-value>
</init-param>
<init-param>
<param-name>jcifs.smb.client.domain</param-name>
<param-value>mydomain</param-value>
</init-param>
<init-param>
<param-name>jcifs.smb.client.username</param-name>
<param-value>validusername</param-value>
</init-param>
<init-param>
<param-name>jcifs.smb.client.password</param-name>
<param-value>validpassword</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>NtlmHttpFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>

The browser then comes back with
jcifs.smb.SmbException: Failed to negotiate
jcifs.smb.SmbException: Timeout trying to open socket
java.net.ConnectException: Connection Refused: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)
Note: This fails for all users (Not just the first)
I agree that there is something screwy with our environment - We just can't
pinpoint it! As you can also guess, my knowledge in this area is limited!
Thanks for your patience!
Paul

[Scrumpy Jak]

Post by Richard Caper
This particular case looks to be failing to connect to the target
server on a lower level than jCIFS. Can you telnet from the Tomcat
server to 192.168.20.101 on port 139 (i.e. "telnet 192.168.20.101
139")? It looks to be a basic connectivity issue here (not sure about
the previous errors). I believe the newer versions of jCIFS use
whichever of 139 and 445 is available (which may be why you are
getting different errors with 1.2.0).

Hi Richard

No, I can't telnet to port 139 on either of the DC's we have access to.
Port 445 connects fine.

Would you expect port 139 to be available? Given that we are using 1.1.11
or 1.2.0 will it be necessary for this to be opened up?

Note that the DC's are on the same subnet.
No intentional security tightening occurred on the servers on question.

Thanks for your help!
Cheers
Paul

[Michael B Allen]

Post by Scrumpy Jak

Post by Richard Caper
This particular case looks to be failing to connect to the target
server on a lower level than jCIFS. Can you telnet from the Tomcat
server to 192.168.20.101 on port 139 (i.e. "telnet 192.168.20.101
139")? It looks to be a basic connectivity issue here (not sure about
the previous errors). I believe the newer versions of jCIFS use
whichever of 139 and 445 is available (which may be why you are
getting different errors with 1.2.0).

Hi Richard
No, I can't telnet to port 139 on either of the DC's we have access to.
Port 445 connects fine.

JCIFS 1.1.11 will NOT work without port 139. This is obviously a
significant environmental change if it worked before.

It so happends that 1.2.0 does work with port 445. You might want to try
that. Use the same config. Just eradicate all other jars and drop in
1.2.0.

Mike

[Scrumpy Jak]

Michael B Allen <mba2000 <at> ioplex.com> writes:
Thanks Michael

Post by Michael B Allen
JCIFS 1.1.11 will NOT work without port 139. This is obviously a
significant environmental change if it worked before.

Thanks for the ammo. I confirmed that 139 was not open and it now turns out
that someone had intentionally disabled it as part of their plan to remove
netbios.....without telling anyone.....

Post by Michael B Allen
It so happens that 1.2.0 does work with port 445. You might want to try
that. Use the same config. Just eradicate all other jars and drop in
1.2.0.

Port 139 is now functioning so I was ever hopeful that the issue was gone, but
I'm still stuck.

I tested (from a remote machine) access to this box and get differing results
with jCIFS 1.1.11 and 1.2.0. However, in both cases the first user to connect
gets in and autologon works. The second user cannot get in. First user can log
off and can log in from multiple machines. Second user has no access.
Swapping users after a restart of Tomcat still means that whoever gets there
first gets access.

jCIFS 1.2.0
Second user gets an NT dialog box headed
Connect to JCIFS20_181_61 in password (Where password is from the web.xml file)
It expects ***@domain.com.au but doesn't accept any valid combination.

jCIFS 1.1.11
Second user gets
jcifs.smb.SmbException: Unverified Signature: 0.0.0.0<00>/192.168.20.101
(Which is the IP of the domain controller specified in web.xml)
at jcifs.smb.SmbTransport.send(SmbTransport.java:674)

Do you have any idea where I should go from here? I've been at this point a
number of times where I think I've got it working, but only the first user
gets connected.

Thanks again
Regards
paul

Post by Michael B Allen
Mike

[Michael B Allen]

On Wed, 8 Jun 2005 07:33:41 +0000 (UTC)

Post by Scrumpy Jak
jCIFS 1.1.11
Second user gets
jcifs.smb.SmbException: Unverified Signature: 0.0.0.0<00>/192.168.20.101
(Which is the IP of the domain controller specified in web.xml)
at jcifs.smb.SmbTransport.send(SmbTransport.java:674)

With a valid jcifs.smb.client.{domain,username,password} supplied
for "preauthentication" you should not get "Unverified Signature"
exceptions.

Mike

[Scrumpy Jak]

Post by Michael B Allen
With a valid jcifs.smb.client.{domain,username,password} supplied
for "preauthentication" you should not get "Unverified Signature"
exceptions.

Thanks Mike. Dumb mistake. When I cut and pasted the domain,username,password
filters I neglected to change the 'domain' to 'password' so it was setting the
domian twice, and no password. Doh!

However.....

We are now getting closer to a solution, but there is still some inconsistency.
- when using jCIFS 1.1.11 and pointing to our Windows2003 DC it fails. This
server has had netbios re-enabled, but is unable to be rebooted yet.

- when using jCIFS 1.1.11 and pointing to an old windows 2000 DC (on a remote
site)it works fine

By removing jCIFS 1.1.11, replacing it with jCIFS 1.2.0 and changing nothing
else it works fine
By pointing back to the Windows 2003 DC it reverts to letting the first user in
and failing for the second.

Since we have a working setup I'll drop the issue until the DC has been rebooted.
If it works after that, given that only netbios has been re-enabled, then this
would not make sense since 1.2.0 does not use netbios.
If it still fails, then I have to try and find what was changed on this machine,
despite assurances that "nothing was changed'.

I guess I'm saying that either way I'm still not out of the woods, but really
appreciate your help as we have progressed a long way based on your input.

Thanks again
Paul

[Michael B Allen]

On Thu, 9 Jun 2005 05:58:45 +0000 (UTC)

Post by Scrumpy Jak
By removing jCIFS 1.1.11, replacing it with jCIFS 1.2.0 and changing nothing
else it works fine
By pointing back to the Windows 2003 DC it reverts to letting the first user in
and failing for the second.

After glancing at the code I realize I left the signing code in total
disarray in 1.2.0. It will need to be fixed.

Use 1.1.11. If you can't get infrastructure to turn on port 139 use a
workstation w/ 139 enabled as the "domainController". It will be slightly
slower because you're going through a middle man but jCIFS scales very
well. I don't even think you'll notice the difference.

Then when I fix 1.2 signing code you can point back to the win2k3 DC.

Mike

[Andreas Knoor]

Hi Mike,

Post by Michael B Allen
Then when I fix 1.2 signing code you can point back to the win2k3 DC.

do you hava idea when this will be done?

Regards,

Andreas

[Michael B Allen]

The SMB signing code in 1.2 is fixed and will be released RSN.

Post by Michael B Allen
On Thu, 9 Jun 2005 05:58:45 +0000 (UTC)

Post by Scrumpy Jak
By removing jCIFS 1.1.11, replacing it with jCIFS 1.2.0 and changing nothing
else it works fine
By pointing back to the Windows 2003 DC it reverts to letting the first user in
and failing for the second.

After glancing at the code I realize I left the signing code in total
disarray in 1.2.0. It will need to be fixed.
Use 1.1.11. If you can't get infrastructure to turn on port 139 use a
workstation w/ 139 enabled as the "domainController". It will be slightly
slower because you're going through a middle man but jCIFS scales very
well. I don't even think you'll notice the difference.
Then when I fix 1.2 signing code you can point back to the win2k3 DC.
Mike

[Michael B Allen]

On Tue, 7 Jun 2005 09:37:20 +0000 (UTC)

Post by Scrumpy Jak

Post by Michael B Allen
<filter>
<filter-name>NtlmHttpFilter</filter-name>
<filter-class>jcifs.http.NtlmHttpFilter</filter-class>
<init-param>
<param-name>jcifs.http.domainController</param-name>
<param-value>192.168.20.101</param-value>
</init-param>
<init-param>
<param-name>jcifs.smb.client.domain</param-name>
<param-value>mydomain</param-value>
</init-param>
<init-param>
<param-name>jcifs.smb.client.username</param-name>
<param-value>validusername</param-value>
</init-param>
<init-param>
<param-name>jcifs.smb.client.password</param-name>
<param-value>validpassword</param-value>
</init-param>
</filter>

Looks good. You can also set jcifs.util.loglevel = 2 maybe.

Post by Scrumpy Jak

Post by Michael B Allen
<filter-mapping>
<filter-name>NtlmHttpFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>

The browser then comes back with
jcifs.smb.SmbException: Failed to negotiate
jcifs.smb.SmbException: Timeout trying to open socket
java.net.ConnectException: Connection Refused: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)
Note: This fails for all users (Not just the first)

You need to figure out where you first encounter an error. You have
mentioned several symptoms but good scientific method would suggest
isolating the first occurance of a problem (maybe it's not even an
error). Other subsequent errors could just be an artifact of previous
conditions.

Post by Scrumpy Jak
I agree that there is something screwy with our environment - We just can't
pinpoint it! As you can also guess, my knowledge in this area is limited!

You need a network engineer. It could be that port 139 is being
blocked. Are you in an XP/200x only environment?

Mike

[Scrumpy Jak]

Post by Michael B Allen
Looks good. You can also set jcifs.util.loglevel = 2 maybe.

Will do.

Post by Michael B Allen
You need to figure out where you first encounter an error. You have
mentioned several symptoms but good scientific method would suggest
isolating the first occurance of a problem (maybe it's not even an
error). Other subsequent errors could just be an artifact of previous
conditions.

Post by Scrumpy Jak
I agree that there is something screwy with our environment - We just can't
pinpoint it! As you can also guess, my knowledge in this area is limited!

You need a network engineer. It could be that port 139 is being
blocked. Are you in an XP/200x only environment?

Both the DC's and Tomcat server are Windows 2003 Server. Most clients are
Windows 2000, and many use a Windows 2003 Terminal Server to lauch their web
broswer.

Post by Michael B Allen
Mike

Not sure if this is important - but my primary test is running a browser on the
Web server itself and pointing to localhost.

Anyway, thanks again for your valuable input. I am arranging for a network
engineer to take a look, but will continue to try and work through the problem
as that may not be possible for a week or so (Remote site).

Thanks
Paul

[Michael B Allen]

Post by Scrumpy Jak
Not sure if this is important - but my primary test is running a browser on the
Web server itself and pointing to localhost.

Yes, that has been known to cause problems as Windows sometimes lacks a
loopback adapter (e.g. laptops). I recommend using a different machine to
test.

Mike