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":"10.122.35.113:35362","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":"10.122.35.113:35362","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.
- is duplicated by
-
SERVER-69464 "Attempt to switch user during SASL authentication" error when cluster is configured for x509 membership auth
-
- Closed
-
- related to
-
-
- Closed
-