Failure to authenticate with SQL Azure

[fergusontom]

Describe the bug
When trying to connect to SQL Azure using AAD Managed Identity authentication from the dotnet core SqlClient v2.1.0-preview2.20297.7, the NMI logs the following warning

W1028 15:35:04.686248 1 server.go:336] parameter resource cannot be empty
I1028 15:35:04.686418 1 server.go:192] status (400) took 200513 ns for req.method=GET reg.path=/metadata/identity/oauth2/token req.remote=172.25.156.61
I1028 15:35:04.717723 1 standard.go:72] no clientID or resourceID in request. namespace-123/pod-456-644c84d44f-bsdnv has been matched with azure identity namespace-123/identity-456
I1028 15:35:04.717775 1 standard.go:178] matched identityType:0 clientid:be3a##### REDACTED #####6f6d resource:https://database.windows.net/
I1028 15:35:04.728655 1 server.go:192] status (200) took 11008060 ns for req.method=GET reg.path=/metadata/identity/oauth2/token req.remote=172.25.156.61

My pod then gives the following SQL connection error
Unhandled exception. Microsoft.Data.SqlClient.SqlException (0x80131904): Login failed for user '<token-identified principal>'.

Even though the managed identity has been created as a login on the SQL instance as follows
CREATE USER [identity-456] FROM EXTERNAL PROVIDER;

@cheenamalhotra
Apologies, but it is not clear to me whether this is a problem on the AKS side or the SQL side. Perhaps I should be raising this as an issue with the SqlClient?

Steps To Reproduce

1. Create managed identity in a new resource group
2. Give the AKS identity the "Managed Identity Operator" role on the resource group
3. Create a SQL login associated with the new managed identity
4. Create AzureIdentity in AKS associated with the managed identity
5. Apply label to pod which is connecting to sql - aadpodidbinding: pod123
6. Create AzureIdentityBinding associating pod123 with the AzureIdentity
7. Attempt to connect to SQL Azure from within the pod

Expected behavior
SQL Client should be able to connect successfully

AAD Pod Identity version
1.6.3

Kubernetes version
1.18.8

Additional context

[fergusontom]

This was a stupid configuration error on my part: I had created the SQL login in the wrong database.