Autorisations utilisateur gâchées après une sauvegarde -> Opération de restauration

11

J'ai dû déplacer plusieurs bases de données SQL Server 2008 vers notre nouveau serveur db, je les ai donc toutes sauvegardées (dans des fichiers .bak), copiées ces fichiers dans la nouvelle boîte et restaurées (le tout à l'aide de SQL Management Studio).

Tout s'est bien passé mais maintenant je trouve que je ne peux pas me connecter à aucune des bases de données en utilisant le compte SQL Server qui continue de fonctionner sur l'ancien SGBDR. Ma connexion authentifiée par Windows fonctionne toujours bien d'ailleurs.

J'ai eu cette idée que les utilisateurs et les autorisations seraient tous dupliqués de manière transparente sur le nouveau serveur de base de données, mais il semble que quelque chose s'est mal passé quelque part. J'apprécierais les commentaires / suggestions / offres d'aide ;-)

sql-server sql-server-2008 backup restore permissions 5arx
la source

Réponses:

7

Je vois que vous avez déjà trouvé une solution à votre problème, une chose que j'ai remarquée dans votre question d'origine était que vous aviez toujours accès à l'ancien serveur.

La question suivante sur SO avait un problème similaire et inclut des liens vers un article Microsoft avec un script pour générer les autorisations utilisateur.

/programming/461385/restoring-a-backup-to-a-different-server-user-permissions

(Ressource répertoriée pour cette question http://support.microsoft.com/kb/918992 )

Il semble que la modification du paramètre du serveur de l'authentification Windows en authentification en mode mixte ait résolu votre problème, mais juste au cas où cela ne résoudrait pas complètement le problème, j'ai pensé que cela pourrait être utile.

Jeff
la source
Je suis sûr que ce ne sera pas la première fois que je me débattre avec SQL Server sur les utilisateurs / autorisations, je vais donc mettre l'article en signet pour la postérité. Merci beaucoup d'avoir posté.
5arx
6

C'est ce qu'on appelle des "utilisateurs orphelins". Voici 2 façons de le réparer

  1. Si vous le pouvez, restaurez la base de données principale d'origine en tant que "source de connexion" et sys.server_principals a suffisamment d'informations pour générer toutes les connexions SQL Server et Windows. Autrement dit, les SID et le mot de passe crypté

  2. Si vous utilisez uniquement les connexions Windows, vous pouvez l'exécuter par base de données pour générer un script

Scénario:

SELECT
    'CREATE LOGIN [' + SUSER_SNAME(sid) + '] FROM WINDOWS'
FROM
    sys.database_principals
WHERE
    [type] IN ('G', 'U')
gbn
la source
Merci pour votre réponse - mon application Web utilise des connexions SQL tandis que nos comptes Windows sont utilisés à des fins d'administration. Je ne vois pas de moyen de restaurer en tant que «source de connexion» comme vous le suggérez - pourriez-vous s'il vous plaît élaborer? J'espère tout cela peut être fait en utilisant Managment Studio?
5arx
PS. J'ai suivi ce doc: support.microsoft.com/kb/274188 et exécuté tous les scripts (apparemment) avec succès. Mais rien n'a changé.
5arx
5

Idéalement, vous devez créer un script pour les utilisateurs et les autorisations avant d'effectuer la restauration. Si cela ne s'est pas produit, vous devez alors réparer les choses après coup, et il y a des chances que quelque chose soit manqué, mais vous devriez pouvoir obtenir environ 90% du chemin.

La première chose que vous devez vérifier est de savoir si les mêmes connexions existent sur le nouveau serveur. S'ils ne le font pas, vous devez vérifier si les connexions doivent être créées sur le nouveau serveur. Ne présumez jamais qu'ils devraient être créés, il pourrait y avoir une bonne raison pour laquelle ils n'existaient pas en premier lieu. Vous pouvez ensuite les créer en fouillant dans la table sysusers.

Vous pouvez corriger les utilisateurs orphelins en exécutant quelque chose de semblable au suivant:

DECLARE @username varchar(25), @loginsid varbinary(85)
DECLARE fixusers CURSOR
FOR
SELECT UserName = name 
    FROM sysusers
    WHERE issqluser = 1 
    and (sid is not null and sid <> 0x0)
    and suser_sname(sid) is null
    and name in (select name from master..syslogins)
    ORDER BY name
OPEN fixusers
FETCH NEXT FROM fixusers
INTO @username
WHILE @@FETCH_STATUS = 0
BEGIN
    EXEC sp_change_users_login 'update_one', @username, @username

    FETCH NEXT FROM fixusers
    INTO @username
END CLOSE fixusers
DEALLOCATE fixusers

Ce code fonctionnera pour SQL2008, mais a été écrit pour être rétrocompatible pour SQL2000.

SQLRockstar
la source
Merci pour le script. Puis-je supposer qu'il n'y a aucun moyen de le faire dans Management Studio? En outre, certaines personnes suggèrent de supprimer et de recréer les utilisateurs de niveau DB - est-ce recommandé?
5arx
Cela suppose que les connexions existent déjà et ne correspondent qu'aux SID
gbn
sp_change_users_login ne met-il pas à jour le SID? msdn.microsoft.com/en-us/library/ms174378.aspx
SQLRockstar
5arx - il n'y a aucun moyen de le faire dans SSMS. Comme je l'ai dit, dans une situation idéale, vous auriez écrit vos autorisations avant la restauration. À ce stade, vous devez soit recréer à la main, soit essayer de reconstituer manuellement les éléments vous-même. si j'étais vous, je restaurerais l'ancienne base de données, je rédigerais les autorisations par script, je ferais la restauration à partir de l'autre serveur, puis je rétablirais vos autorisations.
SQLRockstar
"Update_One: relie l'utilisateur spécifié dans la base de données actuelle à une connexion SQL Server existante. L'utilisateur et la connexion doivent être spécifiés. Le mot de passe doit être NULL ou non spécifié." Il suppose donc que les connexions existent déjà.
gbn
0

Vous pouvez faire référence à l'URL suivante pour corriger les autorisations utilisateur de la base de données

http://mywindowsblog.com/?p=287

Prashant
la source