[jcifs] RE: Second user gets authentication prompt - inconsistent authentication results - "jcifs.smb.SmbAuthException: Access is denied"

[Paul ANDERSON]

Hi Mike,

Thanks. If signing is default on 2003 servers, many users will have this
problem, also with open source kit that includes jcifs (like Liferay).
If it doesn't work out of the box, it's a nightmare, and few people
would know where to start fixing it. The jcifs filter instructions have
only "SMB Signatures and Windows 2003" as a topic, which 'recommends'
settings; a note to indicate what happens if you don't set them - "2nd
user won't work, authn box will pop up" would be helpful (and maybe an
extract from your mail!)
The jcifs.smb.client.ssnLimit param didn't work for me though - I just
got the authentication dialog box popping up.
The preauth seems to work - I'm still experimenting with it.

I suspect people use the timeout fix because it "just works" - and it
doesn't need a dummy domain account. It worked nicely for me; at first I
thought there were occasional problems but my tester used Firefox by
mistake and it simply didn't have that server allowed for NTLM.

Paul.

-----Original Message-----
From: Michael B Allen [mailto:miallen at ioplex.com] 
Sent: Thursday, September 06, 2007 6:26 AM
To: Paul ANDERSON
Cc: jcifs at lists.samba.org
Subject: Re: [jcifs] RE: Second user gets authentication prompt -
inconsistent authentication results - "jcifs.smb.SmbAuthException:
Access is denied"

On Thu, 6 Sep 2007 10:09:21 +0100
"Paul ANDERSON" <panderson at wta.dz> wrote:

> I tried increasing the timeout with jcifs 1.2.17 according to previous
> forum posts and it's OK - not all the time though apparently, some
users
> get the authentication box.
> 
> What's a timeout got to do with signing - why does it appear as a
> signing error? I know some people tried disabling signing on the
server
> side where the client doesn't require it, but it made no difference
for
> them.

Hi Paul,

This is the official word on the topic of the JCIFS NTLM HTTP
Authentication Filter and the jcifs.smb.client.soTimeout property with
respect to SMB signing.

To the best of my knowledge, SMB signing in JCIFS works
perfectly. However, it appears to be common for people to have problems
with it when using the JCIFS NTLM HTTP Authentication Filter. There
could be several possible reasons:

  1. It is not clear if they are not reading and understanding the NTLM
  HTTP Filter documentation with respect to providing valid credentials
  for initializing the signing digest code.

  2. The signing digest is specific to the domain controller being used
  to authenticate clients. If something about the infrastructure affects
  that requirement the digest will be invalid.

  3. NTLMv2 may somehow be involved. I have not been paying much
attention
  to the NTLMv2 discussions but Eric has been hovering lately so perhaps
  he can provide a definitive answer as to whether or not it is or is
  not a factor with respect to the Filter.

The jcifs.smb.client.soTimeout property cannot be used to fix SMB
signature errors [1]. No one should ever use the soTimeout property to
bypass signature errors. I'm not really sure why people try changing
that
property. I don't recall ever telling anyone to change it. But someone
did and posted here and it's just been perpetuated through the archives
I guess.

> Someone contributed a patch for signing a few days ago - could the
> issues be linked?

No. As far as I know SMB signing with respect to the Filter works
perfectly.

Mike

[1] Setting a low soTimeout just causes the transport to close shortly
after the user is authenticated thereby causing the signing digest to
be reinitialized for the next user. The problems are that a brief lag in
communication will cause the transport to close before the
authentication
has completed or two or more authentications in quick succession will
still cause an SMB signing error.

-- 
Michael B Allen
PHP Active Directory Kerberos SSO
http://www.ioplex.com/