-
Type: Bug
-
Resolution: Done
-
Priority: Major - P3
-
Affects Version/s: 2.12.0, 3.0.0
-
Component/s: Authentication
-
None
-
Environment:Java on any platform connected to a MongoDB server running on Windows
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.
- is related to
-
SERVER-27252 Relax constraint on client's maximum size output message in SSPI implementation of SASL GSSAPI mechanism
- Closed
- related to
-
JAVA-2320 Add test automation for GSSAPI authentication on Windows
- Closed