[jcifs] Re: NTLM HTTP Filter Does Not Work With SMB Signing

[Dane Henry]

The values will change until the next time I restart, where I would surmise
that indeed they are being reset by a policy. If I simply set them and then
exit regedit, when I go back in (if I haven't restarted or logged off) the
values remain. That they are being reset isn't really a problem, if it comes
down to that these properties _need_ to remain, I can push to have them set
in the "standard" image of our company. Barring that however, even when the
noted changes are made, they don't seem to have an impact, and the
functioning of the filter is sporatic at best. Even when I can get it to
authenticate me through IE, it only works on my box, no one else's. As
stated before, my box is the one running the container (Tomcat), though it
is checking, correctly, the credentials against a Windows Server 2003 AD,
but only in Firefox. In summary:

Registry edits have been made and reset to default, neither seem to make an
impact.
FF, with the dialog box, works every time (barring proper credentials of
course).
IE is sporatic, though more often than not it doesn't work.
Fresh installs of Tomcat 5.5.17 and JCIFS 1.2.9 and Java (both 1.4.2_11 and
1.5.0_06)
Used the standard web.xml described in
http://jcifs.samba.org/src/docs/ntlmhttpauth.html, with log level 6.
Configured in IE to have the FQDN in the trusted Sites and the IP in the
intranet with neither working any differently from the others.

What is frustrating to me is that in the rare moments it occasionally works,
if I walk away for 5-10 mins, it might or might not work again, despite no
changes being made to any aspect of the system, container, code or anything.
Even with setting the flags |= NTLMSSP_NEGOTIATE_SIGN |
NTLMSSP_NEGOTIATE_SEAL |
           NTLMSSP_NEGOTIATE_128 | NTLMSSP_NEGOTIATE_NTLM2; in
jcifs.ntlmssp.Type2Message didn't seem to have an impact.
I'm completely at a loss at this point, and I don't know what else can be
done to get it to work.

Dane


On 6/2/06, Richard Caper < rcaper at gmail.com> wrote:
>
> The DLLfile and flag settings are documented here, but they are no
> longer actually used/needed:
>
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wininet/wininet/handling_authentication.asp
>
>
> (as you noted, as of IE 6 they don't have any relevance).
>
>
> On 6/2/06, Dane Henry <danehenry at gmail.com> wrote:
> > Well I just answered my own question; the registry entries have nothing
> to
> > do with the authentication. As of right now, it is still allowing me to
> > authenticate transparantly, but whenever anyone else attempts to do a
> log
> > on, whether I have previously logged on or just restarted with a freshly
>
> > downloaded .jar file, it still will not allow them to authenticate. It
> hangs
> > right where it was hanging for me, it'll pre-authenticate, but will not
> > authenticate the remote user. Any ideas or suggestions would be great.
> >
> > Dane
> >
> >
> > On 6/2/06, Dane Henry <danehenry at gmail.com> wrote:
> > >
> > > I think you were right about the older version of JCIFS, I removed and
>
> > deleted all that jar files, restarted and re-downloaded jcifs1.2.9.jarand
> > now it is allowing me to authenticate with IE. You, not surprisingly,
> were
> > also right about the log not printing 'The operation completed
> > successfully'. However when I tried it on another client, it was doing
> the
> > same thing it was doing for me previously, however since it is working
> on my
> > machine, I know it has to be a client configuration with IE. It isn't
> > related, yet, to the problem that you were describing of the access
> denied,
> > I'll test further to see if that pops up. I think what is different is
> in my
> > registry, HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet
> > Explorer\Security\NTLM
> > > I have a String Value 'DLLFile' set to Winsspi.dll and a DWORD Value
> > 'Flags' set to 0x08. This is different from the default, or at least the
> > default systems here, do you all think this might be what's allowing the
>
> > authentication?
> > >
> > >
> > >
> > > On 6/2/06, Michael B Allen < mba2000 at ioplex.com> wrote:
> > > > On Fri, 2 Jun 2006 08:37:49 -0400
> > > > "Dane Henry" <danehenry at gmail.com> wrote:
> > > >
> > > > >
> >
> SmbComSessionSetupAndXResponse[command=SMB_COM_SESSION_SETUP_ANDX,received=true,errorCode=The
>
> > > > > operation completed
> > > > > successfully.,flags=0x0098,fla
> > > >
> > > > I think you're using an old version of jCIFS. Newer versions of
> jCIFS do
> > > > not print 'The operation completed successfully.' for errorCode 0.
> They
> > > > just print errorCode=0.
> > > >
> > > > Seek and destroy jcifs.jar files and *restart until the jCIFS
> classes
> > > > are no longer found*. Then download a brand new jcifs 1.2.9 and
> > carefully
> > > > install that jar.
> > > >
> > > > I think there was a serious bug in SMB signing prior to 1.2.8. You
> must
> > > > be running 1.2.9 or SMB signing may not work.
> > > >
> > > > > I know that it is pre-authenticating, because if I remove the user
> > name and
> > > > > password from the filter, it gives me the error:
> > > >
> > > > Yup. Preauth is definitely working. That's good. But the problem
> we've
> > > > been talking about is that after a while SMB signing get's messed up
> > > > and people start getting "Access denied".
> > > >
> > > > > From what I've been seeing, all that is _not_ happening, is IE 6
> is
> > not
> > > > > sending the "3rd" handshake back to the server, unlike Firefox.
> And if
> > what
> > > >
> > > > Hmm, well if firefox works but IE doesn't that's a client issue.
> > > >
> > > > > I know of NTLM authentication is correct, it's this 3rd handshake
> that
> > > > > contains the user's name and information to be checked against the
> > server.
> > > > > This is occurring in Firefox simply because I provide the browser
> with
> > > > > credentials through the dialog box, however that defeats the
> purpose
> > of NTLM
> > > > > in my opinion. Any light that you or anyone else can shed on this
> > would be
> > > > > _amazing_.
> > > >
> > > > It sounds like transparent auth just isn't taking place in which
> case
> > > > read the section in the NTLM HTTP auth docs about that. For example,
>
> > > > make sure the workstation is actually joined to the domain. And when
> > > > you log into XP make sure that the domain (ie MAIN) is selected in
> the
> > > > domain dialog box. If it's something else like the local workstation
>
> > > > name *transparent* auth won't work.
> > > >
> > > > Mike
> > > >
> > >
> > >
> >
> >
>
-------------- next part --------------
HTML attachment scrubbed and removed