Início / dba / Perguntas / 102605
Accepted
Ben Collins
Asked: 2015-05-28 11:47:14 +0800 CST

Banco de Dados SQL do Azure "Falha no login do usuário" no aplicativo, mas funciona bem no SSMS

  • 772

Eu queria experimentar o recurso de usuários de banco de dados independente no Banco de Dados SQL do Azure V12, mas estou tendo um problema de autenticação que me parece estranho.

Criei um banco de dados chamado Classifier. Adicionei meu IP às regras de firewall para poder me conectar ao servidor db do Azure do SSMS na minha estação de trabalho. Assim que consegui me conectar via SSMS para administração, tentei adicionar um usuário com uma senha ao banco de dados, assim:

CREATE USER classifier WITH PASSWORD='thepassword'

Também adicionei este usuário às funções de gravador de dados e leitor:

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

Depois disso, consigo me conectar ao banco de dados com essas credenciais do SSMS:

insira a descrição da imagem aqui

Mas é aí que as coisas dão errado: eu tentei vários encantamentos de string de conexão diferentes e não consigo me conectar em um aplicativo da Web em que estou trabalhando. Não funcionou no ambiente do Azure, então estou executando em localhost com uma cadeia de conexão para o banco de dados do Azure e ele simplesmente não se conecta. Aqui está a string de conexão que estou usando no momento:

<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"/>

Já tentei redefinir a senha (via SSMS) do usuário e atualizar a string de conexão; Também verifiquei a senha copiando-a diretamente dessa cadeia de conexão e na caixa de diálogo de conexão no SSMS para garantir que não houvesse algum tipo de erro de digitação.

Habilitei a auditoria no servidor de banco de dados do Azure na esperança de obter alguns detalhes sobre o motivo da falha, mas tudo o que recebo é isso:

Err 18456, Level 14, State 1, Server SQL Azure, Line 1Login falhou para o usuário 'classificador'

E é aqui que estou preso. A maior parte do que consegui encontrar por meio de documentação ou blogs indica que a coisa a fazer é examinar os logs do SQL Server para ver qual é o estado real do erro, o que indicaria mais precisamente a natureza da falha, mas como estou lidando com o Azure, não há como fazer isso (até onde eu sei).

O que pode fazer com que o aplicativo falhe onde o SSMS (e o LinqPad e o Visual Studio Server Explorer, incidentalmente) for bem-sucedido?

authentication connections

5 respostas

  1. Best Answer

    Descobrimos que com bancos de dados independentes/usuários independentes você deve especificar:

    GRANT CONNECT TO [YOUR_USER]

    Caso contrário CONNECT, parece ser revogado por padrão. Uma vez que fizemos a alteração acima, poderíamos acessar o banco de dados.

    • 19

  2. Ao alternar nossa API para se conectar a um banco de dados do Azure por meio de um novo usuário independente, tivemos que alterar nossa cadeia de conexão para incluir:

    Persist Security Info=True;

    Embora eu não entenda por que essa mudança foi necessária, eu queria postar aqui caso isso ajude alguém no futuro.

    Nós originalmente viemos para tentar isso a partir desta pergunta .

    • 7

  3. Meu problema era diferente, mas relacionado: eu estava tentando me conectar a um banco de dados SQL do Azure usando o SQL Server Management Studio (SSMS) com um usuário contido . Eu estava recebendo uma mensagem "Falha no login para o usuário" no SSMS.

    Solução: nas opções de conexão do SSMS para a janela de consulta, configurei o "Conectar ao banco de dados" com o nome do banco de dados ao qual estava tentando me conectar.

    Explicação: Em retrospectiva, o motivo era óbvio: os usuários contidos só podem se conectar ao(s) banco(s) de dados em que foram criados.

    • 3

  4. Isso pode ocorrer se estiver executando um comando do Powershell contendo uma string de conexão quando sua senha contiver $. Você pode contornar isso colocando a string de conexão entre aspas simples - ou não armazenando sua senha na string de conexão em primeiro lugar ;-)

    Por exemplo. Eu corri para isso com o Scaffold-DbContextcomando

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

    • 1

  5. A causa no meu caso foi que estamos usando uma versão mais antiga do ASP.NET Identity. Quando você está atualizando o IdentityDbContext, ele verifica alguns objetos de banco de dados para uma verificação de versão. Ele faz isso abrindo uma segunda conexão SQL usando ConnectionString da primeira conexão:

    Do código-fonte do Identity :( https://github.com/aspnet/AspNetIdentity/blob/b7826741279450c58b230ece98bd04b4815beabf/src/Microsoft.AspNet.Identity.EntityFramework/IdentityDbContext.cs#L198 )

            internal static bool IsIdentityV1Schema(DbContext db)
        {
            var originalConnection = db.Database.Connection as SqlConnection;
            // Give up and assume its ok if its not a sql connection
            if (originalConnection == null)
            {
                return false;
            }

            if (db.Database.Exists())
            {
                using (var tempConnection = new SqlConnection(originalConnection.ConnectionString))
                {
                    tempConnection.Open();
                    return
                        VerifyColumns(tempConnection, "AspNetUsers", "Id", "UserName", "PasswordHash", "SecurityStamp",
                            "Discriminator") &&
                        VerifyColumns(tempConnection, "AspNetRoles", "Id", "Name") &&
                        VerifyColumns(tempConnection, "AspNetUserRoles", "UserId", "RoleId") &&
                        VerifyColumns(tempConnection, "AspNetUserClaims", "Id", "ClaimType", "ClaimValue", "User_Id") &&
                        VerifyColumns(tempConnection, "AspNetUserLogins", "UserId", "ProviderKey", "LoginProvider");
                }
            }

            return false;
        }

    Se Persist Security Info for false (como mencionado por outra resposta), essa verificação falhará (já que agora tenta abrir uma segunda conexão sem fornecer uma senha).

    Um sinalizador adicional pode ser passado para o IdentityDbConte

    var identityContext = new IdentityDbContext<UserModel>(config.ConnectionString, false);
    • 0

relate perguntas