[jcifs] How long is a NtlmPasswordAuthentication object valid
?
Eric
eglass1 at comcast.net
Thu Jul 17 10:34:31 EST 2003
>
> Here's the tricky part. The NPA password hases should be updated *in-place* if the
> client reauthenticates NTLM. So in theory the client could negotiate NTLM http
> authentication from which you get an NPA object and use that to access files, named
> pipes, etc. Then the transport to the target SMB server closes invalidating the NPA
> password hashes because the server challenge is now wrong. Now the client makes
> another request re-negotiating NTLM http authentication which updates the NPA
> password hashes *in-place* and you can go about your business with the *same*
> NtlmPasswordAuthenctication object.
>
> At one time this did work like that but I haven't tested this in a while. Can you confirm
> Eric?
>
Currently it creates a new NPA with the new hashes (rather than updating
the ansiHash/unicodeHash) and replaces the NPA in the session. I
don't remember it doing an in-place changeout, but it may have before I
was involved; currently I don't think the NPA has a facility for
changing out the hashes once the object is constructed. I don't see any
reason why it *couldn't*; from the HTTP side of things, we would just do
something like:
if (auth == null) {
auth = new NtlmPasswordAuthentication(domain, user,
lmResponse, ntResponse);
} else {
synchronized (auth) {
auth.setAnsiHash(lmResponse);
auth.setUnicodeHash(ntResponse);
}
}
probably passing in the current auth (or null) to NtlmSsp, and returning
either a new NPA or the current NPA with new hashes. If there aren't
any issues arising from the current scheme, I would be a bit wary of
poking around; but on the other hand I'm always game for a bit of
experimentation.
Eric
More information about the jcifs
mailing list