Closed fbiesse closed 2 years ago
Unfortunately these types of bugs are hard to figure out just from the debug logs alone. The last SPNEGO step output
entry contains the NTLM authentication message which is what's being rejected by Nutanix
and it's decoded value is
# python -m spnego --format yaml --token base64value
MessageType: SPNEGO NegTokenResp
Data:
negState: accept-incomplete (1)
supportedMech:
responseToken:
MessageType: AUTHENTICATE_MESSAGE (3)
Data:
LmChallengeResponseFields:
Len: 24
MaxLen: 24
BufferOffset: 88
NtChallengeResponseFields:
Len: 214
MaxLen: 214
BufferOffset: 112
DomainNameFields:
Len: 28
MaxLen: 28
BufferOffset: 326
UserNameFields:
Len: 24
MaxLen: 24
BufferOffset: 354
WorkstationFields:
Len: 12
MaxLen: 12
BufferOffset: 378
EncryptedRandomSessionKeyFields:
Len: 16
MaxLen: 16
BufferOffset: 390
NegotiateFlags:
raw: 3800662549
flags:
- NTLMSSP_NEGOTIATE_56 (2147483648)
- NTLMSSP_NEGOTIATE_KEY_EXCH (1073741824)
- NTLMSSP_NEGOTIATE_128 (536870912)
- NTLMSSP_NEGOTIATE_VERSION (33554432)
- NTLMSSP_NEGOTIATE_TARGET_INFO (8388608)
- NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY (524288)
- NTLMSSP_TARGET_TYPE_DOMAIN (65536)
- NTLMSSP_NEGOTIATE_ALWAYS_SIGN (32768)
- NTLMSSP_NEGOTIATE_NTLM (512)
- NTLMSSP_NEGOTIATE_SIGN (16)
- NTLMSSP_REQUEST_TARGET (4)
- NTLMSSP_NEGOTIATE_UNICODE (1)
Version:
Major: 0
Minor: 1
Build: 6
Reserved: '000000'
NTLMRevision: 15
MIC: 4737AFF1108270C222FFD7C64B691F52
Payload:
LmChallengeResponse:
ResponseType: LMv2
LMProofStr: '00000000000000000000000000000000'
ChallengeFromClient: '0000000000000000'
NtChallengeResponse:
ResponseType: NTLMv2
NTProofStr: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
ClientChallenge:
RespType: 1
HiRespType: 1
Reserved1: 0
Reserved2: 0
TimeStamp: '2021-10-27T08:50:00.104934Z'
ChallengeFromClient: CE62FCBB2A95607C
Reserved3: 0
AvPairs:
- AvId: MSV_AV_NB_DOMAIN_NAME (2)
Value: DOMAIN
- AvId: MSV_AV_NB_COMPUTER_NAME (1)
Value: TARGET
- AvId: MSV_AV_DNS_DOMAIN_NAME (4)
Value: "\0"
- AvId: MSV_AV_DNS_COMPUTER_NAME (3)
Value: target-dns
- AvId: MSV_AV_TIMESTAMP (7)
Value: '2021-10-27T08:50:00.104934Z'
- AvId: MSV_AV_TARGET_NAME (9)
Value: CIFS/target.domain.local
- AvId: MSV_AV_FLAGS (6)
Value:
raw: 2
flags:
- MIC_PROVIDED (2)
- AvId: MSV_AV_EOL (0)
Value:
Reserved4: 0
DomainName: domain
UserName: user.local
Workstation: WORKSTATION
EncryptedRandomSessionKey: BD30D448B1CAF7DE01F7616BB912D577
SessionKey: Failed to derive
RawData: Raw hex of NTLM auth token
mechListMIC: 01000000156465DE07B8A7F900000000
RawData: Raw hex of token
Nothing is really jumping out at me as overly wrong but obviously there's a problem and the server doesn't like some component.
In these cases what I do is:
Session Setup
messages sent after negotiationsmbclient.ClientConfig(auth_protocol="ntlm")
to force using NTLM only and not NTLM through SPNEGO
My bad, it works if I use the full username eg : domain\username
Glad you were able to figure it out. I've found that Linux hosts are a bit more touchy when it comes to the username. Typically it's best to always specify the domain or use the UPN format if it's a domain user.
We are using Nutanix Files and it supports SMB protocol V2 and V3.
https://portal.nutanix.com/page/documents/kbs/details?targetId=kA00e000000LMXuCAO
I have the last version of smbprotocol
I tried the following program :
But I have the following error :
When I tyy to mount the same shared folder with cifs-utils in Debian :
Everything works fine.
Anyway, With the same user on a windows server share everything also works fine.
I don't know if there's enouth information to debug in the logging information....
Thank for this project that works great, If you could check ang give me a workaround, I'll be very happy.