Bienvenue à Blogs CodeS-SourceS Identification | Inscription | Aide

SQL Server : Copier les logins avant une sauvegarde, un déplacement de base, une migration, etc.

SQL Server possède une particularité, celle de séparer la sécurité des bases de données de celle du serveur. Le serveur dispose en effet de comptes appelés « login » ou « connexion » permettant l’authentification auprès de celui-ci. La base de données possède quant à elle des comptes appelés « user » ou « utilisateur ».

Un utilisateur se trouve généralement mappé à une connexion, permettant ainsi à se dernier de pouvoir accéder à la base de données avec les droits de l’utilisateur. Mais pas toujours, lorsque par exemple vous copier la base de données sur un autre serveur, ses utilisateurs de retrouvent orphelins.

C’est en fait un comportement souhaité pour éviter des failles de sécurité. En effet toute personne ayant les droits de restaurer une base et/ou de créer des connexions au niveau du serveur se retrouverait implicitement avec des droits dans la base ajoutée au serveur. C’est aussi pour cette raison qu’un utilisateur d’une base X nommé Y n’est pas considéré identique par le moteur que l’utilisateur Y de la base Z. Bien que portant le même nom ils sont différent car dans 2 bases de données différentes (en tout cas ce comportement est celui par défaut depuis SQL Server 2000 SP3).

Pour pouvoir ré-associer les connexions / utilisateurs il existe une astuce qui permet de créer les connexions avec le même identifiant interne. On créée une procédure stockée appelé sp_help_revlogin qui génère un script qui nous servira à dupliquer les fameux comptes de connexion au serveur.

Si vous copiez les Logins de SQL 7, 2000 vers SQL 7, 2000, 2005, il vous faudra cette version :
http://support.microsoft.com/kb/246133

Pour une copie à partir de SQL 2005 vers SQL 2005, ce sera celle-ci :
http://support.microsoft.com/kb/918992

On exécute alors sur le serveur depuis lequel on va copier les logins :

EXEC sp_help_revlogin

On copie le script ainsi obtenu que l’on exécute sur l’autre serveur. Pensez au besoin à aller dans les options de l’analyseur de requêtes ou de Management Studio pour l’empêcher de tronquer les lignes de texte.

Le script ainsi obtenu peut idéalement se conserver avec les sauvegardes des bases, il vous sera très utile en cas de restauration de celles-ci sur un nouveau serveur.

Bonne copie…

Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :
Publié vendredi 22 juin 2007 22:56 par christian
Classé sous : ,

Commentaires

Pas de commentaires
Les commentaires anonymes sont désactivés

Les 10 derniers blogs postés

- Emportez votre sélection de la MSDN dans la poche ? par Blog de Jérémy Jeanson le il y a 16 heures et 46 minutes

- [ #Office365 ] Pb de connexion du flux Yammer ajouté à un site SharePoint par Le blog de Patrick [MVP SharePoint] le il y a 22 heures et 8 minutes

- NFluent & Data Annotations : coder ses propres assertions par Fathi Bellahcene le il y a 22 heures et 16 minutes

- Installer un site ASP.net 32bits sur un serveur exécutant SharePoint 2013 par Blog de Jérémy Jeanson le 04-17-2014, 06:34

- [ SharePoint Summit 2014 ] Tests de montée en charge SharePoint par Le blog de Patrick [MVP SharePoint] le 04-16-2014, 20:44

- [ SharePoint Summit 2014 ] Bâtir un site web public avec Office 365 par Le blog de Patrick [MVP SharePoint] le 04-16-2014, 18:30

- Kinect + Speech Recognition + Eedomus = Dommy par Aurélien GALTIER le 04-16-2014, 17:17

- [ SharePoint Summit 2014 ] Une méthodologie simple pour concevoir vos applications OOTB SharePoint de A à Z par Le blog de Patrick [MVP SharePoint] le 04-16-2014, 16:51

- //Lean/ - Apprendre à faire des Apps Windows universelles par Blog de Jérémy Jeanson le 04-16-2014, 12:57

- Une culture de la donnée pour tous… par Le blog de Patrick [MVP SharePoint] le 04-16-2014, 11:00