Corrigir usuários órfãos do SQL Server após restauração

Uma restauração pode terminar com sucesso e a aplicação continuar sem acesso. Uma causa comum é um usuário órfão: a base contém um usuário associado a um SID de login ausente na instância de destino. Recriar o login com o mesmo nome visível não garante o mesmo SID.

Separe autenticação e autorização. O login estabelece identidade na instância. O usuário de banco representa essa identidade em uma base específica e possui ali roles e permissões. Restaurar traz o usuário, mas não automaticamente todos os logins e dependências da instância.

Diagnosticar o vínculo pelo SID

Execute a leitura na base restaurada com uma conexão administrativa que tenha visibilidade suficiente dos principais do servidor.

-- SQL-authenticated, instance-mapped users in the current database.
SELECT dp.name AS DatabaseUser, dp.sid AS DatabaseUserSid,
       dp.authentication_type_desc
FROM sys.database_principals AS dp
LEFT JOIN sys.server_principals AS sp ON sp.sid = dp.sid
WHERE dp.type = 'S'
  AND dp.authentication_type_desc = 'INSTANCE'
  AND dp.principal_id > 4
  AND sp.principal_id IS NULL
ORDER BY dp.name;

A consulta se limita intencionalmente a usuários de autenticação SQL mapeados a logins de instância. Não cobre universalmente grupos Windows, usuários contidos, certificados ou identidades externas. Um usuário WITHOUT LOGIN não está quebrado simplesmente por não possuir login.

A visibilidade de metadados importa. Uma conta restrita pode não enxergar todos os logins e apontar falsos órfãos. Confirme os resultados no contexto administrativo aprovado antes de alterar vínculos.

Examine separadamente o login pretendido: SID, habilitação, tipo de autenticação e finalidade. Nomes iguais são indícios, não autorização para associar identidades. Ambientes diferentes podem usar o mesmo nome para serviços diferentes.

Diferencie ainda login desabilitado, base padrão indisponível, string de conexão errada e ausência de CONNECT. O erro 18456 sozinho não fecha o diagnóstico. Use detalhes do servidor e uma tentativa real de conexão para identificar a etapa da falha.

Remapear o usuário existente

Se o login correto já existe, altere o vínculo no próprio usuário.

-- Run in the restored database only after verifying the intended mapping.
ALTER USER [AppUser] WITH LOGIN = [AppLogin];

AppUser e AppLogin são nomes ilustrativos e devem ser substituídos pelo par verificado. ALTER USER mantém o principal existente em vez de removê-lo e recriá-lo, permitindo preservar permissões e relações com roles.

Excluir como atalho pode perder permissões explícitas ou falhar porque o usuário possui esquemas. Recriar com o mesmo nome não necessariamente restaura todas as relações. Não transforme um reparo de mapeamento em mudança acidental de acesso.

Se o login realmente precisa ser recriado, decida se o SID original será preservado por um processo aprovado de migração. Isso pode manter vínculos em várias bases restauradas. Trate credenciais e políticas de conta pelo processo seguro existente, sem copiar senhas para scripts improvisados.

Evite remapeamento automático de todos os usuários apenas por nome. Revise uma lista concreta de identidades de origem e destino, especialmente ao consolidar instâncias. Nomes iguais podem esconder fronteiras de confiança distintas.

Validar identidade e capacidade

Confirme os SIDs e confira as roles esperadas.

SELECT dp.name AS DatabaseUser, sp.name AS MappedLogin,
       dp.sid AS DatabaseUserSid, sp.sid AS LoginSid
FROM sys.database_principals AS dp
JOIN sys.server_principals AS sp ON sp.sid = dp.sid
WHERE dp.name = N'AppUser';

SELECT r.name AS DatabaseRole
FROM sys.database_role_members AS drm
JOIN sys.database_principals AS r ON r.principal_id = drm.role_principal_id
JOIN sys.database_principals AS m ON m.principal_id = drm.member_principal_id
WHERE m.name = N'AppUser';

A consulta de roles é apenas parte do inventário. Permissões diretas, direitos de esquema, DENY e propriedade também influenciam o acesso. Compare os direitos relevantes antes e depois em vez de presumir que roles explicam tudo.

Abra então uma conexão nova com o login real da aplicação e a base inicial correta. Execute uma operação permitida e confirme que uma fora do papel continue negada. Testar somente como sysadmin ignora justamente o caminho reparado.

Em grupos de disponibilidade, prepare os logins necessários em todas as réplicas que podem assumir como primárias. A primária atual funcionando não comprova um failover futuro. Inclua identidade nos ensaios de restauração e troca de primária.

Usuários contidos podem reduzir a dependência de logins da instância quando esse modelo faz sentido. A adoção é uma escolha separada envolvendo autenticação, conexão e política de segurança, não uma solução emergencial universal.

Mantenha vínculos verificados e resultados no registro da migração. Uma restauração concluída deve significar que a identidade certa consegue executar suas tarefas com os limites de acesso preservados.

Referências técnicas: Microsoft Learn: Troubleshoot orphaned users · Microsoft Learn: ALTER USER.