Início / dba / Perguntas / 193138
Accepted
Shaul Behr
Asked: 2017-12-15 06:25:46 +0800 CST

Por que o usuário não tem acesso ao banco de dados?

  • 772

Eu tenho um usuário ls_readonlyque deveria ter db_datareaderprivilégios em vários bancos de dados. Achei que tinha configurado direitinho:

insira a descrição da imagem aqui

Mas quando eu me conecto ao servidor como ls_readonlye tento abrir o db no Object Explorer, recebo um erro:

O banco de dados wtest não está acessível. (Explorador de Objetos)

Eu abro uma janela de consulta mastere tento executar:

use wtest

Isso responde com:

Msg 916, Level 14, State 1, Line 1
The server principal "ls_readonly" is not able to access the database "wtest" under the current security context.

o que estou perdendo?

ATUALIZAÇÃO: aqui está uma pista. Se eu excluir ls_readonlycomo usuário do contexto de segurança do banco de dados, vou para o usuário no contexto de segurança do servidor e em "Mapeamento do usuário" concedo acesso ao banco de dados e ele começa a funcionar.

Pode ser que o banco de dados tenha sido originalmente restaurado de um servidor diferente, que também tenha um ls_readonlyusuário. Eu acho então que a identificação do usuário não é baseada no nome de usuário?

sql-server permissions

4 respostas

  1. Best Answer

    Pode ser que o banco de dados tenha sido originalmente restaurado de um servidor diferente, que também tenha um usuário ls_readonly. Eu acho então que a identificação do usuário não é baseada no nome de usuário?

    Normalmente, todos os logins têm o mesmo sidcom os usuários correspondentes. Esse é o sentido do CREATE USER FROM LOGINcomando: o banco de dados principal é criado com o mesmo sid(identificador de segurança) que o login correspondente possui.

    Este usuário sidagora está armazenado em seu banco de dados, e quando você backup/ restoreseu banco de dados o sid também é preservado.

    Imagine agora que você tem 2 servidores e ambos possuem ls_readonlylogin. para simplificar, no primeiro servidor ls_readonlytem sid= 1, no segundo sid= 2. Você tem o banco de dados MyDB onde este login está mapeado. No primeiro servidor MyDB armazena sid= 1, no segundo sid= 2.

    Você faz backup do banco de dados MyDB no primeiro servidor e o restaura no segundo. Agora seu login tem sid= 2 e no banco de dados MyDB é sid= 1.

    Você faz login como ls_readonlye tenta acessar o MyDB, o servidor está verificando se há sid = 2 no banco de dados, não há, portanto, o servidor ls_readonlynão está mapeado para o MyDB.

    Isso pode ser corrigido fazendo

    alter user ls_readonly with login = ls_readonly;

    Este comando apenas atualiza o sid do ls_readonlyusuário do banco de dados com o sid do ls_readonlylogin. Todas as permissões são preservadas.

    Se você recriar o usuário descartando-o, depois de descartar o usuário, todas as permissões concedidas a ele serão descartadas e você precisará concedê-las novamente.

    • 16

  2. @sepupic cobre muito bem tudo o que eu teria sugerido, mas pensei em compartilhar o seguinte script que executo sempre que restauro um banco de dados cujo backup foi feito de uma instância do SQL Server e restaurado em outra. Execute-o no banco de dados que você acabou de restaurar. Basicamente automatiza o que o @sepupic está falando. (O executeestá comentado)

    SET NOCOUNT ON

DECLARE @cmd nVARCHAR(max) = ''

SELECT @Cmd = @cmd + 'ALTER USER ' + dp.NAME + ' WITH LOGIN = ' + dp.NAME + ';' + CHAR(10)
FROM sys.database_principals dp
LEFT JOIN master.sys.server_principals sp ON sp.NAME = dp.NAME
WHERE dp.type = 's'
    AND dp.default_schema_name <> dp.NAME
    AND sp.NAME IS NOT NULL
ORDER BY dp.NAME

PRINT @Cmd
--EXECUTE sp_executeSQL @CMD
    • 6

  3. Isso soa como um usuário órfão. Um usuário órfão é onde o SID do usuário não corresponde ao SID de login, não ao nome amigável que vemos (provavelmente foi causado quando um login foi excluído do servidor ou o banco de dados foi restaurado de um servidor diferente). Você não deve precisar excluir o usuário e recriá-lo, pois todas as permissões existentes seriam perdidas (ok, essa é apenas a função, mas diga que você tinha permissões individuais em outros objetos; procedimentos armazenados e tabelas etc). Existe um recurso que permite remapear o usuário para o login (mesmo que tenha o mesmo nome).

    use db1
GO
alter user [user_name] with login = [login_name]

    então gostaria de:

    use wtest
GO
alter user [ls_readonly] with login = [ls_readonly]

    Veja aqui para mais detalhes na documentação do MS

    • 5

  4. Solte o usuário do banco de dados
    Excluir e recriar o usuário
    Adicionar o usuário ao banco de dados

    Você pode não precisar do 2º, mas não deve doer

    • -2

relate perguntas