Summary

Historically we haven't allowed x509 auth when the client certificate O/OU/DC matched the server certificate O/OU/DC.

The intention of SERVER-45938 was to provide a parameter to disable the O/OU/DC check and disable it automatically when the clusterAuthMode is keyFile (because in this case we don't care about the cert clash as there would be no x509 cluster auth).

The enforceUserClusterSeparation parameter was introduced to override this behaviour. Code was added to the createUser and authentication commands accordingly.

The logic for the authentication command has been implemented - I believe - incorrectly. Currently, the O/OU/DC client/server validation only takes place if the clusterAuthMode does not allow X509 (i.e keyFile mode). For X509 clusterAuthMode, no validation is performed, only a log warning.

We actually want the validation to be performed on the X509 code path only - with no validation when using keyFile.

The validation logic for the createUser command and configuration check on process startup seem correct.

Faulty logic:

https://github.com/mongodb/mongo/blob/master/src/mongo/db/commands/authentication_commands.cpp#L232-L256

Motivation

How does this affect the end user?

Possible security implications due to faulty validation logic.

Currently, when X509 clusterAuth is enabled, any client certificate that matches the server O/OU/DC will bypass validation and be granted __system privileges.

How likely is it that this problem or use case will occur?

Fairly rare.