-
Type: Improvement
-
Resolution: Done
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: Security
-
None
-
Environment:Windows
The RFC 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 though it indicates no support for any security layer.
The SSPI implementation in the server correctly checks this: https://github.com/mongodb-labs/winkerberos/blob/master/src/kerberos_sspi.c#L461-L464
(Note that this link reflects code that is similar to what the server does, but is not the actual code. The actual code is in the closed-source enterprise module.)
This request is to relax that check and instead only check the first byte, ignoring the last three entirely. That's what Cyrus SASL does.
Note that this issue prevents any Java client from authenticating via GSSAPI to a MongoDB server running on Windows.
- related to
-
JAVA-2385 GSSAPI authentication fails against Windows MongoDB server
- Closed