Comment faire pour configurer la sécurité pour SQL Server Envoi de journaux

Traductions disponibles Traductions disponibles
Numéro d'article: 321247 - Voir les produits auxquels s'applique cet article
Agrandir tout | Réduire tout

Sommaire

Résumé

Cet article fournit des informations sur la façon de configurer sécurité pour l'envoi de journaux. Il existe plusieurs problèmes à prendre en considération lors vous configurez la sécurité pour le journal de SQL Server cette plage de livraison du compte de démarrage pour SQL Server pour partager des autorisations pour le partage réseau sur lequel résident les sauvegardes de journaux de transaction. Ces problèmes décrites dans cet article.

Compte de démarrage pour SQL Server et SQL Server Agent Services dans journal de serveurs de transport

Compte de domaine

Si vous avez sélectionné SQL Server dans un domaine, Microsoft vous recommande d'utiliser un compte de domaine pour démarrer les services SQL Server. Vous devez utiliser un compte de domaine si vous prévoyez pour configurer SQL Server pour s'exécuter comme un serveur virtuel sous le clustering Windows. Un compte de domaine offre l'avantage de maintenance minimale en cas de modifications de mot de passe. Toutefois, vous ne peut-être en mesure de démarrer SQL sous un compte de domaine si SQL Server réside sur un serveur qui se trouve dans un groupe de travail.

Compte de réseau local

Vous pouvez utiliser SQL Server pour démarrer sous un compte réseau créé localement. Dans le cas où il est Accès réseau requis par un processus SQL Server, qui est le cas si vous avez configuré SQL Server pour utiliser l'envoi de journaux, vous pouvez utiliser la sécurité réseau directe. Avec la sécurité SQL directe, tous les ordinateurs qui sont accessible par SQL Server doivent disposer le même compte de réseau avec le même mot de passe et les autorisations appropriées, configurées localement. En outre, lorsque le processus SQL Server demande ressources de l'ordinateur deuxième, la sécurité réseau traditionnel est contournée si le même compte (sous lequel le service SQL Server demandeur est démarré) existe avec le même mot de passe. Durée le compte sur le deuxième ordinateur est configuré suffisamment autorisé à exécuter la tâche est demandée par l'appel de SQL Server, la tâche sera réussie.

Compte système local

Vous pouvez également configurer SQL Server pour démarrer sous le compte système local. Modifier le mot de passe pour le compte LocalSystem peut entraîner l'échec de certains services qui sont critiques pour la stabilité du système. Ce compte est local à l'ordinateur où elle réside, ce qui signifie que le contexte de sécurité qui utilise des services SQL Server est local. Comme indiqué dans la section compte réseau local, vous ne pouvez pas utiliser la sécurité réseau directe lorsque vous démarrez SQL Server sous le compte LocalSystem, car les mots de passe pour le compte LocalSystem sur différents ordinateurs sont différentes. Début de SQL Server sous ce compte lorsque l'accès aux ressources réseau est requise probablement entraînera l'échec achèvement de tâches.

Pour d'informations sur les droits minimales requis pour un compte réseau pour correctement démarrer et exécuter les services SQL Server et SQL Server Agent, consultez la rubrique suivante dans la documentation en ligne de SQL Server :
Setting up Windows Service Accounts

Comprendre le modèle de sécurité SQL Server

Pour comprendre entièrement les implications de sécurité, il est important de comprendre le modèle de sécurité sur lequel Microsoft a implémenté dans SQL Server 2000. Lorsque vous créez une connexion, il est ajouté à la table syslogins dans la base de données MASTER . Pour chaque base de données cette connexion venez d'ajouter est fournie aux, il est ajouté à la table sysusers de cette base de données. Le mappage entre table de syslogins et la table sysusers est sur le champ SID.

Si une base de données utilisateur est déplacé vers un autre serveur, les valeurs SID sont étendent à partir du serveur précédent. Soit sécurité de base de données sauts lorsque ouvertures de session sur le second serveur ne sont pas créés avec les mêmes valeurs de SID ou si la sécurité est mal configurée d'en raison de pas de valeurs SID.

Pour plus d'informations, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
240872 Fichier INF: Comment faire pour résoudre les problèmes d'autorisation lorsqu'une base de données est déplacée

Configuration de journal livraison

Configuration de sécurité

partage de sauvegarde

