Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-70242

Intracluster X509 authentication can trigger "Different user name was supplied to saslSupportedMechs"

    • Type: Icon: Task Task
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • 6.3.0-rc0, 6.0.7, 5.0.19
    • Affects Version/s: None
    • Component/s: None
    • Labels:
    • Fully Compatible
    • v6.0, v5.0
    • Security 2022-10-17, Security 2022-12-12, Security 2022-12-26

      Looking at the logs from the most recent run of jstests/ssl_x509/sharding_with_x509.js we can see the following sequence of events:

      [js_test:sharding_with_x509] c20043| 2022-10-05T13:12:51.724+00:00 D2 NETWORK  4908000 [conn2] "Client connected with SNI extension","attr":{"sniName":"ip-10-122-35-113.ec2.internal"}
      [js_test:sharding_with_x509] c20043| 2022-10-05T13:12:51.724+00:00 I  NETWORK  6723804 [conn2] "Ingress TLS handshake complete","attr":{"durationMillis":6}
      [js_test:sharding_with_x509] c20043| 2022-10-05T13:12:51.724+00:00 I  NETWORK  6723801 [conn2] "Accepted TLS connection from peer","attr":{"peerSubject":"CN=clustertest,OU=Kernel,O=MongoDB,L=New York City,ST=New York,C=US","cipher":"TLS_AES_256_GCM_SHA384"}
      [js_test:sharding_with_x509] c20043| 2022-10-05T13:12:51.724+00:00 I  NETWORK  51800   [conn2] "client metadata","attr":{"remote":"","client":"conn2","doc":{"application":{"name":"/data/mci/1b7d5954a7badbd78fb06fecd1355345/src/dist-test/bin/mongod","pid":"14912"},"driver":{"name":"NetworkInterfaceTL-ReplNetwork","version":"6.2.0-alpha-824-gec66667"},"os":{"type":"Linux","name":"Red Hat Enterprise Linux release 8.0 (Ootpa)","architecture":"x86_64","version":"Kernel 4.18.0-80.1.2.el8_0.x86_64"}}}
      [js_test:sharding_with_x509] c20043| 2022-10-05T13:12:51.724+00:00 I  ACCESS   5286202 [conn2] "Different user name was supplied to saslSupportedMechs","attr":{"error":{"code":17,"codeName":"ProtocolError","errmsg":"Attempt to switch user during SASL authentication from __system@local to CN=clustertest,OU=Kernel,O=MongoDB,L=New York City,ST=New York,C=US@$external"}}
      [js_test:sharding_with_x509] c20043| 2022-10-05T13:12:51.724+00:00 I  ACCESS   20429   [conn2] "Successfully authenticated","attr":{"client":"","mechanism":"MONGODB-X509","user":"CN=clustertest,OU=Kernel,O=MongoDB,L=New York City,ST=New York,C=US","db":"$external"}

      Nothing strictly wrong happened here, but the warning is chatty and misleading. X509 authentication happens on the $external database. But the __system user, which gives the client its privileges lives on the local database. The AuthenticationSession, which knows that internal authentication can happen on admin during testing, but doesn't seem to have an exemption for $external, seems to be getting confused. Strangely, MONGODB-X509 authentication only requires one step, and can entirely start and conclude in speculative hello authentication.

      The problem appears to be that a hello command can include a speculativeAuthenticate and a saslSupportedMechs statement. speculativeAuthenticate works just like authenticate and must use the certificate's subject name. saslSupportedMechs has to enumerate a real user identity, so during intracluster auth has to be set to local.__system.

      The fault here can either been seen to be arising from the AuthenticationSession not knowing that a saslSupportedMechs call can lead to a cluster auth attempt on the $external database. Alternatively, it can be seen as a result of the egress connection subsystem asking for supported SASL mechanisms when it knows that it's going to make a MONGODB-X509 authentication attempt.

            militsa.sotirova@mongodb.com Militsa Sotirova
            spencer.jackson@mongodb.com Spencer Jackson
            0 Vote for this issue
            13 Start watching this issue