Thanks for the comprehensive interop issue report.&nbsp; I have one question:<br />
<br />
&gt;&nbsp;In function, src/lib/gssapi/spnego/spnego_mech.c: get_negTokenResp we return error code that it is a defective token.<br />
<br />
This function should only return a defective token error if the packet has a bad length, which does not appear to be the case.&nbsp; Is it possible that the error came from handle_mic() at the first else-if clause?<br />
<br />
Some background:<br />
<br />
* RFC 4178 (SPNEGO) section 5 only requires a mechlistMIC exchange if the negotiated mech is not the most-preferred mech of one of the two parties.&nbsp; Otherwise the MIC exchange is optional (unless the negotiated mech has no MIC support, in which case it&#39;s impossible).<br />
<br />
* RFC 4178 section 5 (c) (I) says, for the acceptor processing the final initiator token: &quot;If a mechlistMIC token was included and is correctly verified, GSS_Accept_sec_context() indicates GSS_S_COMPLETE.&nbsp; The output negotiation message contains a mechlistMIC token&nbsp;and an accept_complete state.&quot;<br />
<br />
In this exchange both parties prefer NTLMSSP, so one would expect the MIC exchange to be optional.&nbsp;&nbsp;&nbsp;However, Microsoft imposes an additional constraint for NTLMSSP.&nbsp; This is both observed and documented; [MS-SPNG] Appendix A says:<br />
<br />
&nbsp; &nbsp; If NTLM authentication is most preferred by the client and the server, and the<br />
&nbsp; &nbsp; client includes a MIC in AUTHENTICATE_MESSAGE ([MS-NLMP] section<br />
&nbsp; &nbsp; 2.2.1.3), then the mechListMIC field becomes mandatory in order for the<br />
&nbsp; &nbsp; authentication to succeed. Windows clients in this case send an NTLM token<br />
&nbsp; &nbsp; instead of an SPNEGO token.<br />
<br />
Accordingly, we have a helper&nbsp;mech_requires_mechlistMIC(), so that NTLMSSP can report that it&#39;s behaving in a way that causes a SPNEGO MIC to be required.&nbsp; In our code, the MIC requirement is treated as symmetrical; if we send one, we believe we must receive one, and (following RFC 4178 5.c.I) if we receive one, we send one.<br />
<br />
From the packet traces it would appear that the Azure server does not believe a MIC is required (i.e. it is not behaving according to [MS-SPNG] Appendix A) and isn&#39;t sending a MIC in response to the initiator&#39;s MIC (i.e. it it violates RFC 4178 section 5(c)(I)).&nbsp; This apparent misbehavior could be accomodated in two ways:<br />
<br />
1. Following the hint in [MS-SPNG] Appendix A, the application could send an NTLM token instead of a SPNEGO token.&nbsp; Generally if a client prefers NTLM, it can only do NTLM, so negotiation isn&#39;t required.&nbsp; However, it may be difficult for an application using MIT krb5 to implement this due to the abstraction boundaries; the application doesn&#39;t know that the client is only capable of NTLM and the SPNEGO layer can&#39;t generate a non-SPNEGO token.<br />
<br />
2. In our SPNEGO layer, a true result from mech_requires_mechlistMIC() could cause a MIC token to be generated, but not required from the other party.<br />
&nbsp;