Vous êtes actuellement hors ligne, en attente de reconnexion à Internet.

Comment faire pour résoudre les problèmes d'autorisation lorsque vous déplacez une base de données entre des serveurs SQL Server

Cet article peut contenir des liens vers des informations en langue anglaise (pas encore traduites).
Résumé
Cet article explique comment mapper les noms d'accès standard et intégrés pour résoudre les problèmes d'autorisation lorsque vous déplacez une base de données entre des serveurs SQL Server.
Plus d'informations
Lorsque vous déplacez une base de données d'un serveur SQL Server vers un autre serveur SQL Server, une incompatibilité peut survenir entre les numéros d'identification de sécurité (SID) des noms d'accès de la base de données principale et les utilisateurs de la base de données d'utilisateurs. Par défaut, SQL Server 7.0, SQL Server 2000 et SQL Server 2005 fournissent la procédure stockée système sp_change_users_login pour mapper ces utilisateurs qui ne concordent pas. Toutefois, vous pouvez uniquement utiliser la procédure stockée sp_change_users_login pour mapper les noms d'accès SQL Server standard et vous devez effectuer ces mappages pour un utilisateur à la fois. Pour plus d'informations sur la procédure stockée sp_change_users_login, reportez-vous à la rubrique « sp_change_users_login » de la documentation en ligne de SQL Server 7.0, SQL Server 2000 et SQL Server 2005.

Dans SQL Server 7.0 ou version ultérieure, vous pouvez conserver le mappage entre les noms d'accès de la base de données principale et les utilisateurs de la base de données d'utilisateurs à l'aide des SID. Ce mappage est nécessaire pour conserver les autorisations correctes pour les noms d'accès des bases de données d'utilisateurs. Lorsque ce mappage est perdu, les noms d'accès ont les problèmes d'autorisations suivants (mais sans limitation) :
  • Si le nom d'accès SQL Server n'existe pas sur le nouveau serveur et que l'utilisateur essaie d'ouvrir une session, le message d'erreur suivant peut s'afficher :
    Serveur : Msg 18456, Niveau 16, État 1
    Échec de la connexion de l'utilisateur "%ls".
  • Si le nom d'accès SQL Server existe sur le nouveau serveur, mais que le SID de la base de données principale diffère de celui de la base de données d'utilisateurs, l'utilisateur peut ouvrir une session sur SQL Server ; toutefois, lorsqu'il essaie d'accéder à cette base de données, le message d'erreur suivant peut s'afficher :
    Serveur : Msg 916, Niveau 14, État 1, Ligne 1
    L'utilisateur du serveur "%.*ls" n'est pas valide pour la base de données "%.*ls".
    Remarque Dans SQL Server 2005, le message d'erreur suivant peut s'afficher :

    L'utilisateur du serveur '%s' n'est pas valide pour la base de données '%s'. Ajoutez d'abord le compte utilisateur ou le compte utilisateur « invité » dans la base de données.
Pour plus d'informations sur le modèle de sécurité SQL Server 7.0, reportez-vous au livre blanc « Microsoft SQL Server 7.0 Security » (en anglais uniquement). Pour afficher ce livre blanc, reportez-vous au site Web de Microsoft à l'adresse suivante (en anglais) :Pour plus d'informations sur le modèle de sécurité de SQL Server 2000, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft.
322712 Fonctionnalités de sécurité de Microsoft SQL Server 2000 et méthodes conseillées

Restrictions

  • Si certains utilisateurs du tableau sysusers ne disposent pas du préfixe du nom d'ordinateur ou du nom de domaine qui possède des objets et que ces objets sont référencés dans les applications à l'aide du nom à deux parties nom_utilisateur.nom_objet, l'application peut s'interrompre parce que la procédure stockée sp_sidmap renomme ces utilisateurs avec le préfixe du nom d'ordinateur ou du nom de domaine comme il apparaît dans le tableau sysxlogins. Pour contourner ce problème, une fois la procédure stockée sp_sidmap terminée, renommez les utilisateurs qui ont été affectés, dans le tableau sysusers, avec leur ancien nom ou contactez votre fournisseur principal de support technique.
  • Cet article ne prend pas en compte les alias. Vous devez gérer les alias manuellement.
  • Si un nom d'accès SQL Server standard n'existe pas sur le nouveau serveur SQL Server, vous pouvez l'ajouter avec un mot de passe NULL. Il est possible que vous ayez à modifier le mot de passe pour ces noms d'accès en conséquence.
  • Si un utilisateur a été créé dans la base de données d'utilisateurs avec un nom différent de celui qui apparaît dans le tableau sysxlogins, il est impossible de connaître le nom d'accès correspondant pour cet utilisateur. Par conséquent, avant d'exécuter la procédure stockée sp_sidmap, procédez comme suit :
    1. Transférez tous les objets que cet utilisateur possède vers une base de données intermédiaire.
    2. Effacez l'utilisateur, rajoutez-le avec le nom correct, puis retransférez tous les objets pour cet utilisateur.
  • Si un utilisateur n'a ni nom d'accès correspondant, ni préfixe du nom d'ordinateur local ou du nom de domaine, un message s'affiche pour cet utilisateur. Ce message indique que vous devez d'abord ajouter l'utilisateur au niveau de Windows, puis l'ajouter au niveau de SQL Server en tant que nom d'accès. Après cela, vous devez réexécuter la procédure stockée sp_sidmap.
  • Si un utilisateur dispose d'un préfixe du nom de domaine ou du nom de serveur Windows local, mais que le nom d'accès correspondant n'existe pas dans le tableau sysxlogins, la procédure stockée essaie de l'ajouter comme nouveau nom d'accès à SQL Server. Si l'utilisateur Windows n'existe pas, la procédure génère un message de sortie dans la fenêtre des résultats, puis elle crée manuellement le nom d'accès après avoir ajouté l'utilisateur Windows.
  • S'il existe plusieurs noms d'accès pour un utilisateur dans le tableau sysusers, un message de sortie s'affiche dans le fichier de résultats et tous les noms d'accès présentant le même nom_utilisateur sont répertoriés. À ce stade, vous devez intervenir manuellement pour vous assurer que l'utilisateur correspond à un seul nom d'accès.

    Exemple Si le tableau sysusers contient un utilisateur nommé « johndoe » et que le tableau sysxlogins contient des noms d'accès tels que « Test\johndoe » et « Test2\johndoe », lorsque vous exécutez la procédure stockée, un message s'affiche pour signaler que l'un des utilisateurs dispose de plusieurs noms d'accès et que l'Administrateur système doit en choisir un. Ce sera alors la seule fois où vous aurez à exécuter la seconde procédure stockée, sp_prefix_sysusersname, qui est fournie dans cet article. En outre, cette situation est décrite en détail dans le fichier Lisezmoi.txt.

