We are using MIT krb5 with libsmb2: https://github.com/sahlberg/libsmb2/ and GSS implementation from here: https://github.com/gssapi/gss-ntlmssp. I have attached the packet taces for the following:
-- Packet traces for authentication with azure [tcp_azure.pcap].
-- Packet traces of authentication with windows server (which also requires MIC, encryption) [tcp_new_win_enc_test.pcap].
-- Packet traces for authentication with Samba [tcp_azure_old.pcap]

In authentication with Azure files Samba server, the session setup response from the server (4th packet of 4) has a security blob of length only 9. In function, src/lib/gssapi/spnego/spnego_mech.c: get_negTokenResp we return error code that it is a defective token. As a result of this, we clean up the gss context and then we are not able to retrieve the session key (which would be required for encryption).

I tried the same with the Samba client and it works.

What could be the problem?
-- Is the token defective and clean up of the context is the right approach? In this case, it needs to be handled in another layer. Not sure if that is possible.
-- If we have received the MIC in the 3rd packet of session setup response, do not make it mandatory to send MIC in the 4th packet. Can this be a solution?
-- Do not clean up when we get the defective token from the 4th packet. 


P.S.: I do not have much idea on how the protocol works, and the above understanding is gained by putting working on this issue. Please pardon any mistakes in the bug analysis.