[jcifs] The SmbTransport for getChallenge() and logon() must be the same? why?

[Michael B Allen]

On Fri, 6 May 2005 16:15:59 +0200 (MEST)
"Xaver Fischer" <Xaver.Fischer at gmx.de> wrote:

> Hi,
> 
> at first I have to admit that I'm quite new to the JCIFS and SMB stuff.
> I would like to use it to achieve SSO in an HTTP environment to my
> application. To our current system topology it would best fit to do the
> HTTP challenge and negotiation stuff in my servlet engine, but do the
> check of the credential in my own Login service, which then creates a
> accessToken specific for my application. This would imply that the
> SmbSession.getChallenge() would be done by another process as the
> SmbSession.logon() and thus by two different SmbTransports and
> SmbSessions. Both going to the same domain controller.
> 
> What I learned by trying this "greenly" is that the same
> SmbTransport/SmbSession must be used for these two actions. It seems to me
> as if the domain controller creates the challenge, stores it for this
> client's session internally and uses it for verifying the password hash
> later. 
> 
> Am I right? Can someone confirm or correct me?
> 
> Is there some workaround, so that I can separate the HTTP handshake stuff
> from the real password hash check into two processes? 
> 
> I neither like the idea to do the SmbSession.logon() in the servlet engine
> and as a consequence have to ensure that the instance creating my internal
> accesstoken can trust this servlet (maybe by some digital signature) nor
> do I like the idea to do the whole handshake at my Login service.

I don't fully understand exactly what you're trying to do but the
challenge is specific to the transport (to the DC) from which it
came. After it has been passed to the client, the client should return
password hashes which can only be validated against the DC from which
the challenge came. So you cannot authenticate in part or in whole with
one machine and then use those credentials to access another machine.

Note that 1.1.11trans has a modification to NtlmHttpFilter that might
interest you. It has a separate negotiate() method that doFilter
calls(). This allows you to extend the filter and override doFilter
to either do custom authentication or call negotiate to do NTLM HTTP
Authentication.

Mike

-- 
IRC - where men are men, women are men, and the boys are FBI agents.