Configurer le partage réseau qui est configuré pour stocker les sauvegardes du journal transaction pour que les autorisations read/change pour le compte sous les SQL Server services (sur le serveur secondaire qui est configuré pour l'envoi de journaux) démarrage.

Le partage réseau qui est configuré pour stocker les sauvegardes de journal des transactions, doit être configuré pour que les autorisations read/change pour le compte sous les SQL Server services, sur le serveur secondaire configuré pour log-shipping, démarrage. Ce partage est accessible par le travail de copie sur le serveur secondaire pour copier les sauvegardes de journaux de transaction dans le dossier local sur le serveur secondaire respectif. La charge de travail charge ensuite ces sauvegardes à partir du dossier local.

croix domaine journal livraison

Si ordinateurs qui exécutent SQL Server sont placés dans un environnement multi-domaine, Microsoft vous recommande de définir des approbations bidirectionnelles entre tous les domaines qui sont impliqués dans l'envoi de journaux. Toutefois, si vous ne peut pas établir des approbations entre domaines, vous pouvez utiliser la sécurité réseau directe pour l'envoi de journaux. Reportez-vous à la section de cet article décrit l'option de démarrage système local réseau compte pour les services liés à SQL Server.

Sélectionner le mode d'authentification pour se connecter au serveur de moniteur

Vous pouvez sélectionner l'authentification Windows ou l'authentification SQL (par les serveurs principales et secondaires) pour vous connecter au serveur de surveillance et mettre à jour les tables de moniteur. Vous pouvez sélectionner ce soit lors de la paramètre jusqu'à l'envoi de journaux ou une fois que vous avez défini jusqu'à l'envoi de journaux et elle est opérationnelle. Par défaut, SQL Server utilise l'authentification Windows ; Toutefois, si vous sélectionnez l'authentification SQL, une nouvelle de connexion SQL log_shipping_monitor_probe est créée sur le principal, secondaire, et serveurs moniteur s'il n'existe pas. Si vous sélectionnez l'authentification SQL pour cela, configurez SQL Server pour utiliser l'option d'authentification SQL et Windows .

Configuration de sécurité sur le serveur secondaire de bases de données en attente

Si vous configurez la base de données secondaire en mode veille, vous pouvez accéder à cette base de données en état de lecture seule. En restaurant la base de données secondaire dans ce mode, ce peut fournir un moyen utilisé générer des états en mode hors connexion, ainsi le déchargement du travail à partir du système de production. Toutefois, pour la base de données en attente prendre en charge la fonctionnalité en lecture seule, vous devrez peut-être appliquer les mêmes paramètres de sécurité sur le serveur secondaire. Car la base de données est dans état de veille, vous ne pouvez pas même créer toutes les modifications pour les besoins de configuration de sécurité. Dans ce cas, vous devez créer tous les logins SQL Server avec les mêmes valeurs de SID sur le serveur secondaire. Logins Windows conservent automatiquement le même SID car le GUID de Windows est globalement unique, même si vous utilisez plusieurs domaines.

Pour plus d'informations sur comment créer les logins SQL avec le même SID sur différents serveurs, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
303722 Comment faire pour accorder l'accès pour les connexions SQL sur une base de données du mise en veille lorsque "Invité" utilisateur est désactivé

Configuration de sécurité lors de l'exécution change de rôle

La procédure de modification de rôles pour l'envoi de journaux implique la promotion d'un serveur secondaire pour prendre le contrôle comme principal. Vous pouvez le faire avec ou sans le serveur principal en cours en ligne. Dans le cadre de la modification de rôle, il existe jusqu'à quatre procédures stockées qui sont exécutées. Une de ces procédures stockées, sp_resolve_logins , permet de corriger les valeurs SID de connexions qui résident dans la base de données en attente juste avant qu'il est rendu disponible pour servir de la base de données principale.

Dans le cadre de cette procédure stockée, un fichier .BCP de la table syslogins à partir du ancien serveur principal est chargé dans une table temporaire. Chaque ouverture de session qui est présent dans cette table temporaire est ensuite comparée à la table syslogins dans la base de données MASTER du serveur secondaire et la table sysusers de la base de données secondaire. Pour chaque connexion de la table temporaire qui a une connexion avec le même nom dans la table de syslogins et le même SID que celui de la table sysusers de la base de données secondaire, le SID a été corrigé (dans la base de données secondaire) à l'aide de sp_change_users_login pour correspond à celui qui se trouve dans la table syslogins.

Configuration de sécurité à l'aide de cette procédure stockée requiert les conditions suivantes :
  • Ouvertures de session SQL doivent déjà être créés sur le serveur secondaire. Pour cela, utilisez la tâche de transfert DTS de connexions (qui est expliqué dans la documentation en ligne de SQL Server rubrique, « How to paramétrer et exécuter journal modification du rôle de livraison.
  • Vous devez fournir un fichier .BCP de la table syslogins à partir du serveur principal. Ce fichier doit être en cours car un fichier obsolète peut entraîner sp_resolve_logins Échec de résoudre les noms d'accès.
Vous devez répondre à trois conditions suivantes avant de le sp_resolve_logins peut en fait résoudre les noms d'accès dans la base de données secondaire :
  1. Le nom de session à partir du fichier .BCP de la table syslogins doit correspondre au nom de la table syslogins à partir du serveur principal.
  2. La valeur SID doit correspondre à entre l'ouverture de session le fichier .BCP et de la table sysusers de la base de données secondaire
  3. La valeur du SID de la base de données secondaire doit être différente de la valeur SID dans la table syslogins dans la base de données MASTER sur le serveur secondaire.
Si vous créez logins SQL Server comme décrit dans Q303722, il n'est exécuter cette procédure stockée car toutes les connexions sont déjà être présent avec la même valeur SID dans la table de syslogins (dans la base de données MASTER sur le serveur secondaire) et la table sysusers (dans la base de données secondaire).

Forum aux questions

question : l'envoi de journaux propager liées à la sécurité modifications vers un serveur secondaire automatiquement ?

réponse : Oui. Étant donné que toutes les modifications apportées aux tables système sont consignées les opérations, elles sont répercutées via dans le ou les serveurs secondaires automatiquement.

question : pouvez vous avez deux ouvertures de session sur le secondaire serveur avec le même SID ? J'AI devez cela car j'utilise le même ordinateur SQL Server pour gérer plusieurs bases de données en attente à partir de plusieurs serveurs.

réponse : non. Modèle de sécurité SQL Server ne permet pas avoir deux connexions avec le même SID. S'il existe un conflit sur SID lors de l'utilisation avec plusieurs serveurs l'envoi de journaux, la seule pour corriger ce problème consiste à déposer la connexion en conflit sur le serveur principal, puis sur la création par un SID qui n'existe pas sur le serveur secondaire.
Pour plus d'informations sur la modification du rôle d'envoi de journaux, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances :
314515 Fichier INF: Forum aux questions - SQL Server 2000 - journal livraison

Propriétés

Numéro d'article: 321247 - Dernière mise à jour: mercredi 21 décembre 2005 - Version: 3.5
Les informations contenues dans cet article s'appliquent au(x) produit(s) suivant(s):
  • Microsoft SQL Server 2000 Standard
  • Microsoft SQL Server 2000 Édition 64 bits
  • Microsoft SQL Server 2005 Standard Edition
  • Microsoft SQL Server 2005 Developer Edition
  • Microsoft SQL Server 2005 Enterprise Edition
  • Microsoft SQL Server 2005 Workgroup Edition
Mots-clés : 
kbmt kbhowtomaster KB321247 KbMtfr
Traduction automatique
IMPORTANT : Cet article est issu du système de traduction automatique mis au point par Microsoft (http://support.microsoft.com/gp/mtdetails). Un certain nombre d?articles obtenus par traduction automatique sont en effet mis à votre disposition en complément des articles traduits en langue française par des traducteurs professionnels. Cela vous permet d?avoir accès, dans votre propre langue, à l?ensemble des articles de la base de connaissances rédigés originellement en langue anglaise. Les articles traduits automatiquement ne sont pas toujours parfaits et peuvent comporter des erreurs de vocabulaire, de syntaxe ou de grammaire (probablement semblables aux erreurs que ferait une personne étrangère s?exprimant dans votre langue !). Néanmoins, mis à part ces imperfections, ces articles devraient suffire à vous orienter et à vous aider à résoudre votre problème. Microsoft s?efforce aussi continuellement de faire évoluer son système de traduction automatique.
La version anglaise de cet article est la suivante: 321247
L'INFORMATION CONTENUE DANS CE DOCUMENT EST FOURNIE PAR MICROSOFT SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE. L'UTILISATEUR ASSUME LE RISQUE DE L'UTILISATION DU CONTENU DE CE DOCUMENT. CE DOCUMENT NE PEUT ETRE REVENDU OU CEDE EN ECHANGE D'UN QUELCONQUE PROFIT.

Envoyer des commentaires

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com