Open l-k-test opened 1 year ago
Not sure I can be of much help in this regard, but would be interested in the answers, too. I can't see anything relating to that behavior in the NTLM specification, nor the implementation notes there. 20 characters was the limit for Windows usernames/samAccountName - at least up until to some point in time, but truncating that at the client side does not make too much sense to me. Possibly this is some kind black magic to work around implementation bugs that existed at some point in time. I did not find the relevant samba source during a quick search, that might offer some additional insight - maybe the samba devs could be of help. If everything else fails, there is a open maling list by Microsoft on which one can ask for clarification on the specifications.
Thanks for the answers.
It is clear that nothing is really clear here :-)
Anyway, at the moment I do not really have time to pursuit this particular issue. It means that I would not have time to come back to this in future either.
Hi.
We have a very strange situation at a client site.
Our code based on jcifs-ng-2.1.10.jar fails with error "Logon failure: unknown user name or bad password.". At the same time smbclient works successfully.
I have created a very basic test application to reproduce the problem and collect some some tcp dumps. I might even attach some of the dump later if I get a clearance on that from our security team. Meanwhile I try to describe what is happening and what I see in the dumps which I cannot understand.
All of my questions are at the moment about smbclient actually and not about jcifs-ng. I understand it. I just hope there is some part of the relevant specifications that can explain what I am seeing.
So, first of all, smbclient command that works:
smbclient '//<domain>/dfsroot/' -U <domain>/<user name of 23 chars> -d 5
It asks for the password and successfully connects to the share. <user name of 23 chars> was provided to us by the client.
The tcpdump shows two Session Setup Request packets:
I could not find anything on the net that can explain this behavior.
What is even more interesting is that I tried to execute smbclient with different user names and compare the dumps:
Explicitly using the truncated name as in the first dump: smbclient '//<domain>/dfsroot/' -U <domain>/<user name of 20 chars> -d 5 It produces a very similar dump, with NTLMSSP_AUTH Session Setup Request with 'Domain name: NULL' and 'User name: <user name>@<domain> This succeeds.
Using various user names like '24 chars', '23 chars but modifying the last char', '22 chars', '21 chars'. All of these attempts show a different picture in the tcp dumps: NTLMSSP_AUTH Session Setup Request with 'Domain name: <domain>' and 'User name: <user name as specified in the command line> All these attempts fail with STATUS_LOGON_FAILURE.
I tried to compare response messages the server returned prior to NTLMSSP_AUTH Session Setup Request to see if smbclient might be somehow directed to use one \username@domain version over domain\username, but could not see anything relevant.
If I run my test application with user name <\<user name of 23 chars>' I see in the dump NTLMSSP_AUTH Session Setup Request with 'Domain name: <domain>' and 'User name: <user name of 23 chars>. It fails with STATUS_LOGON_FAILURE.
If I run my test application with user name '<domain>\<user name truncated to 20 chars>' I see in the dump NTLMSSP_AUTH Session Setup Request with 'Domain name: <domain>' and 'User name: <user name truncated to 20 chars>'. And it works.
I actually built a modified version of jcifs: if it sees that SmbSessionImpl.sessionSetupSMB2() fails with SmbAuthException and the credentials include a domain name, it tries to execute sessionSetupSMB2() again, with modified credentials: username = username@domain and domain = "". Executing it with the original '<domain>\<user name of 23 chars>' I see in the dump NTLMSSP_AUTH Session Setup Request with 'Domain name: <domain>' and 'User name: <user name of 23 chars>, which fails with STATUS_LOGON_FAILURE. And then comes NTLMSSP_AUTH Session Setup Request with 'Domain name: NULL' and 'User name: <user name of 23 chars>@<domain>'. It succeeds.
This baffles me even more.
So the questions are: