[JAVA-2385] GSSAPI authentication fails against Windows MongoDB server Created: 16/Nov/16  Updated: 27/Dec/16  Resolved: 02/Dec/16

Status: Closed
Project: Java Driver
Component/s: Authentication
Affects Version/s: 2.12.0, 3.0.0
Fix Version/s: 3.4.1

Type: Bug Priority: Major - P3
Reporter: rajesh Assignee: Jeffrey Yemin
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Java on any platform connected to a MongoDB server running on Windows


Issue Links:
Depends
Related
related to JAVA-2320 Add test automation for GSSAPI authen... Closed
is related to SERVER-27252 Relax constraint on client's maximum ... Closed

 Description   

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.



 Comments   
Comment by Jeffrey Yemin [ 27/Dec/16 ]

JDK code review link: http://cr.openjdk.java.net/~weijun/8170732/webrev.00/

Comment by Jeffrey Yemin [ 19/Dec/16 ]

Hi Rajesh,

No matter what you're going to have to change your dependency, as 3.2.2 by definition cannot contain this fix, since it's already been released. Given that, I'm not sure what exactly you're asking. Since you have to change the dependency regardless, you can either

  • Upgrade to 3.4.1 when you're able
  • Build your own release based on 3.2.2 with this one change applied, and update your dependency to your own release.
Comment by rajesh [ 12/Dec/16 ]

Hi Jeff,

As of now we cannot upgrade to 3.4.1, upgrade is planned for future release. We have made the changes in 3.2.2 source and built the jar and tested it, its working fine for us. But the problem is with hosting the 3.2.2 source with the fix. Can we host the source jar in maven central? If yes what namespace can we use, I assume we cannot use the existing org.mongodb namespace. Hosting the source jar is needed as we build a Eclipse Orbit bundle using the groupid and artifact id from maven central. Please let me know how to proceed with this.

Thanks,
Rajesh

Comment by Jeffrey Yemin [ 09/Dec/16 ]

We have no plans to backport this to the 3.2 or 3.3 release branch. As BIRT would have to be upgraded to 3.2.3 anyway, I suggest you take the opportunity to upgrade instead to 3.4.1 when it is released.

Comment by rajesh [ 09/Dec/16 ]

Hi Jeff,

Will this fix be back ported to mongodb 3.2.2 driver? we are using monongdb 3.2.2 in our BIRT mongo db plugin. we create a eclipse orbit bundle for mongodb jar and include it in BIRT designer.

Comment by Jeffrey Yemin [ 09/Dec/16 ]

Reference to JDK bug reported as the root cause of this issue: JDK-8170732.

Comment by rajesh [ 05/Dec/16 ]

Hi Jeff, Thanks for the quick fix. It works in my environment.

Comment by Jeffrey Yemin [ 02/Dec/16 ]

rgoteti

A snapshot build is available here or here if you'd like to test out this fix and let us know if it works in your environment.

Comment by Githook User [ 02/Dec/16 ]

Author:

{u'username': u'jyemin', u'name': u'Jeff Yemin', u'email': u'jeff.yemin@10gen.com'}

Message: JAVA-2385: Set javax.security.sasl.Sasl#MAX_BUFFER property to "0" in GSSAPIAuthenticator in order to work around a strict check in the Windows implementation of GSSAPI in the MongoDB server.
Branch: 3.4.x
https://github.com/mongodb/mongo-java-driver/commit/26d4bcedc61b5f2e6919ef0230eff35e7f50cddb

Comment by Githook User [ 02/Dec/16 ]

Author:

{u'username': u'jyemin', u'name': u'Jeff Yemin', u'email': u'jeff.yemin@10gen.com'}

Message: JAVA-2385: Set javax.security.sasl.Sasl#MAX_BUFFER property to "0" in GSSAPIAuthenticator in order to work around a strict check in the Windows implementation of GSSAPI in the MongoDB server.
Branch: master
https://github.com/mongodb/mongo-java-driver/commit/ca2f1979dfeb6c1f1eb02fb771791bbe4b8a6bd4

Comment by Jeffrey Yemin [ 16/Nov/16 ]

We will address this issue in scope of JAVA-2320.

Comment by rajesh [ 16/Nov/16 ]

I have found this issue in MongoDB jira and updated it my comments,
https://jira.mongodb.org/browse/JAVA-2320

Comment by rajesh [ 16/Nov/16 ]

Hi Jeff,
we are facing this issue when connecting to MongoDB with javadriver using GSSAPI on windows environment. Connections through mongoshell and python driver seemes to be working fine. This problem is specific to windows environment as we were able to succesfully authenticate on centos. we are currently stuck due to this issue. is there any workaround for this issue ?
mongodb log:
-----------------
2016-11-05T15:44:19.426+0530 D ACCESS [conn6] SSPI authenticated name: mongoClient@IHUBTEST.COM
2016-11-05T15:44:19.426+0530 D ACCESS [conn6] auxprop matched no properties
2016-11-05T15:44:19.426+0530 D ACCESS [conn6] SSPI encrypted size: 74 decrypted size: 28 encrypted msg pointer: 000000DCE8F52990 decrypted msg pointer: 000000DCE8F529BD
2016-11-05T15:44:19.426+0530 E ACCESS [conn6] SSPI: wrong security layer from client
2016-11-05T15:44:19.426+0530 D ACCESS [conn6] Was not able to acquire authorization username from Cyrus SASL. Falling back to authentication name.
2016-11-05T15:44:19.426+0530 I ACCESS [conn6] GSSAPI authentication failed for mongoClient@IHUBTEST.COM on $external from client 10.96.45.144 ; ProtocolError: SASL(-1): generic failure: SSPI: wrong security layer from client
2016-11-05T15:44:19.426+0530 D ACCESS [conn6] Was not able to acquire authorization username from Cyrus SASL. Falling back to authentication name.
Thanks,
Rajesh

Comment by Jeffrey Yemin [ 16/Nov/16 ]

Hi Rajesh,

Can you provide the full exception stack trace as well as any relevant mongod server logs?

Thanks,
Jeff

Generated at Thu Feb 08 08:57:04 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.