Open isabsent opened 2 years ago
A user of my free Android app has reported the same problem when accessing a share on MacOS. For him it fails when connecting to MacOS 10.15.7.
Until recently, I was using a much older version of smbj, a snapshot from 28.8.2017. With this version, connecting to MacOS does work! It used config = SmbConfig.builder().withMultiProtocolNegotiate(true).build(); client = new SMBClient(config);
Then I changed to a current snapshot recently for the SMB3 support, and with this version the connection fails with STATUS_LOGON_FAILURE (0xc000006d). The user tried SMB2 only (builder.withDialects(SMB2Dialect.SMB_2_1, SMB2Dialect.SMB_2_0_2)) and also SMB3 (builder.withDialects(SMB2Dialect.SMB_3_1_1, SMB2Dialect.SMB_3_0_2, SMB2Dialect.SMB_3_0)) and a combination of both, it always failed with the same error.
Maybe a code comparison could give you a clue why it works with the older smbj version but not the latest.
Between 2017 and now, quite a number of things have changed. Is there any way of obtaining a pcap file of a working connect and a non-working to analyze the difference?
Between 2017 and now, quite a number of things have changed. Is there any way of obtaining a pcap file of a working connect and a non-working to analyze the difference?
I will try, but I have no idea what is pcap and how to get it.
pcap is a packet capture. There are multiple ways to grab one, depending on your OS.
pcap is a packet capture. There are multiple ways to grab one, depending on your OS.
Ok, I will try to get it.
isabsent: Why did you close this issue? Did you find a solution? The user of my app who has this problem would also appreciate a solution.
isabsent: Why did you close this issue? Did you find a solution? The user of my app who has this problem would also appreciate a solution.
I have closed it accidentally. I have no the solution yet.
I have now made a code comparison between the smbj version from 2017 which works, and the current version which doesn't, and found the following differences in the authentication functions which may have an influence. Unfortunately I don't have access to a Mac so it would be nice if you (isabsent) or anyone else with this problem could test whether one of these changes causes the problem.
mssmb2\messages\SMB2SessionSetup.java new version: buffer.putUInt32(clientCapabilities & 0xFF); // Capabilities (4 bytes) old version: buffer.putUInt32(clientCapabilities & 0x01); // Capabilities (4 bytes) (only last byte can be set)
ntlm\messages\NtlmNegotiate.java new: buffer.putUInt32(0x20); // DomainNameBufferOffset (4 bytes) // WorkstationFields (8 bytes) buffer.putUInt16(0x0); // WorkstationLen (2 bytes) buffer.putUInt16(0x0); // WorkstationMaxLen (2 bytes) buffer.putUInt32(0x20); // WorkstationBufferOffset (4 bytes) old: buffer.putUInt32(0x0); // DomainNameBufferOffset (4 bytes) // WorkstationFields (8 bytes) buffer.putUInt16(0x0); // WorkstationLen (2 bytes) buffer.putUInt16(0x0); // WorkstationMaxLen (2 bytes) buffer.putUInt32(0x0); // WorkstationBufferOffset (4 bytes)
smbj\auth\NtlmAuthenticator.java new: Object msAvTimestamp = serverNtlmChallenge.getTargetInfo().getAvPairObject(AvId.MsvAvTimestamp); if (msAvTimestamp != null) { old: Object msvAvFlags = challenge.getAvPairObject(AvId.MsvAvFlags); if (msvAvFlags instanceof Long && ((long) msvAvFlags & 0x00000002) > 0) { you can't use this old code directly because the object names changed. You will need to use something like this: Object msvAvFlags = serverNtlmChallenge.getTargetInfo().getAvPairObject(AvId.MsvAvFlags); if (msvAvFlags instanceof Long && ((long) msvAvFlags & 0x00000002) > 0) {
a lot was rearranged in smbj\connection\Connection.java, so if the problem is there, it will be difficult to analyze.
Also there are a lot of protocol negotiations if SMB2Dialect.SMB_3_1_1 is set, so try connecting with SMB2 only: builder.withDialects(SMB2Dialect.SMB_2_1, SMB2Dialect.SMB_2_0_2)
I will try to check it in this weekend.
isabsent: Have you tried my 3 suggested changes in the meantime? They are so small, you can just edit the 3 files by hand and recompile. Unfortunately I don't have access to a Mac, so I can't test it myself. In the meantime, more MacOS users have reported the login failure.
@chrisgch I applied first 3 changes you proposed (points 1, 2 and 3) and it started working. The changes, however caused test NegTokenInitSpec."should correctly encode ntlm choice negInitToken"
to fail. Afterwards, I tried applying changes one by one with results (in all cases the negotiated protocol dialect is SMB_3_0_2):
TL;DR version would be, that it seems that changes in NtlmAuthenticator
seem to make it working again on MacOS 12.3.1.
After applying only change "3" (in NtlmAuthenticator
), the failing test is now working allowing for build.
Thanks a lot for your tests! So apparently there is no msAvTimestamp field in the authentication with the Mac, but the flags field is there. @hierynomus Any idea of what this could be? Was there a specific reason for switching to the timestamp check? The comment above the changed check still reads: // MIC (16 bytes) provided if in AvPairType is key MsvAvFlags with value & 0x00000002 is true
@isabsent: Are you still using MacOS 12.3.1? A user with MacOS 12.4 has reported that the bugfix doesn't work for him.
@chrisgch I tried running it on my machine (MacOS 12.4) and the fix seems to be working fine (I haven't tried the original library, though).
3. smbj\auth\NtlmAuthenticator.java new: Object msAvTimestamp = serverNtlmChallenge.getTargetInfo().getAvPairObject(AvId.MsvAvTimestamp); if (msAvTimestamp != null) { old: Object msvAvFlags = challenge.getAvPairObject(AvId.MsvAvFlags); if (msvAvFlags instanceof Long && ((long) msvAvFlags & 0x00000002) > 0) { you can't use this old code directly because the object names changed. You will need to use something like this: Object msvAvFlags = serverNtlmChallenge.getTargetInfo().getAvPairObject(AvId.MsvAvFlags); if (msvAvFlags instanceof Long && ((long) msvAvFlags & 0x00000002) > 0) {
It work for me. macOS Ventura 13.1
Does the original code work, or the updated for 13.1?
Does the original code work, or the updated for 13.1?
The original code doesn't work.
Object msAvTimestamp = serverNtlmChallenge.getTargetInfo().getAvPairObject(AvId.MsvAvTimestamp); (msAvTimestamp != null) is true
Object msvAvFlags = serverNtlmChallenge.getTargetInfo().getAvPairObject(AvId.MsvAvFlags); (msvAvFlags instanceof Long && ((long) msvAvFlags & 0x00000002) > 0) is false
When the code takes the false branch, it works fine.
Looks like this is a duplicate of #730 with a proposed fix in #731 and changeset c81367c4b35aedd468a75483f1e130ed2d8323c9.
MacOS Monterey 12.1 for
com.hierynomus:smbj
versions0.11.1
and0.11.3
Error in the method:
on the string
Session session = setupSession(ctx)
As I have found the same error was faced on Big Sur year ago https://github.com/hierynomus/smbj/issues/454#issuecomment-817713480, but the provided solution doesn't work now.
The same code works fine for shared folders on Ubuntu 20.04.
P.S.:
com.hierynomus:smbj:0.10.0
doesn't have this problem on MacOS Monterey 12.1! I have found the same situation in this message https://github.com/hierynomus/smbj/issues/478#issuecomment-962856583.