Como para configurar a segurança para SQL Server Iniciar envio

Traduções de Artigos Traduções de Artigos
Artigo: 321247 - Ver produtos para os quais este artigo se aplica.
Expandir tudo | Reduzir tudo

Nesta página

Sumário

Este artigo fornece informações sobre como configurar a segurança de envio do registo. Existem vários aspectos a considerar quando estiver a configurar segurança de envio nesse intervalo da conta de arranque para o SQL Server partilhar as permissões para a partilha de rede onde residem cópias de segurança da registo de transacções do registo do SQL Server. Estes problemas são descritos neste artigo.

Conta de arranque para o SQL Server e SQL Server Agent Services no registo de servidores de envio

Conta de domínio

Se tiver colocado o SQL Server num domínio, a Microsoft recomenda que utilize uma conta de domínio para iniciar serviços SQL Server. Se configurar o SQL Server para ser executado como um servidor virtual em Clustering do Windows tem de utilizar uma conta de domínio. Uma conta de domínio fornece a vantagem de manutenção mínima no caso de alterações de palavra-passe. No entanto, não poderá iniciar SQL sob uma conta de domínio se o SQL Server residir num servidor que está a ser um grupo de trabalho.

Conta de rede local

Pode utilizar o SQL Server para iniciar uma conta de rede criados localmente. Na situação onde não existe acesso de rede necessário por um processo do SQL Server, o que acontece se tiver configurado SQL Server para utilizar o envio do registo, pode utilizar a segurança da rede pass-through. Com a segurança pass-through, todos os computadores que serão acedidos pelo SQL Server tem de ter a conta de rede mesmo com a mesma palavra-passe e permissões apropriadas, configuradas localmente. Além disso, quando o processo de SQL Server pede recursos do segundo computador, segurança de rede tradicional é ignorada se a mesma conta (em que o serviço de SQL Server pedir é iniciado) existe com a mesma palavra-passe. Como longo a conta no segundo computador está configurada com permissão suficiente para executar a tarefa é solicitada pela chamada do SQL Server, a tarefa será efectuada com êxito.

Conta de sistema local

Pode também configurar o SQL Server para iniciar a conta sistema local. Modificar a palavra-passe da conta sistema local pode resultar numa falha de alguns serviços que são críticas para a estabilidade do sistema. Esta conta é local para o computador onde reside, que significa que o contexto de segurança que utiliza serviços do SQL Server é local. Como mencionado na secção de conta de rede local, pode utilizar rede pass-through segurança quando inicia o SQL Server sob a conta LocalSystem uma vez que as palavras-passe para a conta sistema local em computadores diferentes são diferentes. O início do SQL Server sob esta conta quando é necessário acesso de recursos de rede muito provavelmente resultar na conclusão das tarefas sem êxito.

Para obter informações sobre os direitos necessários mínimo para uma conta de rede para iniciar com êxito e executar serviços SQL Server e SQL Server Agent, consulte o seguinte tópico no SQL Server Books Online:
Setting up Windows Service Accounts

Noções sobre o modelo de segurança do SQL Server

Para compreender completamente as implicações de segurança, é importante compreender o modelo de segurança Microsoft implementou no SQL Server 2000. Quando criar um início de sessão, é adicionado à tabela syslogins a base de dados MASTER . Para cada base de dados que este início de sessão adicionado recentemente é fornecido acesso, é adicionada à tabela sysusers nessa base de dados. O mapeamento entre tabelas syslogins e sysusers é no campo SID.

Se uma base de dados do utilizador for movido para um servidor diferente, os valores de SID são transportados através do anterior servidor. Em segurança de base de dados interrompe quando inícios de sessão no segundo servidor não são criados com os mesmos valores de SID ou se a segurança está configurada incorrectamente devido a encontradas SID valores.

Para obter informações adicionais, clique no número de artigo existente abaixo para visualizar o artigo na base de dados de conhecimento da Microsoft:
240872INF: Como resolver problemas de permissões quando uma base de dados for movido

Configuração do registo de envio

Requisitos de segurança

partilha de cópia de segurança

