[JAVA-2320] Add test automation for GSSAPI authentication on Windows Created: 23/Sep/16  Updated: 31/Jan/18  Resolved: 31/Jan/18

Status: Closed
Project: Java Driver
Component/s: Test Coverage
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Jeffrey Yemin Assignee: Unassigned
Resolution: Duplicate Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
Related
is related to JAVA-2385 GSSAPI authentication fails against W... Closed

 Description   

The Java driver automated test suite on Jenkins executes GSSAPI authentication on Linux.

Although there is no Windows-specific code in the driver for GSSAPI authentication, we should still validate in Jenkins that it works properly, as there is a significant volume of platform-specific code for GSSAPI authentication within the JDK itself, and clients have historically had trouble getting GSSAPI authentication working on Windows with the Java driver.



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

See SERVER-27252, which is likely the root cause of the error in the server logs. It also appears that there is a workaround which can be implemented in the driver itself (see JAVA-2385).

See javax.security.sasl.Sasl#MAX_BUFFER:

    /**
     * The name of a property that specifies the maximum size of the receive
     * buffer in bytes of {@code SaslClient}/{@code SaslServer}.
     * The property contains the string representation of an integer.
     * <br>If this property is absent, the default size
     * is defined by the mechanism.
     * <br>The value of this constant is {@code "javax.security.sasl.maxbuffer"}.
     */
    public static final String MAX_BUFFER = "javax.security.sasl.maxbuffer";

The default value for this is 65536. There is a bug in the JDK in which in incorrectly sends a non-zero value to the server even when there is no security layer defined. This is a violation of the RFC mentioned in the SERVER ticket, but one apparently that most implementations are relaxed about, but not the mongod server on Windows.

Note also that this actually has nothing to do with GSSAPI using a Java client on Windows. It's the same code for Linux, Mac, etc. So no Java client can currently authenticate via GSSAPI to a mongod running on Windows. And any Java client, Windows or otherwise, can authenticate to a mongod running on Linux.

Comment by rajesh [ 05/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 David Golub [ 23/Sep/16 ]

Server log output from attempting to connect to a MongoDB process using Kerberos on Windows with the Java driver:

 
2016-09-14T12:26:16.685-0700 D ACCESS   [conn61] SSPI encrypted size: 59 decrypted size: 31 encrypted msg pointer: 000000D67D9FCB00 decrypted msg pointer: 000000D67D9FCB10
2016-09-14T12:26:16.685-0700 E ACCESS   [conn61] SSPI: wrong security layer from client
2016-09-14T12:26:16.685-0700 D ACCESS   [conn61] Was not able to acquire authorization username from Cyrus SASL. Falling back to authentication name.
2016-09-14T12:26:16.685-0700 I ACCESS   [conn61] GSSAPI authentication failed for Administrator@MONGODB.LOCAL on $external from client 10.0.2.15 ; ProtocolError: SASL(-1): generic failure: SSPI: wrong security layer from client
2016-09-14T12:26:16.685-0700 D ACCESS   [conn61] Was not able to acquire authorization username from Cyrus SASL. Falling back to authentication name.
2016-09-14T12:26:16.685-0700 I COMMAND  [conn61] command admin.system.users command: saslContinue { saslContinue: 1, conversationId: 1, payload: BinData(0, 050400FF000C000000000000157D13C60101000041646D696E6973747261746F72404D4F4E474F44422E4C4F43414C9448D4E5552D395F6A3B5307) } keyUpdates:0 writeConflicts:0 numYields:0 reslen:82 locks:{ Global: { acquireCount: { r: 2 } }, Database: { acquireCount: { r: 1 } }, Collection: { acquireCount: { r: 1 } } } protocol:op_query 0ms

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