Risolto il problema con l'utente orfano "ospite"?

Cosa si può fare, se non altro, quando l' guestutente speciale è orfano (non collegato a nessun accesso)?

Per uno dei miei database (SQL Server 2005), l'esecuzione di seguito elenca l' utente guest come utente orfano.

exec sp_change_users_login 'report'

risultati:

UserName    UserSID
guest       0x3C2E66759FFBC14F84127D6795C27FD3

Se provo a riparare l' utente guest usando quella procedura, ottengo quanto segue:

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

Terminare questa procedura. 'guest' è un valore proibito per il parametro del nome di accesso in questa procedura.

Se provo a eliminare l'utente, ottengo:

L'utente "ospite" non può essere eliminato, può solo essere disabilitato.

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

Risultati in:

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

Il database sembra essere confuso sul fatto che si tratti di un utente speciale o meno. c'è qualcosa che si può fare?

sql-server sql-server-2005

— JustinStolle
fonte

Il suo SID è elencato come 0x3C2E66759FFBC14F84127D6795C27FD3anziché0x00

— JustinStolle il

Hai già provato a fare la correzione automatica? Sono curioso di vedere il risultato.

— SQLRockstar

RicevoTerminating this procedure. 'guest' is a forbidden value for the login name parameter in this procedure.

— JustinStolle il

Viene visualizzato questo errore perché non è possibile avere guest come nome utente ( msdn.microsoft.com/en-us/library/ms174378.aspx ). Sto facendo fatica a ricreare il tuo scenario.

— Thomas Stringer,

Vorrei aggiungere che ho riscontrato esattamente lo stesso problema di Justin. Il problema qui è che il sid dell'ospite dovrebbe essere 0x00 ma per qualsiasi motivo non lo è e come tale sp_change_users_login 'report' lo prenderà come utente orfano. Non riesco proprio a vedere che c'è un modo per i DBA di cambiare o rovinare [guest] in modo normale. Quindi penso che questo casino sia altamente possibile creato dalle patch del server sql qualche volta, in qualche modo.

— jyao,

Risposte:

L'utente "guest" non viene mai assegnato a un accesso al server, anche su una nuova installazione viene classificato come utente SQL senza un accesso. Poiché è possibile impostare solo il SID di un accesso (al momento della creazione) e non un utente, non credo che ciò sia possibile; sp_change_users_login non funziona esattamente perché l'account guest non deve mai essere associato a un accesso al server. Di conseguenza, l'utente "ospite" è sempre un utente orfano. Probabilmente non è la risposta che volevi però :)

— World Wide DBA
fonte

Pensi che ci sia un modo per eseguire il backup / ripristinare questo database in un'altra posizione lasciando fuori l'utente guest dal ripristino?

— JustinStolle,

Sì, ma non è carino. Un semplice backup e ripristino non funzionerebbe in quanto l'utente guest sarebbe incluso in questo. Dovresti iniziare con un nuovo database creato utilizzando lo stesso metodo usato per installarlo originariamente (supponendo che il guest nel modello abbia il SID corretto). Quindi dal tuo sistema esistente esporta tutti i dati nel tuo nuovo database. Funzionerebbe, ma è un grande sforzo per qualcosa di così minore ...

— World Wide DBA

Quindi, nonostante l'account abbia un SID imprevisto, pensi che non ci sia davvero un problema con esso ed è sicuro ignorarlo nel sp_change_users_loginrapporto?

— JustinStolle,

In questo caso, lo direi, basandomi sul fatto che in realtà non si può fare molto. Poi c'è il classico dibattito sull'opportunità o meno di utilizzarlo, ma questa è una domanda completamente diversa ... :)

— World Wide DBA

I miei pensieri ... La ragione sp_change_users_loginsta gettando quell'errore è perché anche MS l'ha scritto. [Di tanto in tanto guardare il codice della procedura di sistema può essere divertente. :)] Tuttavia, il fatto che venga visualizzato durante l'esecuzione del rapporto indica che qualcuno / qualche processo ha incasinato l'account o che una possibile correzione rapida da parte di MS potrebbe averlo fatto (non si sa mai).

Si suppone che l'account guest sia presente, esiste in ogni database creato poiché l'account esiste nel modello per impostazione predefinita. Fare in modo che non venga visualizzato nel rapporto probabilmente richiederebbe la modifica del SID a 0x00indovinare. Fintanto che l'account è disabilitato lo lascerei da solo e lo ignorerei. Se mi dava davvero fastidio, avrei sborsato i soldi e chiamato con il supporto Microsoft.

In altre parole, stai dicendo che non è un problema che si guestmanifesta nei risultati in questo caso.

— JustinStolle,

Praticamente sì.

Nota: ogni volta che si sposta il database da un server a un altro server, si verifica di solito un problema di utente orfano. FileListOnly è il nuovo termine in SQL Server che ha tutti i dettagli del backup creato che ha accesso ad esso.

Quindi ci sono sequenze di attività che devi seguire

Innanzitutto è necessario ripristinare FileListOnly dal backup creato sulla destinazione o sul nuovo server.

Ripristina il backup.

Utilizzare sp_change_users_login secondo le necessità. Per assistenza in merito a questa procedura, è possibile fare riferimento a http://msdn.microsoft.com/en-us/library/ms174378.aspx .

Ho messo un esempio qui spero che possa aiutare:

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

— JP Chauhan
fonte

Questo non funzionerà per l' guestutente. Vedi la risposta sopra di Mr.Brownstone.

— Simon Righarts,