O SQL Server em execução sob uma conta de domínio não pode registrar seu SPN

Question

Estou tentando configurar uma nova instalação do SQL Server para ser executada em uma conta de domínio. No entanto, recebo erros intermitentes ao tentar conectar-me ao servidor usando outra conta de domínio, e ainda vejo The SQL Server Network Interface library could not register the Service Principal Name ao vasculhar o arquivo ERRORLOG.

Eu adicionei minha conta de serviço (não uma Conta de Serviço Gerenciado, apenas uma conta de usuário comum) a um grupo do AD (por exemplo, SQL Servers ) e adicionei uma ACE à ACL do meu domínio Computers container, por este grupo, selecionando:

• Aplicar a: objetos de computador descendente
• Gravação validada para o nome principal do serviço: Permitir
• Ler servicePrincipalName: permitir
• Gravar servicePrincipalName: permitir

Eu repliquei isso para todos os controladores de domínio e confirmei a hereditariedade do novo ACE ao objeto de computador específico, usando a guia Permissões Efetivas e com dsacls CN=SERVER01,CN=Computers,DC=fabrikam,DC=local , o último dos quais agora inclui:

Allow FABRIKAM\SQL Servers
                                  SPECIAL ACCESS for Validated write to service principal name   <Inherited from parent>
                                  WRITE SELF
Allow FABRIKAM\SQL Servers
                                  SPECIAL ACCESS for Validated write to service principal name   <Inherited from parent>
                                  WRITE SELF
                                  WRITE PROPERTY
                                  READ PROPERTY

No entanto, quando eu reinicio o serviço do SQL Server, ainda vejo a mensagem could not register the Service Principal Name . Eu também reiniciei o servidor, com o mesmo resultado.

Eu usei o Sysinternals Process Explorer para inspecionar a execução sqlservr.exe ; a guia Segurança mostra claramente o usuário do serviço correto e sua associação ao grupo SQL Servers .

Eu sei que posso adicionar manualmente o SPN com setspn -A , mas isso não é realmente o ponto.

O que mais devo fazer para garantir que a conta de serviço (e qualquer conta futura que eu coloque no grupo SQL Servers ) possa registrar automaticamente seu próprio SPN sem intervenção manual?

E / OU

Como posso diagnosticar quais privilégios / permissões estão faltando aqui?

    

Answer 1

Eu encontrei.

Eu registrei o SPN manualmente na conta de serviço e inspecionei o AD com o ADSIEdit, apenas para descobrir que os SPNs registrados manualmente não estavam armazenados no campo servicePrincipalName da conta Computador , mas o campo servicePrincipalName da conta específica Usuário .

Portanto, em vez de conceder aos meus grupos SQL Servers direitos para registrar seus próprios SPNs, concedi (inadvertidamente) a eles os direitos de alterar os SPNs registrados pelos serviços executados como contas do Sistema Local / Serviço de Rede nesse computador. / p>

Agora removi o novo ACE do contêiner Computers e, em vez disso, criei uma nova Unidade organizacional SQL Servers . Eu adicionei uma ACE para SELF a essa UO e a restrinjai para aplicar a usuários :

• SQL Servers OU ACL
  • %código%
    • Aplicar a: objetos de usuário descendente
    • Ler servicePrincipalName: permitir
    • Gravar servicePrincipalName: permitir

Agora, quando inicio minha instância do SQL Server, vejo a SELF esperada e o Kerberos agora está sendo usado para minhas conexões remotas.

(Agora, para atualizar nossa documentação interna do processo, ela exige que novas contas de serviço do SQL Server sejam criadas sob a nova UO, em vez de serem adicionadas ao grupo)

Editar: Observe que um administrador de domínio também pode registrar manualmente os SPNs em uma conta de domínio usando The SQL Server Network Interface library successfully registered the Service Principal Name .

setspn -S MSSQLSvc/myhost.redmond.microsoft.com:1433 DOMAIN\User
setspn -S MSSQLSvc/myhost.redmond.microsoft.com DOMAIN\User

