Recebe uma "Info de SuperSocket de aviso" de informações de aviso quando uma conta de serviço do SQL Server é um utilizador de domínio

Traduções de Artigos Traduções de Artigos
Artigo: 303411 - Ver produtos para os quais este artigo se aplica.
BUGS #: 232774 (SHILOH_BUGS)
Expandir tudo | Reduzir tudo

Sintomas

Quando o SQL Server é iniciado num computador que está a ser executado Microsoft SQL Server 2000 ou Microsoft SQL Server 2005, o programa do SQL Server tenta sempre registar o servidor virtual no Active Directory. O seguinte evento poderá ser registado no registo de eventos:

SuperSocket info: (SpnRegister): erro 8344 SuperSocket Info: (SPNRegister): informações de erro 1355 SuperSocket: SpnUnRegister(): erro 8344.

NotaErro 1355 é igual a ERROR_NO_SUCH_DOMAIN. Erro 8344 é igual a permissões insuficientes para executar a operação de registo. Isto é mostrado como um aviso para a função de SPNRegister e como um erro para a função SpnUnRegister .

Esta mensagem não é uma mensagem de erro. Este texto é apenas um Aviso de que o SQL Server não é possível registar um nome principal do serviço (SPN). Isto indica que é o mecanismo de segurança que será utilizado Autenticação do Microsoft Windows NT Challenge\Response (NTLM) em vez de Autenticação Kerberos.

Estas mensagens só devem ser consideradas um problema se a instalação do SQL Server requer a autenticação Kerberos ou as definições de segurança de rede impedirem regressar a negociação de NTLM. Caso contrário, estas mensagens podem ser ignoradas com segurança.

Causa

Normalmente, aparece a mensagem porque o serviço SQL Server conta está a funcionar como um utilizador de domínio que não tem permissões necessárias para Registe SPN. Com o Microsoft Windows 2000 Service Pack 3 (SP3), pode activar Autenticação Kerberos em clusters de servidor. Para obter instruções sobre como fazê-lo, consulte o seguinte artigo na Microsoft Knowledge Base:
319723 Informações sobre Kerberos do SQL Server 2000 suporta, incluindo servidores virtuais do SQL Server em clusters de servidor

Resolução

Também pode editar permissões de definições de controlo de acesso da conta no serviço de directório do Active Directory para activar a permissão de servicePrincipalName de leitura e a permissão de escrita servicePrincipalName da conta de serviço do SQL.

Aviso Se utilizar o snap-in do Active Directory Service Interfaces (ADSI) edição, o utilitário LDP ou quaisquer outros clientes LDAP versão 3 e modificar incorrectamente os atributos de objectos do Active Directory, pode provocar problemas graves. Estes problemas podem obrigar à reinstalação do Microsoft Windows 2000 Server, Microsoft Windows Server 2003, Microsoft Exchange 2000 Server, Microsoft Exchange Server 2003, ou o Windows e Exchange. A Microsoft não garante que os problemas causados por modificar incorrectamente os atributos de objecto do Active Directory possam ser resolvidos. Modificar estes atributos na sua conta e risco.

Como contornar

Para resolver estas mensagens de tipo e activar o serviço SQL Server criar SPNs dinamicamente para as instâncias do SQL Server, peça ao administrador de domínio para adicionar as permissões adequadas e direitos de utilizador para as contas de arranque do SQL Server.

