Baza danych Azure SQL „Logowanie nie powiodło się dla użytkownika” w aplikacji, ale działa dobrze w SSMS

Chciałem wypróbować funkcję użytkowników bazy danych zawartej w bazie danych Azure SQL Database 12, ale mam problem z uwierzytelnieniem, który wydaje mi się dziwny.

Utworzyłem bazę danych o nazwie Classifier. Dodałem mój adres IP do reguł zapory, aby móc połączyć się z serwerem db Azure z SSMS na mojej stacji roboczej. Gdy udało mi się połączyć za pośrednictwem SSMS w celu administrowania, próbowałem dodać użytkownika z hasłem do bazy danych:

CREATE USER classifier WITH PASSWORD='thepassword'

Dodałem także tego użytkownika do ról pisarza i czytelnika:

exec sp_addrolemember 'db_datawriter', 'classifier'
exec sp_addrolemember 'db_datareader', 'classifier'

Po tym jestem w stanie połączyć się z bazą danych przy użyciu tych poświadczeń z SSMS:

Ale tutaj wszystko idzie nie tak: wypróbowałem kilka różnych inkantacji ciągu połączenia i nie mogę się połączyć w aplikacji internetowej, nad którą pracuję. Nie działało w środowisku Azure, więc działam na localhost z parametrem połączenia z bazą danych Azure i po prostu się nie łączy. Oto ciąg połączenia, którego obecnie używam:

<add name="Classifier" connectionString="Data Source=xxxxxxx.database.secure.windows.net;Initial Catalog=Classifier;User ID=classifier;Password=xxxxxxxxxxxxx;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;" providerName="System.Data.SqlClient"/>

Próbowałem zresetować hasło użytkownika (przez SSMS), a następnie zaktualizować parametry połączenia; Sprawdziłem również dwukrotnie hasło, kopiując je bezpośrednio z tego ciągu połączenia i do okna dialogowego połączenia w SSMS, aby upewnić się, że nie mam tam literówki.

Włączyłem inspekcję na serwerze db Azure, mając nadzieję uzyskać szczegółowe informacje na temat przyczyny niepowodzenia, ale otrzymuję tylko:

I tu utknąłem. Większość tego, co udało mi się znaleźć za pomocą dokumentacji lub blogów, wskazuje, że należy spojrzeć na dzienniki programu SQL Server, aby zobaczyć, jaki jest rzeczywisty stan błędu, który wskazywałby węższy charakter awarii, ale ponieważ Mam do czynienia z platformą Azure, nie ma na to sposobu (o ile wiem).

Co może spowodować awarię aplikacji w przypadku powodzenia SSMS (i, nawiasem mówiąc, LinqPad i Visual Studio Server Explorer)?

Stwierdziliśmy, że w przypadku zawartych baz danych / ograniczonych użytkowników należy określić:

GRANT CONNECT TO [YOUR_USER]

W przeciwnym razie CONNECTwydaje się, że jest domyślnie odwołany. Po wprowadzeniu powyższej zmiany możemy uzyskać dostęp do bazy danych.

Podczas przełączania naszego interfejsu API w celu łączenia się z bazą danych Azure za pośrednictwem nowego zawartego użytkownika musieliśmy zmienić parametry połączenia, aby uwzględnić:

Persist Security Info=True;

Chociaż nie rozumiem, dlaczego ta zmiana była wymagana, chciałem opublikować tutaj, aby pomóc komuś innemu w przyszłości.

Pierwotnie przyszliśmy spróbować tego z tego pytania .

Mój problem był inny, ale związany: próbowałem połączyć się z bazą danych Azure SQL przy użyciu programu SQL Server Management Studio (SSMS) z zawartym użytkownikiem . Otrzymałem komunikat „Logowanie nie powiodło się dla użytkownika” w SSMS.

Rozwiązanie: w opcjach połączenia SSMS dla okna zapytania ustawiłem „Połącz z bazą danych” na nazwę bazy danych, z którą próbowałem się połączyć.

Objaśnienie: Z perspektywy czasu powód był oczywisty: ograniczeni użytkownicy mogą łączyć się tylko z bazą danych, w której zostali utworzeni.

Może się to zdarzyć, jeśli uruchomisz polecenie PowerShell zawierające ciąg połączenia, gdy hasło zawiera $. Możesz obejść ten problem, dołączając ciąg połączenia pojedynczymi cudzysłowami - lub nie przechowując hasła w ciągu połączenia ;-)

Na przykład. Wpadłem na to z Scaffold-DbContextrozkazem

https://github.com/aspnet/EntityFrameworkCore/issues/6624