[jcifs] Exception: Invalid access to memory location

Michael B Allen mba2000 at ioplex.com
Mon Oct 18 18:10:36 GMT 2004


All basically right but a few things...

On Mon, 18 Oct 2004 08:08:30 -0500
Tapperson Kevin <Kevin.Tapperson at eHC.com> wrote:

> My guess is that the 8 byte challenge
> value itself is somehow tied to a memory location on the domain controller
> that generated it.

Not quite. The status NT_STATUS_ACCESS_VIOLATION is not returned
by the server but artifically thrown whenever auth.challenge !=
session.transport.server.encryptionKey. Meaning the challenge being used
did not come from the domain controller against which the auth is being
validated. But you're right that the problem is that different domain
controllers are being queryed during the negotiation.

JCIFS 1.1.0 fixes this by adding a SmbSession.getChallengeForDomain
function that returns an NtlmChallenge object that contains both the
challenge and the UniAddress of the domain from which it came. So
the solution is to upgrade to this version, use that method to get
the challenge/addres and put that in the session after you get the
type-1-message. Now you can retrieve that attribute during the negotiation
and be sure the challenge and DC address always stick together.

> If you replace the steps listed above with the following, it should go
> away: 3) save the address of the domain controller used in step 2 in the
> HttpSession
> 6) retrieve the saved address of the domain controller from the
> HttpSession 7) submit the challenge (can be re-acquired with
> SmbSession.getChallenge(dc)) along with the LM and NT responses received
> in step 5 to domain controller A (which was saved in the HttpSession)

SmbSession.getChallengeForDomain rotates evenly through the list of DCs
and will failover to another DC if the one queried is not responding. I
highly recommend using that as opposed to the above but what you say
should work ok.

Mike

-- 
Greedo shoots first? Not in my Star Wars.


More information about the jcifs mailing list