Password with symbols/punctuation causes authentication failure

Hello,

I've noticed that the appearance of symbols/punctuation in the DocumentDB master password field often results in an authentication failure to the database. I have a CloudFormation template which generates the cluster and its master credentials via Secrets Manager. When excluding some illegal characters in the 99-character password using `ExcludeCharacters: '"@/#%:='` under `GenerateSecretString`, I get the bellow errors as seen in ODBC Data Sources when clicking "Test" and in DocumentDB audit logs in CloudWatch respectively.



However when I use `ExcludePunctuation: true` to remove all symbols instead of only those specified above, generating a password of only letters and numbers, I get no error and receive the expected response and log shown below.



For some reason, the "user" field is blank in the error 18 log shown for the failed authentication, even though the user field is populated when establishing the connection through ODBC Data Sources when using this driver. This appears to be caused by some symbol(s) being present in the password, as the error only occurs when symbols are permitted and does not occur when they are all excluded, but it is unclear which symbol(s) is causing this.

Something to note is that I have a Lambda function which is able to successfully connect to and interact with the database using the connection string and pymongo library, even when the majority of symbols are allowed by using `ExcludeCharacters: '"@/#%:='` instead of `ExcludePunctuation: true`. It is only the ODBC driver which appears to have the issue. The Python Lambda function properly encodes the password before transmitting it in the connection string, using the `urllib.parse.quote()` function.

Does the driver appropriately encode the database password field before attempting to establishing a connection? I also noticed the ODBC driver misinterpreting the password when the "=" symbol is used, also leading me to believe the issue may be related to character escapement.

Thank you.

Start by reproducing the failure through ODBC Data Sources with passwords containing the reported punctuation, especially “=”, and compare it with the working Python Lambda connection that uses urllib.parse.quote(). Trace how the ODBC driver receives and transmits the password, then verify that punctuation is handled correctly without breaking the connection string or authentication.

Written by the indexing model from the issue text.