Solución para el usuario huérfano 'invitado'?

¿Qué se puede hacer, en todo caso, cuando el guestusuario especial queda huérfano (no está vinculado a ningún inicio de sesión)?

Para una de mis bases de datos (SQL Server 2005), ejecutar lo siguiente enumera al usuario invitado como un usuario huérfano.

exec sp_change_users_login 'report'

Resultados:

UserName    UserSID
guest       0x3C2E66759FFBC14F84127D6795C27FD3

Si trato de arreglar el usuario invitado usando ese procedimiento, obtengo lo siguiente:

exec sp_change_users_login 'update_one', 'guest', 'guest'

Terminando este procedimiento. 'guest' es un valor prohibido para el parámetro de nombre de inicio de sesión en este procedimiento.

Si intento eliminar al usuario, obtengo:

El usuario 'invitado' no se puede descartar, solo se puede deshabilitar.

select * from sys.database_principals where name = 'guest'

Resultados en:

name                 guest
principal_id         2
type                 S
type_desc            SQL_USER
default_schema_name  guest
create_date          11/13/98 2:58 AM
modify_date          10/16/01 4:31 PM
owning_principal_id  NULL
sid                  0x3C2E66759FFBC14F84127D6795C27FD3
is_fixed_role        0

La base de datos parece estar confundida sobre si se trata de un usuario especial o no. ¿Hay algo que se pueda hacer?

El usuario "invitado" nunca se asigna a un inicio de sesión del servidor, incluso en una instalación nueva se clasifica como un usuario SQL sin un inicio de sesión. Como solo puede establecer el SID de un inicio de sesión (después de la creación), y no un usuario, no creo que esto sea posible; sp_change_users_login no funciona precisamente porque la cuenta de invitado nunca debe asignarse a un inicio de sesión del servidor. Como resultado, el usuario "invitado" siempre es un usuario huérfano. Probablemente no sea la respuesta que querías :)

Mis pensamientos ... La razón sp_change_users_logines arrojar ese error porque MS también lo escribió. [Revisar el código de procedimiento del sistema de vez en cuando puede ser divertido. :)] Sin embargo, el hecho de que aparezca cuando se ejecuta el informe indica que alguien / algún proceso se equivocó con la cuenta, o una posible solución de MS podría haberlo hecho (nunca se sabe).

Se supone que la cuenta de invitado está allí, existe en cada base de datos que se crea, ya que la cuenta existe en el modelo de forma predeterminada. Hacer que no aparezca en el informe probablemente requeriría que el SID volviera a cambiar 0x00, supongo. Mientras la cuenta esté deshabilitada, la dejaría sola y la ignoraría. Si realmente me molestara, gastaría el dinero y llamaría con el soporte de Microsoft.

Nota: Cada vez que mueve su base de datos de un servidor a otro, generalmente se produce un problema de usuario huérfano. FileListOnly es el nuevo término en el servidor sql que tiene todos los detalles de la copia de seguridad creada que tiene acceso a ella.

Así que hay una secuencia de tareas que debes seguir

1. En primer lugar, debe restaurar FileListOnly desde la copia de seguridad creada al destino o al nuevo servidor.
2. Restaurar la copia de seguridad.
3. Utilice sp_change_users_login según la necesidad. Para obtener ayuda con respecto a este procedimiento, puede consultar http://msdn.microsoft.com/en-us/library/ms174378.aspx .

Pongo un ejemplo aquí, espero que ayude:

> RESTORE FILELISTONLY FROM DISK = N'C:\YourDB.bak'
> 
> RESTORE DATABASE YourDb FROM DISK = N'C:\YourDB.bak' WITH MOVE
> N'YourDB' TO N'D:\YourDB.mdf', MOVE N'YourDB_log' TO N'D:\YourDB.ldf',
> REPLACE
> 
> exec YourDB.dbo.sp_change_users_login 'update_one', 'UserName','UserName'