Mappage des noms d'accès standard et intégrés

Après avoir déplacé une base de données d'un serveur SQL Server vers un autre serveur SQL Server, procédez comme suit pour une intervention minime de la part de l'utilisateur :
  1. Assurez-vous qu'il existe un nom d'accès dans le tableau sysxlogins de la base de données principale pour chaque utilisateur du tableau sysusers de la base de données.

    Remarque Pour ajouter un nom d'accès SQL Server standard, reportez-vous à la rubrique « sp_addlogin » de la documentation en ligne de SQL Server. Pour ajouter un nom d'accès SQL Server intégré, reportez-vous à la rubrique « sp_grantlogin » de la documentation en ligne de SQL Server.
  2. Téléchargez le fichier MapSids.exe, puis extrayez les fichiers Sp_sidmap.sql et Lisezmoi.txt.
  3. Ouvrez une session sur le serveur SQL Server en tant qu'administrateur système, puis exécutez le fichier Sp_sidmap.sql dans la base de données d'utilisateurs. L'exécution du fichier Sp_sidmap.sql crée les deux procédures stockées, sp_sidmap et sp_prefix_sysusersname.
  4. Assurez-vous qu'aucun utilisateur autre que celui qui exécute les procédures stockées n'accède à la base de données.
  5. Assurez-vous que l'Analyseur de requêtes affiche les résultats au format texte et pas sous forme de grille. Pour cela, appuyez sur les touches CTRL+T ou cliquez sur Requête, puis sur Résultats en texte. Ceci est très important pour que vous puissiez afficher les résultats et les messages informationnels dans une fenêtre et enregistrer la sortie vers un fichier texte. Vous pourrez avoir besoin de ce fichier ultérieurement pour résoudre certains mappages.
  6. Étant donné qu'il est impossible de vérifier si les paramètres sont correctement transférés, assurez-vous de les transférer correctement à la procédure stockée sp_sidmap :
    EXEC sp_SidMap @old_domain = old_domain_name,@new_domain = new_domain_name,@old_server = old_server_name,@new_server = new_server_name
    Remplacez les valeurs pour les anciens et nouveaux noms de domaine et noms de serveur de façon appropriée.
  7. Enregistrez les résultats dans un fichier, puis suivez les instructions fournies dans le fichier Lisezmoi.txt.

    Remarque Lorsque vous exécutez ces procédures stockées, le tableau sysusers est le seul tableau qui change dans la base de données. Pour revenir à un état auquel vous avez démarré, restaurez la base de données à partir de la sauvegarde ou rattachez la base de données.
Références
Pour plus d'informations, cliquez sur les numéros ci-dessous pour afficher les articles correspondants dans la Base de connaissances Microsoft.
274188 La rubrique « Dépannage des utilisateurs orphelins » de la documentation en ligne est incomplète
246133 Comment faire pour transférer des noms d'accès et des mots de passe entre instances de SQL Server
168001 Erreurs d'ouverture de session d'utilisateur et/ou d'autorisation après restauration d'une image mémoire
298897 EXEMPLE : Mapsids.exe aide à mapper les SID entre les bases de données d'utilisateurs et master lorsque la base de données est déplacée
Propriétés

ID d'article : 240872 - Dernière mise à jour : 05/15/2011 07:33:00 - Révision : 8.0

Microsoft SQL Server 2000 Standard, Microsoft SQL Server 2000 Édition 64 bits, Microsoft SQL Server 7.0 Standard, Microsoft SQL Server 2005 Developer Edition, Microsoft SQL Server 2005 Enterprise Edition, Microsoft SQL Server 2005 Express Edition, Microsoft SQL Server 2005 Standard Edition, Microsoft SQL Server 2005 Workgroup Edition

  • kbsqlserverengine kbhowtomaster KB240872
Commentaires
=">")[0].appendChild(m);