Registre um nome principal de serviço para conexões Kerberos (TechNet) .

Editar 2: Se as propriedades setspn.exe e Read servicePrincipalName não estiverem visíveis na lista ACE, vá para a aba Editor de Atributos do do objeto Propriedades , clique no botão Filtro e verifique o seguinte:

• Mostrar apenas atributos com valores está desmarcado
• Mostrar apenas atributos graváveis é desmarcado
• Mostrar atributos: Obrigatório é marcado
• Mostrar atributos: opcional é marcado
• Mostrar atributos somente leitura: Construído é marcado
• Mostrar atributos somente leitura: o Backlink é verificado
• Mostrar atributos somente leitura: somente o sistema é verificado

(Outras combinações podem funcionar, mas isso é o que acontece comigo)

    

Answer 2

Você não informou qual versão do SQL Server estava executando, nem as permissões da conta de serviço (além de não ser uma Conta de serviço gerenciada e ter SPN de gravação), mas das informações que você está fornecendo, acredito a conta não tem autoridade para se registrar como um SPN. Mesmo assim, sim, você concedeu isso explicitamente.

Aparentemente, o SQL 2012 requer uma conta virtual ou conta de serviço gerenciado no servidor 2008 :

When the Database Engine service starts, it attempts to register the Service Principal Name (SPN). If the account starting SQL Server doesn’t have permission to register a SPN in Active Directory Domain Services, this call will fail and a warning message will be logged in the Application event log as well as the SQL Server error log. To register the SPN, the Database Engine must be running under a built-in account, such as Local System (not recommended), or NETWORK SERVICE, or an account that has permission to register an SPN, such as a domain administrator account. When SQL Server is running on the Windows 7 or Windows Server 2008 R2 operating system, you can run SQL Server using a virtual account or a managed service account (MSA). Both virtual accounts and MSA’s can register an SPN. If SQL Server is not running under one of these accounts, the SPN is not registered at startup and the domain administrator must register the SPN manually.

Espero que ajude.

    

Answer 3

Se o nome da conta do AD usada pelo serviço SQL tiver mais de 20 caracteres, o SetSpn.exe não poderá encontrá-lo no AD e a única maneira de autenticar as sessões SQL usando o Kerberos é a reconfiguração de Permissões do AD e o reinício do SQL. Não tente enganar SetSpn.exe -S encurtando o parâmetro de nome: SetSpn.exe localizará a conta, mas ela será registrada com o nome "incompatível" para o Kerberos

    

Answer 4

@Katherine Villyard

Quando o serviço Mecanismo de Banco de Dados é iniciado, ele tenta registrar o Nome Principal de Serviço (SPN). Se a conta que inicia o SQL Server não tiver permissão para registrar um SPN nos Serviços de Domínio Active Directory, essa chamada falhará e uma mensagem de aviso será registrada no log de eventos do aplicativo, bem como no log de erros do SQL Server. Para registrar o SPN, o Mecanismo de Banco de Dados deve estar sendo executado em uma conta interna, como Sistema Local (não recomendado) ou SERVIÇO DE REDE, ou uma conta que tenha permissão para registrar um SPN, como uma conta de administrador de domínio. Quando o SQL Server está em execução no sistema operacional Windows 7 ou Windows Server 2008 R2, você pode executar o SQL Server usando uma conta virtual ou uma conta de serviço gerenciado (MSA). As contas virtuais e as MSAs podem registrar um SPN. Se o SQL Server não estiver sendo executado em uma dessas contas, o SPN não será registrado na inicialização e o administrador do domínio deverá registrar o SPN manualmente.

Agora eu encontrei SPNs duplicados setspn -x

Um está associado ao servidor e novamente a uma conta de administrador de domínio. As propriedades do computador mostram o SPN de leitura / gravação como permissões efetivas e a conta de administrador não. Apesar disso .... Como posso ter certeza de qual conta remover o SPN associado de?

Obrigado. Por favor, lembre-se da minha pergunta se parecer bobo.

Cumprimentos Rajen