2 Answers
- Newest
- Most votes
- Most comments
0
This is not an answer to the error posted above but this can be closed. The problem went away after a destroy and new deploy of the environment.
answered a year ago
0
"An attempt to login using SQL authentication failed. Server is configured for Windows authentication only." can be returned in the following situations.
- A SQL Server instance is not configured for mixed mode authentication - it seems not to be the case, as be default all RDS SQL Servers have mixed mode authentication;
- When SQL login and password are empty. Please check "Misleading errors: “Server is configured for Windows ..." - https://sqlstudies.com/2018/06/18/misleading-errors-server-is-configured-for-windows-authentication-only-but-its-not/
- When the server is configured for mixed mode authentication, and an ODBC connection uses the TCP protocol, and the connection doesn't explicitly specify that the connection should use a trusted connection;
- When SQL server is configured for mixed mode authentication, and an ODBC connection uses named pipes, and the credentials the client used to open the named pipe are used to automatically impersonate the user, and the connection string doesn't explicitly specify the use of a trusted authentication.
To resolve this issues 2 and 3, include TRUSTED_CONNECTION = TRUE in the connection string. For further details, please take a look at links below for further details:
"MSSQLSERVER_18456 - More rare possible cause" - https://learn.microsoft.com/en-us/sql/relational-databases/errors-events/mssqlserver-18456-database-engine-error?view=sql-server-ver16
Kind Regards
Simon M.
answered a year ago
Relevant content
- asked 2 years ago
- asked 10 months ago
- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated a year ago
- AWS OFFICIALUpdated a year ago
- How do I troubleshoot using my on-premises Active Directory login to my RDS for SQL Server instance?AWS OFFICIALUpdated 2 years ago
@rePost-User-4555259 - Doh! This is the first time I have ever come across #2 (Thank You!) very interesting and #4 can be discarded. I know that the .net core code base recently switched to a more secure attachment mode when connecting to odbc databases, faulting to more secure, while being a breaking change. This info has been helpful.
To resolve this issues 2 and 3, include TRUSTED_CONNECTION = TRUE <-- Kind of hard to do using dms. However, I am betting this is a secretsmanager issue returning a blank username, it's the only logical explanation as far as I can tell. It worked after a clean slate and prior to a secret rotation :/