[jcifs] strange behavior

[Michael B Allen]

On Fri, 8 Jul 2005 13:19:45 -0400
"Aaron J Weber" <aweber at comcast.net> wrote:

> 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