Para activar a conta do serviço SQL Server estabelecer os SPNs correctamente no arranque, siga estes passos:
  1. Clique em Iniciar, clique em Executar, tipo Adsiedit. msce, em seguida, clique em OK.
  2. No Editor de ADSI janela, expanda Domínio [Nome de domínio], expanda DC = RootDomainName, expanda CN = utilizadores, com o botão direito CN =AccountNamee, em seguida, clique em Propriedades.

    Notas
    • Nome de domínio representa o nome do domínio.
    • RootDomainName é um marcador de posição para o nome do domínio raiz.
    • AccountName representa a conta que especificar para iniciar o serviço SQL Server.
    • Se tiver especificado o Sistema Local para iniciar o serviço SQL Server, AccountName representa a conta que utilizar para iniciar sessão no Microsoft Windows.
    • Se tiver especificado uma conta de utilizador de domínio para o serviço SQL Server, AccountName representa a conta de utilizador de domínio.
  3. No CN =AccountName Propriedades caixa de diálogo, faça clique sobre o Segurança separador.
  4. Sobre o Segurança Clique em Avançadas.
  5. No Definições avançadas de segurança diálogo caixa, certifique-se de que o utilizador SELF está listado em Entradas de permissão. Se o utilizador SELF não estiver listado, clique em Adicionar, e, em seguida, adicione o utilizador SELF .
  6. Em Entradas de permissão, clique em SELFe, em seguida, clique em Editar.
  7. No Entrada de permissão caixa de diálogo, faça clique sobre o Propriedades separador.
  8. Sobre o Propriedades Clique em Este objecto apenas no Aplicar em lista e, em seguida, certifique-se de que as seguintes permissões estão seleccionadas em Permissões:
    • Ler servicePrincipalName
    • Escrever servicePrincipalName
  9. Clique em OK três vezes e, em seguida, feche o Editor de ADSI janela.
Para obter ajuda com este processo, contacte o suporte de produto do Active Directory. Consulte este artigo da Base de dados de conhecimento da Microsoft se contactar o suporte de produto.

Quando efectua esta solução alternativa, pode elimina problemas SPN de novas instalações ou instalações que tenham tido o nome de domínio ou de porta de TCP/IP modificado.

Importante Recomendamos que não conceda WriteServicePrincipalName direita para a conta do serviço SQL quando se verificam as seguintes condições:
  • Existem vários controladores de domínio.
  • SQL Server está incluído no cluster.
Neste cenário, o SPN para o SQL Server pode ser eliminado devido a latência na replicação do Active Directory. Isto pode causar problemas de conectividade a instância do SQL Server.

Suponha que tem o seguinte:
  • Uma instância do SQL virtual denominada Sqlcluster com dois nós: nó A e o nó B.
  • Nó A é autenticado pelo controlador de domínio A e B de nó é autenticado pelo controlador de domínio B.


Poderá ocorrer o seguinte:
  1. A instância de Sqlcluster está activa no nó A e registado o SPN de SQL no controlador de domínio A durante o início até..
  2. Falha a instância de Sqlcluster através do nó B quando o nó A está encerrado normalmente.
  3. A instância de Sqlcluster registo anulado o SPN do controlador de domínio A durante o processo de encerramento no nó A.
  4. O SPN é removido do controlador de domínio A, mas a alteração ainda não foi replicada para o controlador de domínio B.
  5. Quando iniciar no nó B, a instância de Sqlcluster tenta registar o SPN de SQL com o controlador de domínio B. Desde então, o SPN continua a existir nó B não regista o SPN.
  6. Após algum tempo, o controlador de domínio A replica a eliminação de SPN (do passo 3) para o controlador de domínio B como parte da replicação do Active Directory. O resultado final é que não existe nenhum SPN válido para a instância de SQL no domínio e, portanto, ver problemas de ligação à instância de Sqlcluster.

Nota Este problema foi corrigido no SQL Server 2012.

Ponto Da Situação

A Microsoft confirmou que este é um problema no SQL Server 2000 e SQL Server 2005.

Referências

Para mais informações, clique nos números de artigo que se segue para visualizar os artigos na Microsoft Knowledge Base:
235529Suporte de Kerberos em clusters de servidor baseado no Windows 2000
269229 Como recriar manualmente a conta de serviço de Cluster

Propriedades

Artigo: 303411 - Última revisão: 7 de abril de 2013 - Revisão: 2.0
A informação contida neste artigo aplica-se a:
  • Microsoft SQL Server 2005 Standard Edition
  • Microsoft SQL Server 2005 Developer Edition
  • Microsoft SQL 2005 Server Enterprise
  • Microsoft SQL Server 2005 Express Edition
  • Microsoft SQL 2005 Server Workgroup
  • Microsoft SQL Server 2000 Personal Edition
  • Microsoft SQL Server 2000 Standard Edition
  • Microsoft SQL Server 2000 Workgroup Edition
  • Microsoft SQL Server 2000 Developer Edition
  • Microsoft SQL Server 2000 Enterprise Edition
Palavras-chave: 
kbbug kbpending kbmt KB303411 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: 303411

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