[jcifs] Problems authenticating to Mac OS X server

[Trejkaz]

Hi all.

I wrote a test program which was eventually supposed to time file transfers
with jCIFS so that I could compare it with HTTP clients.

The test program is pretty simple (but as I haven't been able to connect yet,
I'm not confident that it's correct):

import jcifs.smb.NtlmPasswordAuthentication;
import jcifs.smb.SmbFile;

public class TestCifs {
public static void main(String[] args) throws Exception {
String domain = ""; // have tried the actual name too
String user = "<your_user_here>";
String pass = "<your_pass_here>";
String host = "192.168.1.66";
String share = "Shared";
String relativePath = "path/to/100MiB";

//TODO: Figure out if this is a real URL (for escaping)
NtlmPasswordAuthentication auth =
new NtlmPasswordAuthentication(domain, user, pass);
String url = String.format("smb://%s/%s/%s", host, share,
relativePath);
SmbFile smbFile = new SmbFile(url, auth);
smbFile.getInputStream().close();
}
}

When I run this, I get an error:

Exception in thread "main" jcifs.smb.SmbAuthException: Logon failure:
unknown user name or bad password.
at jcifs.smb.SmbTransport.checkStatus(SmbTransport.java:596)
at jcifs.smb.SmbTransport.send(SmbTransport.java:722)
at jcifs.smb.SmbSession.sessionSetup(SmbSession.java:428)
at jcifs.smb.SmbSession.send(SmbSession.java:239)
at jcifs.smb.SmbTree.treeConnect(SmbTree.java:176)
at jcifs.smb.SmbFile.doConnect(SmbFile.java:925)
at jcifs.smb.SmbFile.connect(SmbFile.java:974)
at jcifs.smb.SmbFile.connect0(SmbFile.java:890)
at jcifs.smb.SmbFile.open0(SmbFile.java:992)
at jcifs.smb.SmbFile.open(SmbFile.java:1026)
at jcifs.smb.SmbFileInputStream.<init>(SmbFileInputStream.java:73)
at jcifs.smb.SmbFileInputStream.<init>(SmbFileInputStream.java:65)
at jcifs.smb.SmbFile.getInputStream(SmbFile.java:2867)
at TestCifs.main(TestCifs.java:24)

If I look at the packet dumps, it gets rejected before it even sends the
username or password, so "unknown user name or bad password" is really a
bit misleading. I guess that STATUS_LOGON_FAILURE simply maps to that
message.

I trimmed the packet dump down to just this connection:
https://www.cloudshark.org/captures/3340b558229a

The file server is running on OSX and both Windows and other Mac clients are
happily connecting to it. smbclient has an error connecting but it seems to at
least authenticate successfully before getting some other error. I have dumps
for all of those too, but am significantly less confident that their contents
don't contain my credentials. ;)

I'm kind of at a loss for how to proceed though, at this point. I was hoping
to use jCIFS as an alternative to people having to manually mount the file
shares, but if there are servers it can't connect to...

TX

[Michael B Allen]

Post by Trejkaz
Hi all.
I wrote a test program which was eventually supposed to time file transfers
with jCIFS so that I could compare it with HTTP clients.
The test program is pretty simple (but as I haven't been able to connect yet,
import jcifs.smb.NtlmPasswordAuthentication;
import jcifs.smb.SmbFile;
public class TestCifs {
public static void main(String[] args) throws Exception {
String domain = ""; // have tried the actual name too
String user = "<your_user_here>";
String pass = "<your_pass_here>";
String host = "192.168.1.66";
String share = "Shared";
String relativePath = "path/to/100MiB";
//TODO: Figure out if this is a real URL (for escaping)
NtlmPasswordAuthentication auth =
new NtlmPasswordAuthentication(domain, user, pass);
String url = String.format("smb://%s/%s/%s", host, share,
relativePath);
SmbFile smbFile = new SmbFile(url, auth);
smbFile.getInputStream().close();
}
}
unknown user name or bad password.
at jcifs.smb.SmbTransport.checkStatus(SmbTransport.java:596)
at jcifs.smb.SmbTransport.send(SmbTransport.java:722)
at jcifs.smb.SmbSession.sessionSetup(SmbSession.java:428)

Hi Trejkaz,

Try the machine name for the domain.

Also try using a fully qualified DNS hostname instead of the IP.

I'm not aware of mac having an issue like this. It should work. The
SESSION_SETUP_ANDX in your capture is perfectly valid. For some reason
I would not be surprised if mac were fickle about something like an
empty domain. That would be a special case that the server would have
to consider (by mapping it to the local machine domain).

Mike

[Trejkaz]

Post by Michael B Allen
Hi Trejkaz,
Try the machine name for the domain.
Also try using a fully qualified DNS hostname instead of the IP.

I tried more combinations:
* short name for domain, IP for host
* short name for domain, short name for host
* short name for domain, full name for host
* full name for domain, short name for host
* full name for domain, full name for host

Seems like I get the same result using the fully qualified name. I
tried with the URL using the fully-qualified name as well as the IP
now I'm using it for both the URL and the authentication object. The
packets are a bit different - the domain is in the request now and the
response has some different IDs.

I see some activity in the server logs:

21/11/2014 2:25:52.837 pm digest-service[78918]: digest-request: uid=0
21/11/2014 2:25:52.837 pm digest-service[78918]: digest-request: init request
21/11/2014 2:25:52.841 pm digest-service[78918]: digest-request: init
return domain: BUCKET server: BUCKET indomain was: <NULL>

I get the same log entry irrespective of whether I put in an empty
string, the short name or the long name of the host as the domain, so
the system must be normalising it back to the short name.

I don't know if the "indomain" thing here being null is part of my
issue but at the moment it's the only lead I have to work with.

Daniel