[jcifs] RE: Authentication: NTLM

[Allen, Michael B (RSCH)]

First, I don't know alot about servlets and such so please direct your messages
to the jcifs at samba.org mailing list so that people who do understand can help
sort these issues out. I'm just doing this based on my knowledge of networking
and http.

> -----Original Message-----
> From:	skeetz [SMTP:skeetz at 8thdeadlysim.com]
> Sent:	Friday, August 09, 2002 12:42 PM
> To:	Allen, Michael B (RSCH)
> Subject:	RE: Authentication: NTLM
> 
> I am waiting for instructions to signup on the list.  Here is what I've
> discovered using this.
> 
> 1) I think ie expects to get authenticated page.
> 
	What is an "authenticated page"?

> 2) ie won't post any form data until it has finished this process.
> so you have to authenticate every time.
> 
	Not sure what you mean here. You don't have to authenticate "every time". The
	server provokes the NTLM authentication mechanism and therefore decides
	who needs to authenticate and how often. Perhaps you are using POST instead
	of GET? In this case my intention was that you call NtlmHttpSession.logon
	from within your doPost but I have never tried. Or are you saying that IE
	changes it's behavior once you've negotiated NTLM?

>   So what I did:
> 1) made a filter so that each page can be authenticated with out really
> messing with the jsp/htm/zip/whatever files.
> 
	I'll look at your code but I'm getting more confused now.

> 2) made it so the ip for the primary domain controler is an init-param.
> 
	Why is this useful? Are the "domain" and "soTimeout" properties init
	parameters too? Perhaps these properties should be attributes? Are you trying
	to avoid the jcifs.properties file JRE parameter? If so, we could make the
	jcifs.properties file and "init-parameter". Actually, what exactly is an "init
	parameter". Do you mean a logon() method parameter?

> 3) made it so that it will authenticate the first time and save the
> challenge and the browser's encoded 3rd message.  Then on future pages, it
> just sends the same challenge and test the if the encoded response is the
> same as the saved one.
> 
	The jCIFS SmbSession class already essentially does this. If an SmbSession
	exists with a matching password hash it will reuse that session making the
	SmbSession.logon() method a no-op. So if you want to just provoke the
	NTLM password hash negotiation "every time" we could just reorganize the
	NtlmHttpSession.logon() code to perform the whole process (or part of it)
	each time. But it's not clear to me that this is necessary.

> I didn't do stress testing on what you had, but once my deal authenticates,
> it is only a matter of a string compare (on the third attempt of course).
> Also if the domainControler (ip) is given it runs alot faster not having to
> do the netbios lookup.
> 
	It shouldn't be slower to the point that you could notice. If it is, your name
	service is timing out and trying another resolution method. If you have a
	wins server and you set the wins and resolveOrder=WINS properties it
	should be just as fast and after the first lookup the name is cached.

> I've attached a slimed downed version of what I'm using for my project.  I
> hope this helps.  You'll probably pissed that I didn't follow your coding
> standard.  I'm just used to two spaces and certain other things.  Anyway it
> should give you an idea.
> 
> skeetz
> p.s. Thanks again for getting this to work.
> 
	You welcome. I'll look at your code and try to decipher what your talking about
	but it might take me a while. I have never used servlets or jsps. If someone can
	explain to me exactly how this should work in an optimal way it would be
	great to sort this out right away and do an updated release.

	Mike