When testing Kerberos authentication, I received the following error message from MongoDB shell:

speed% /usr/local/m/versions/4.2/mongo --host <kerberos-test-host> --authenticationMechanism=GSSAPI '--authenticationDatabase=$external' --username <kerberos-test-user> 
MongoDB shell version v4.2.1-23-g1860793
connecting to: mongodb://<kerberos-test-host> :27017/?authMechanism=GSSAPI&authSource=%24external&compressors=disabled&gssapiServiceName=mongodb
2020-03-13T23:25:09.300-0400 E  QUERY    [js] Error: SASL(-4): no mechanism available: No worthy mechs found :
connect@src/mongo/shell/mongo.js:341:17
@(connect):3:6
2020-03-13T23:25:09.302-0400 F  -        [main] exception: connect failed
2020-03-13T23:25:09.302-0400 E  -        [main] exiting with code 1

The error provided by the shell is this:

2020-03-13T23:25:09.300-0400 E  QUERY    [js] Error: SASL(-4): no mechanism available: No worthy mechs found :
connect@src/mongo/shell/mongo.js:341:17

Current behavior - this error message:

• Does not indicate the component responsible for the failure (in this case, as far as I can tell it is cyrus-sasl that failed, due to missing one of its optional dependencies).
• Does not indicate what steps the user should perform to identify and fix this issue.
• Is very confusing because it uses "mechanism" in singular and "mechs" in plural, whereas I am expecting to only use one mechanism (gssapi), implying that there are some other mechanisms that I as the user am unaware of, or alternatively that MongoDB delegated authentication to some subsystem which supports more than one component and is misconfigured (i.e. cyrus-sasl).

This error ultimately turned out to be a dependency problem where an optional dependency of cyrus-sasl was not installed. The most effective strategy for a user to diagnose this error, as far as I can tell, is to search the web for the error message and scour the top 10 or so results until they figure out that the real problem is a lack of optional dependency of cyrus-sasl.

In the help ticket I was also offered the suggestion that this error may be produced by the community version of the shell which does not support gssapi. This is not the case for me (I am using an enterprise shell) but, if this could be the case, the shell should clearly state that it does not support gssapi instead of providing the above error message.

Desired behavior:

• If the shell is requested to authenticate with a mechanism it does not support (such as gssapi for a non-enterprise shell), as a user of the shell I expect the shell to clearly state this so that I know to use the correct shell edition.
• If the shell or the server are unable to authenticate when they pass off the authentication work to a third-party library, as a user of the shell or the server I expect the shell and the server to clearly state in the error message that the error message came from a third-party library/service/software, and indicate the library/service/software in question so that I can eliminate MongoDB as a possible culprit and focus on troubleshooting the third-party software.