Configure a partilha de rede que está configurada para armazenar cópias de segurança da registo transacções ter permissões de leitura/alteração para a conta em que o SQL Server serviços (no servidor secundário que esteja configurado para o registo de envio) são iniciados.

A partilha de rede que está configurada para armazenar cópias de segurança as registo de transacções, deverá estar configurado para que as permissões de leitura/alteração para a conta em que o SQL Server serviços, no servidor secundário configurado para registo de envio são iniciados. Esta partilha é acedida pelo trabalho de cópia no servidor secundário para copiar cópias de segurança da registo de transacções para a pasta local no respectivo servidor secundário. A tarefa de carga, em seguida, carrega estas cópias de segurança da pasta local.

cruz domínio registo envio

Se computadores com o SQL Server são colocados num ambiente com vários domínios, a Microsoft recomenda que configure fidedignidades bidireccionais entre todos os domínios envolvidos no envio do registo. No entanto, se não conseguir estabelecer fidedignidades entre domínios, pode utilizar segurança pass-through da rede para o registo de envio. Consulte a secção deste artigo descreve a opção de arranque do sistema local rede conta para serviços relacionados com o SQL Server.

Seleccionar modo de autenticação para ligar ao servidor de monitor

Pode seleccionar autenticação Windows ou autenticação de SQL (por servidores primário e secundários) para ligar ao servidor de monitor e para actualizar as tabelas de monitor. Pode seleccionar este quer durante a definição de registo de envio ou depois de ter configurado envio do registo e está funcional. Por predefinição, SQL Server utiliza a autenticação do Windows; no entanto, se seleccionar a autenticação de SQL, é criado um novo de início de sessão do SQL log_shipping_monitor_probe no primária, secundária, e servidores de monitor se não existir. Se seleccionar a autenticação de SQL para esta finalidade, configure SQL Server para utilizar a opção de autenticação SQL e do Windows .

Configuração da segurança no servidor secundário para bases de dados do modo de espera

Se configurar a base de dados secundária no modo de suspensão, pode aceder a esta base de dados no estado de só de leitura. Ao restaurar a base de dados secundária neste modo, este pode fornecer um meio pelo qual pretende executar relatórios offline, assim descarregar parte do trabalho do sistema de produção. No entanto, para a base de dados em modo de espera suportar a funcionalidade só de leitura, poderá ter de aplicar as mesmas definições de segurança no servidor secundário. Porque a base de dados está num estado inactivo, não é possível ainda efectuar quaisquer modificações para efeitos de configurar a segurança. Neste caso, terá de criar todos os inícios de sessão do SQL Server com os mesmos valores SID no servidor secundário. Inícios de sessão do Windows mantém automaticamente os SID mesmo porque o GUID do Windows é globalmente exclusivo, mesmo quando utilizar vários domínios.

Para obter informações adicionais sobre como criar os inícios de sessão SQL com o mesmo SID em servidores diferentes, clique no número de artigo que se segue para visualizar o artigo na Microsoft Knowledge Base:
303722Como conceder acesso para inícios de sessão de SQL num modo de espera da base de dados quando "convidado" utilizador está desactivado

Configuração da segurança quando efectuar a alteração de função

O procedimento de alteração de função para envio do registo envolve promover um servidor secundário a assumir como principal. Pode fazê-lo com ou sem o servidor primário a ser online. Como parte da alteração de função, existem até quatro procedimentos armazenados que são executados. Um desses procedimentos armazenados, sp_resolve_logins , ajuda a corrigir os valores de SID para inícios de sessão que residem na base de dados em modo de espera antes que é disponibilizado para utilizar como base de dados principal.

Como parte deste procedimento armazenado, um ficheiro .BCP da tabela syslogins a partir do antigo servidor principal é carregado para uma tabela temporária. Em seguida, é comparado com cada início de sessão que está presente nesta tabela temporária para a tabela syslogins na base de dados MASTER do servidor secundário e tabela de base de dados secundária sysusers. Para cada início de sessão na tabela temporária que tem um início de sessão com o mesmo nome na tabela syslogins e mesmo SID que na tabela sysusers da base de dados secundária, o SID é corrigido (na base de dados secundária) utilizando sp_change_users_login para corresponder a um que esteja na tabela syslogins.

