Reparar usuarios huérfanos de SQL Server tras restaurar

Una restauración puede finalizar correctamente y dejar a la aplicación sin acceso. Una causa habitual es un usuario huérfano: la base contiene una asociación a un SID de login que no existe en la instancia de destino. Recrear un login con el mismo nombre visible no garantiza recuperar el mismo SID.

Separa autenticación y autorización. El login establece identidad en la instancia. El usuario de base la representa dentro de una base concreta y conserva roles y permisos. Restaurar trae el usuario, pero no automáticamente todos los logins y dependencias de instancia.

Diagnosticar la asociación por SID

Ejecuta esta consulta de lectura en la base restaurada desde una conexión administrativa con visibilidad suficiente sobre los principales del 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;

La consulta se centra en usuarios de autenticación SQL asociados a logins de instancia. No audita universalmente grupos Windows, usuarios contenidos, certificados o identidades externas. Un usuario WITHOUT LOGIN no está roto por carecer de login.

La visibilidad de metadatos importa. Una cuenta limitada puede no ver todos los logins y producir falsos huérfanos. Confirma el resultado en el contexto administrativo autorizado antes de cambiar asociaciones.

Inspecciona por separado el login de destino: SID, habilitación, tipo de autenticación y finalidad. Un nombre coincidente es una pista, no autorización para unir identidades. Entornos diferentes pueden usar ese nombre para servicios distintos.

Distingue también login deshabilitado, base predeterminada no disponible, cadena de conexión incorrecta o falta de CONNECT. El error 18456 por sí solo no completa el diagnóstico. Consulta sus detalles del servidor y realiza un intento real de conexión.

Reasociar el usuario existente

Si ya existe el login correcto, cambia la asociación sin recrear el usuario.

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

AppUser y AppLogin son nombres ilustrativos que debes sustituir por la pareja verificada. ALTER USER conserva el principal existente, permitiendo mantener sus permisos y relaciones con roles.

Eliminarlo como atajo puede perder permisos explícitos o fallar porque posee esquemas u objetos. Recrearlo con el mismo nombre no recupera necesariamente todas sus relaciones. Evita convertir una reparación de identidad en un rediseño accidental de permisos.

Si hace falta recrear el login, decide si preservarás el SID original mediante un proceso aprobado de migración. Puede mantener asociaciones en varias bases restauradas. Gestiona credenciales y políticas del login mediante el proceso seguro habitual, sin copiar contraseñas a scripts improvisados.

No reasocies automáticamente todos los usuarios solo por nombre. Revisa una lista concreta de identidades originales y de destino, especialmente al consolidar instancias. El mismo nombre puede ocultar fronteras de confianza diferentes.

Verificar identidad y capacidades

Confirma los SID y revisa los roles esperados.

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';

La consulta de roles solo muestra parte del inventario. Concesiones directas, permisos de esquema, DENY y propiedad también afectan al acceso. Compara permisos relevantes antes y después en vez de asumir que las membresías lo describen todo.

Abre después una conexión nueva con el login real de la aplicación y su base inicial. Ejecuta una operación permitida y confirma que otra fuera del rol siga denegada. Probar únicamente como sysadmin evita precisamente la ruta reparada.

En un grupo de disponibilidad, prepara los logins en cada réplica que pueda ser primaria. Que funcione la primaria actual no demuestra que funcione un futuro failover. Incluye identidades en los ensayos de restauración y conmutación.

Los usuarios contenidos pueden reducir dependencias de instancia cuando su modelo encaja, pero adoptarlos es una decisión distinta sobre autenticación, conexiones y seguridad. No son una reparación urgente universal.

Conserva asociaciones verificadas y resultados en el registro de migración. Una restauración completada debe significar que la identidad prevista puede realizar su trabajo con sus límites de acceso intactos.

Referencias técnicas: Microsoft Learn: Troubleshoot orphaned users · Microsoft Learn: ALTER USER.