How to debug 'Login failed for user' on an Azure SQL database?

Question

Here's the error message that is stumping me:

My Web App seems to have the correct connection string. This is exactly what Azure provides me when I click Show Connection String:

Server=tcp:myservertest.database.windows.net,1433;Initial Catalog=MyDatabaseTest;Persist Security Info=False;User ID={your_username};Password={your_password};MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;

Here's the connection string that I put in the Visual Studio Publish Settings Default Connection setting:

Server=tcp:myservertest.database.windows.net,1433;Initial Catalog=MyDatabaseTest;Persist Security Info=False;User ID=*****;Password=***********;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;

I have confirmed the username and password are correct...I used the same ones to connect via Microsoft SQL Server Management Studio.

I tried setting up the Diagnostic settings as follows, but I'm not exactly sure where I can find the resulting logs. I don't see them in Kudo services, but I believe they'd be accessed elsewhere.

Does anyone know where they're stored?

Also, what other ways could this Login failed for user error message be debugged?

Answer 1

The error looks like you are able to connect to the server but the server rejects the login. Debugging in the server logs would help, so you are looking at the right place.

You can enable Azure SQL Database Auditing & Threat Detection. You can enable it on SQL Server instance level by opening your SQL Server resource and selecting Security / Auditing & Threat Detection. Select a storage account to store logs in Storage details (see picture below). For more information, see https://docs.microsoft.com/en-us/azure/sql-database/sql-database-auditing.

After enabling auditing try to login to your database. After that you can find the logs in the specified Azure Storage Account in blob container named sqldbauditlogs. The logs are in folder /servername/databasename/SqlDbAuditing_ServerAudit_NoRetention/yyyy-mm-dd/ in files with xel extension. You can download and open the .xel -file in SSMS (File / Open / File…). The xel file contains events and you can see login attempts there.

Event field succeeded tells if the login failed or not, and field server_principal_name contains the username in both cases. From text in field additional_information you can find error_code (in the xml). Error code 40615 is blocked by firewall and code 18456 is wrong username or password. (error codes from https://docs.microsoft.com/en-us/azure/sql-database/sql-database-develop-error-messages)

You can also find some information in the database system tables for analysing the connections, e.g. sys.event_log (see: https://docs.microsoft.com/en-us/sql/relational-databases/system-catalog-views/sys-event-log-azure-sql-database?view=azuresqldb-current).

More information on troubleshooting the Azure SQL Database connectivity can be found here: https://docs.microsoft.com/en-us/azure/sql-database/sql-database-troubleshoot-common-connection-issues.

I hope this helps you forward with debugging the connection.

Answer 2

You've verified that Allow access to Azure services is ON. This is generally where we get tripped up. If it was coming from an outside place, we'd want to check the IP list here. Knowing that's not it, let's dig deeper.

You've gotten into the Kudu console to verify all the things. From that console, install mssql-cli. Run pip install mssql-cli from the Kudu console. If that doesn't work, look for direct urls curl or download to your PC and use the Kudu Console to upload the file into your app service.

Once you have the mssql-cli installed, try connecting with the credentials you've set in place in appSettings.json. (See https://github.com/dbcli/mssql-cli/blob/master/doc/usage_guide.md#options for command line options.) Most probably, it'll spit out a nice error message about why it can't connect, giving you more clues.

If mssql-cli connects successfully, there's something overriding your app's settings. Did you set the connection string in the Azure Portal's App Settings tab? Temporarily, you might alter your app to write portions of the connection string to an obscure page. And as soon as you get the info, DELETE THE PAGE and then change the password.

Another thing to try: grab all the details from the exception -- including Data and recursively through inner exceptions. It probably has a clue buried in there. You can remotely debug the app on Azure. Before you can debug, you'll need to ensure you've turned on remote debugging and selected the correct version of Visual Studio from the App Settings blade in your App Service.

Answer 3

Continue from comment - Where in Kudu would that be found? Justin in the general file explorer?

Go to Debug console > CMD - site > wwwroot - click Edit icon

Also ensure that Allow access to Azure services is ON.

Answer 4

Sometimes you need to check the connection string on azure application in azure. Maybe the connection string is different from the one in your web.config