Configuração de segurança utilizando este procedimento requer o seguinte:
  • Inícios de sessão SQL tem de ser já criados no servidor secundário. Para o fazer, utilize a tarefa de transferência DTS inícios de sessão (que é explicado no SQL Server Books Online tópico, "Como configurar e efectuar o envio de alteração de função do registo."
  • Tem de fornecer um ficheiro .BCP a tabela syslogins o servidor primário. Este ficheiro tem de ser actual porque um ficheiro desactualizado poderá resultar na sp_resolve_logins falhar corrigir os inícios de sessão.
Tem de cumprir as seguintes três condições antes de sp_resolve_logins , na realidade, pode corrigir os inícios de sessão na base de dados secundário:
  1. O nome de início de sessão do ficheiro .BCP da tabela syslogins deve corresponder ao nome da tabela syslogins do servidor principal.
  2. O valor de SID tem de corresponder entre o início de sessão o ficheiro .BCP e a tabela sysusers na base de dados secundário
  3. O valor de SID da base de dados secundário tem de ser diferente do valor de SID na tabela syslogins na base de dados MASTER no servidor secundário.
Se criar inícios de sessão do SQL Server conforme descrito em Q303722, não é necessário que executar este procedimento armazenado, uma vez que todos os inícios de sessão são já existir com o mesmo valor SID na tabela syslogins (na base de dados MASTER no servidor secundário) e a tabela sysusers (base de dados secundária).

Perguntas mais frequentes

pergunta : É registo envio propagar alterações relacionadas com segurança a um servidor secundário automaticamente?

resposta : Sim. Uma vez que todas as alterações às tabelas de sistema são operações registadas, estes são propagadas através de para o servidor secundário (ou servidores) automaticamente.

pergunta : pode tem dois inícios de sessão no secundário servidor com o SID mesmo? Tem esta vez que Estou a utilizar o mesmo computador SQL Server para manter várias bases de dados em modo de espera de múltiplos servidores.

resposta : ' não '. Modelo de segurança do SQL Server não permite ter duas inícios de sessão com o SID do mesmo. Se existir um conflito no SID ao utilizar o registo de envio com vários servidores, a única forma para corrigir este problema é cancelar o início de sessão em conflito no servidor principal e, em seguida, criá-la com um SID que não existe no servidor secundário.
Para obter informações adicionais sobre envio alteração de função do registo, clique no número de artigo existente abaixo para visualizar o artigo na base de dados de conhecimento da Microsoft:
314515INF: Frequently Asked Questions - SQL Server 2000 - registo de envio

Propriedades

Artigo: 321247 - Última revisão: 21 de dezembro de 2005 - Revisão: 3.5
A informação contida neste artigo aplica-se a:
  • Microsoft SQL Server 2000 Standard Edition
  • Microsoft SQL Server 2000 64-bit Edition
  • Microsoft SQL Server 2005 Standard Edition
  • Microsoft SQL Server 2005 Developer Edition
  • Microsoft SQL 2005 Server Enterprise
  • Microsoft SQL 2005 Server Workgroup
Palavras-chave: 
kbmt kbhowtomaster KB321247 KbMtpt
Tradução automática
IMPORTANTE: Este artigo foi traduzido por um sistema de tradução automática (também designado por Machine translation ou MT), não tendo sido portanto revisto ou traduzido por humanos. A Microsoft tem artigos traduzidos por aplicações (MT) e artigos traduzidos por tradutores profissionais. O objectivo é simples: oferecer em Português a totalidade dos artigos existentes na base de dados do suporte. Sabemos no entanto que a tradução automática não é sempre perfeita. Esta pode conter erros de vocabulário, sintaxe ou gramática? erros semelhantes aos que um estrangeiro realiza ao falar em Português. A Microsoft não é responsável por incoerências, erros ou estragos realizados na sequência da utilização dos artigos MT por parte dos nossos clientes. A Microsoft realiza actualizações frequentes ao software de tradução automática (MT). Obrigado.
Clique aqui para ver a versão em Inglês deste artigo: 321247

Submeter comentários

 

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