Estou encontrando informações contraditórias sobre como exatamente formatar SPNs (Service Principle Names) para obter as conexões Kerberos adequadas e quantas eu preciso para cada instância SQL.
Este documento MS 2017 contém o seguinte:
A partir do SQL Server 2008, o formato SPN é alterado para oferecer suporte à autenticação Kerberos no TCP / IP, pipes nomeados e memória compartilhada. Os formatos SPN suportados para instâncias nomeadas e padrão são os seguintes.
- Instância nomeada:
MSSQLSvc/FQDN:[port|instancename]- Instância padrão:
MSSQLSvc/FQDN:port|MSSQLSvc/FQDNO novo formato SPN não requer um número de porta . Isso significa que um servidor de várias portas ou um protocolo que não usa números de porta pode usar a autenticação Kerberos.
Peguei este último parágrafo para significar que eu só preciso de uma única entrada, uma das seguintes:
- Instância nomeada:
MSSQLSvc/sqlbox1.mydomain.org/instance2 - Instância padrão:
MSSQLSvc/sqlbox1.mydomain.org
Isso parece contradizer este documento antigo do MS (2011) , não apenas sobre o número da porta, mas também sobre o nome a ser usado:
Para criar o SPN, você pode usar o nome NetBIOS ou o FQDN (Fully Qualified Domain Name) do SQL Server. No entanto, você deve criar um SPN para o nome NetBIOS e o FQDN .
Quando olho para os SPNs que já existem no meu ambiente, vejo uma grande variedade de combinações, alguns servidores têm até 4 entradas:
MSSQLSvc/sqlbox1MSSQLSvc/sqlbox1:1433MSSQLSvc/sqlbox1.mydomain.orgMSSQLSvc/sqlbox1.mydomain.org:1433
Até o próprio gerenciador de configuração Kerberos da MS parece querer gerar as duas últimas versões (com ofuscação apropriada):
Da mesma forma, para instâncias nomeadas existentes, vejo uma mistura estranha, algumas delas quase certamente inválidas:
MSSQLSvc/sqlbox1:1522MSSQLSvc/sqlbox1:instance2MSSQLSvc/sqlbox1.mydomain.org:1522MSSQLSvc/sqlbox1.mydomain.org:instance2MSSQLSvc/sqlbox1.mydomain.org/instance2MSSQLSvc/sqlbox1.mydomain.org:1522:instance2
Então, como devem ser meus DSNs, tanto para as instâncias padrão quanto para as nomeadas, se eu apenas usar o TCP no meu ambiente?
Devo incluir a porta ou não? Ou incluir um com a porta e outro sem?
Use apenas o FQDN ou preciso das entradas apenas com o nome Netbios? Ou seria apenas se estivéssemos usando pipes nomeados (o que não somos)?
(Para o contexto, executamos o SQL 2005 até 2014, alguns agrupados, outros autônomos. A conectividade é somente via TCP, os pipes nomeados estão desabilitados no gerenciador de configuração. Vamos corrigi-los / criá-los manualmente, em vez de permitir que a conta do serviço SQL os crie após início do servidor.)
fonte
Respostas:
Se você estiver usando apenas o TCP / IP para se conectar às suas instâncias, precisará apenas das portas especificadas. Os nomes das instâncias são usados ao conectar-se às instâncias SQL por meio dos protocolos de pipes nomeados. Infelizmente, o artigo da MS não sai direto, diga qual formato é necessário para qual protocolo, mas é derivado de (muitos testes no meu ambiente) e a seguinte importância do artigo da MS :
Em relação aos nomes FQDNs e NETBIOS, recomendarei FQDNs, pois eles não são tão propensos a problemas se você enfrentar problemas aleatórios no servidor DNS.
Retirado do meu blog sobre o assunto, os formatos devem ter a seguinte aparência:
A referência de origem da MS pode ser encontrada aqui .
Agora, para fazer o dia do administrador da rede (por exemplo, configuração da UO que permite o registro automático de SPNs)
Seu administrador de rede pode criar uma UO no domínio que contém todas as suas contas de serviço do SQL Server que podem ser configuradas de maneira que a conta de serviço possa criar um SPN para si e para si próprio. O método segue principalmente o blog de Ryan Reis , mas apresenta alguns pequenos ajustes para que não sejam realizadas subvenções.
Este processo descreve a criação de uma UO no domínio que permite que as contas nele registrem automaticamente seus próprios SPNs:
Depois de seguir as etapas acima, o contêiner da OU em questão agora está configurado para que qualquer conta adicionada a ele possa registrar e excluir SPNs somente para si e para si. Essa é exatamente a quantidade certa de permissões, pois essas contas não poderão atropelar os SPNs registrados por outras contas.
O objetivo de reiniciar o SQL Server na etapa 16 é garantir que os SPNs sejam registrados conforme o esperado. O SQL tentará remover todos os SPNs registrados no desligamento e adicioná-los na Inicialização. Portanto, a reinicialização será realmente necessária apenas se não houver atualmente SPNs para o serviço SQL Server.
A observação final dessa abordagem é que, se você estiver executando o SQL Server em uma configuração tradicional de Instância em Cluster de Failover (FCI), NÃO é recomendável adicionar a conta de serviço dessa instância a esta OU, por KB 2443457 .
Eu realmente preciso postar a Parte 2 da minha série Kerberos ...
fonte
Quando o serviço SQL Server cria o SPN, ele cria dois para cada instância. Este é o formato que ele usa.
Instância padrão:
Instância nomeada:
Para suas instâncias nomeadas, se você criar SPNs manualmente, precisará ter uma porta estática em vez da porta dinâmica padrão.
fonte