Correction pour l'utilisateur orphelin «invité»?

Que peut-on faire, le cas échéant, lorsque l' guestutilisateur spécial est orphelin (pas lié à une connexion)?

Pour l'une de mes bases de données (SQL Server 2005), l'exécution de ce qui suit répertorie l' utilisateur invité en tant qu'utilisateur orphelin.

exec sp_change_users_login 'report'

Résultats:

UserName    UserSID
guest       0x3C2E66759FFBC14F84127D6795C27FD3

Si j'essaie de réparer l' utilisateur invité à l'aide de cette procédure, j'obtiens ce qui suit:

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

Mettre fin à cette procédure. 'guest' est une valeur interdite pour le paramètre de nom de connexion dans cette procédure.

Si j'essaie de supprimer l'utilisateur, j'obtiens:

L'utilisateur «invité» ne peut pas être supprimé, il peut uniquement être désactivé.

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

Résulte 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 données semble confuse quant à savoir s'il s'agit d'un utilisateur spécial ou non. Peut-on faire quelque chose?

L'utilisateur «invité» n'est jamais affecté à une connexion au serveur, même lors d'une nouvelle installation, il est classé comme utilisateur SQL sans connexion. Comme vous ne pouvez définir que le SID d'une connexion (lors de la création), et non un utilisateur, je ne pense pas que cela soit possible; sp_change_users_login ne fonctionne pas précisément parce que le compte invité ne doit jamais être mappé à une connexion au serveur. En conséquence, l'utilisateur "invité" est toujours un utilisateur orphelin. Mais ce n'est probablement pas la réponse que vous vouliez :)

Mes pensées ... La raison de sp_change_users_logincette erreur est que MS l'a aussi écrite. [Regarder le code de procédure système de temps en temps peut être amusant. :)] Cependant, le fait qu'il apparaisse lors de l'exécution du rapport indique que quelqu'un / un processus a foiré le compte, ou qu'un correctif logiciel possible de MS aurait pu le faire (on ne sait jamais).

Le compte invité est censé être là, il existe dans chaque base de données créée car le compte existe par défaut dans le modèle. Pour que cela n'apparaisse pas dans le rapport, il faudrait probablement que le SID soit changé, 0x00je suppose. Tant que le compte est désactivé, je le laisse tranquille et je l'ignore. Si cela me dérangeait vraiment, je débourserais l'argent et téléphonerais au support Microsoft.

Remarque: Chaque fois que vous déplacez votre base de données d'un serveur vers un autre serveur, un problème d'utilisateur orphelin se produit généralement. FileListOnly est le nouveau terme dans SQL Server qui contient tous les détails de la sauvegarde créée qui y a accès.

Il y a donc une séquence de tâches que vous devez suivre

1. Vous devez d'abord restaurer FileListOnly à partir de la sauvegarde créée vers le serveur de destination ou le nouveau.
2. Restaurez la sauvegarde.
3. Utilisez le sp_change_users_login selon le besoin. Pour obtenir de l'aide concernant cette procédure, vous pouvez consulter http://msdn.microsoft.com/en-us/library/ms174378.aspx .

Je mets ici un exemple en espérant que cela vous aidera:

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