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

Dane Henry danehenry at gmail.com
Mon Jun 5 13:28:05 GMT 2006


One thing that just popped into my head, I am right now just using "MAIN" as
my domain, but the full domain name is MAIN.xxx.xxxx.xxx, which, if counted
adds up to 17, however as noted previously in the lists, JCIFS only allows
15 characters for the domain name. While obviously this isn't a completely
detremental issue, since it is in fact preauthenticating, and in the case of
FF actually authenticating, I'm just trying to consider everything that
_could_ be an issue. Lemme know if I'm way off base of if this is actually
something to consider.

Dane

On 6/5/06, Dane Henry <danehenry at gmail.com> wrote:
>
> 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_11and
> 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


More information about the jcifs mailing list