[jcifs] strange behavior

Aaron J Weber aweber at comcast.net
Fri Jul 8 18:49:17 GMT 2005


Thanks for all those tips.  I tested Logon.class against the .115 DC, and it succeeded every time!  How could that be?  Is that code significantly different?  Is it possible that 115 has its IPC$ service closed somehow, someway?

Also, I noticed with my app that there are a LOT of authentication requests...for example when my main page comes-up (which uses frames), there are at least 4 auth requests for the user...and as the user progresses thru the app, it continues.  That's gonna irk the networking guys a bit.  I looked thru the different config settings, but didn't find anything to "cache" the users credentials and/or allow the user to remain "auto-authenticated" for a period of time.

For example, I'd like to set a param that, once a user is successfully authenticated, additional auth requests are NOT re-authenticated until a timeout of 15 minutes?

Thanks,
AJ
  Sent: Friday, July 08, 2005 1:53 PM
  Subject: Re: [jcifs] strange behavior



  > Found something in stdout.   It looks (to the untrained-eye) like some DCs are authenticating the user, and others are not?  Can anyone tell me what they think of this?  THANKS!

  Yeah, that would be pretty weird but I suppose it's possible. Try using jcifs.http.domainController for a while. Also I can see you're not specifying jcifs.smb.client.username/password for preauth. I thought you were doing that? Just put init-params for domainController=<ip of successful dc>, wins, and then domain/username/password for preauth. That's a sort of "safe-mode" setup. There's no load balancing or anything like that so we narrow the number of possibilities a little.

  > session established ok with AMER<1C>/148.168.199.121
  > requesting negotiation with AMER<1C>/148.168.199.121
  > byteCount=42 but readBytesWireFormat returned 16

  These "byteCount" messages are normal.

  > Default credentials (jcifs.smb.client.username/password) not specified. SMB signing may not work propertly.  Skipping DC interrogation.

  The above means you're not getting setting domain/username/password for preauth.

  > treeConnect: unc=\\10.1.4.115\IPC$,service=?????
  > NtlmHttpFilter: AMER\ITConsult: 0xC000006D: jcifs.smb.SmbAuthException: Logon failure: unknown user name or bad password.

  Try running the LoginTest example (or something like that) to test these credentials manually against this specific DC to see if it really doesn't own those credentials.

  > java.io.InterruptedIOException
  >  at java.net.PlainDatagramSocketImpl.receive(Ljava.net.DatagramPacket;Z)V(Unknown Source)
  >  at java.net.PlainDatagramSocketImpl.receive(Ljava.net.DatagramPacket;)V(Unknown Source)
  >  at java.net.DatagramSocket.receive(Ljava.net.DatagramPacket;)V(Unknown Source)
  >  at jcifs.netbios.NameServiceClient.run()V(NameServiceClient.java:184)
  >  at java.lang.Thread.run()V(Unknown Source)
  >  at java.lang.Thread.startThreadFromVM(Ljava.lang.Thread;)V(Unknown Source)

  I think this is normal. Again this is just the transport timing out after being idle for 10 minutes.

  Mike
-------------- next part --------------
HTML attachment scrubbed and removed


More information about the jcifs mailing list