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

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:

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:

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:

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

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: