RFC 4752 section 4.3.1 states that:

The client then constructs data, with the first octet containing the bit-mask specifying the selected security layer, the second through fourth octets containing in network byte order the maximum size output_message the client is able to receive (which MUST be 0 if the client does not support any security layer)

There is a bug in the JDK where by default it does not send 0 for the maximum size output_message, even when it indicates no support for any security layer. Rather, it sends the default value for the javax.security.sasl.Sasl#MAX_BUFFER property, which is not specified but is generally set to 65,536 in the Oracle JDK.

The SSPI implementation in the server checks this and fails with the following error:

2016-11-05T15:44:19.426+0530 E ACCESS [conn6] SSPI: wrong security layer from client

The corresponding code in the Linux version of MongoDB does not make such a stringent check, and therefore GSSAPI authentication from a Java client succeeds when connecting to a Linux-based MongoDB server.

The driver can work around the server check by setting the javax.security.sasl.Sasl#MAX_BUFFER property to "0".

Note that this issue prevents any Java client from authenticating via GSSAPI to a MongoDB server running on Windows.