Estou encontrando informações contraditórias sobre como exatamente formatar SPNs (Nomes de Princípios de Serviço) para obter as conexões Kerberos adequadas e quantas preciso para cada instância SQL.
Este documento MS de 2017 contém o seguinte:
A partir do SQL Server 2008, o formato SPN é alterado para oferecer suporte à autenticação Kerberos em 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.
Eu entendi 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 MS mais antigo (2011) , não apenas sobre o número da porta, mas também sobre qual nome usar:
Para criar o SPN, você pode usar o nome NetBIOS ou o nome de domínio totalmente qualificado (FQDN) do SQL Server. No entanto, você deve criar um SPN para o nome NetBIOS e o FQDN .
Quando olho os SPNs que já existem no meu ambiente, vejo uma grande variedade de combinações, alguns servidores possuem 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, para instâncias padrão e nomeadas, se eu usar apenas TCP em 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 isso seria apenas se estivéssemos usando pipes nomeados (o que não estamos)?
(Para contextualizar, executamos o SQL 2005 a 2014, alguns em cluster, outros autônomos. A conectividade é apenas via TCP, os pipes nomeados estão desabilitados no gerenciador de configuração. Estaremos corrigindo/criando esses manualmente em vez de permitir que a conta de serviço SQL os crie após início do servidor.)
Se você estiver usando apenas TCP/IP para se conectar às suas instâncias, precisará apenas das portas especificadas. Os nomes de instância são usados ao conectar-se às instâncias SQL por meio dos protocolos de pipes nomeados. Infelizmente, o artigo do MS não diz exatamente qual formato é necessário para qual protocolo, mas é derivado de (muitos testes no meu ambiente) e da seguinte frase do artigo do MS :
Em relação aos nomes FQDNs vs NETBIOS, recomendo FQDNs, pois eles não são tão propensos a problemas se você enfrentar problemas aleatórios do servidor DNS.
Retirados da minha postagem no blog sobre o assunto, os formatos devem ter a seguinte aparência:
A referência da fonte do MS pode ser encontrada aqui .
Agora para fazer o seu Network Admin's Day (por exemplo, configuração de OU que permite SPNs de auto-registro)
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 forma que a conta de serviço possa criar um SPN para si mesma e sozinha. O método segue principalmente o blog de Ryan Reis , mas tem alguns pequenos ajustes para que as concessões excessivas não sejam executadas.
Este processo descreve a criação de uma UO no domínio que permite que as contas dentro dela registrem seus próprios SPNs:
Após seguir as etapas acima, o contêiner da UO em questão agora está configurado de forma que qualquer conta adicionada a ele poderá registrar e excluir SPNs para si e para si mesmo. Essa é exatamente a quantidade certa de permissões, pois essas contas não poderão atropelar SPNs registrados por outras contas.
A finalidade 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 só será realmente necessária se não existir nenhum SPNs atualmente para o referido serviço SQL Server.
A observação final sobre essa abordagem é que, se você estiver executando o SQL Server em uma configuração tradicional de Failover Clustered Instance (FCI), NÃO é recomendado adicionar a conta de serviço desta instância a esta UO, por KB 2443457 .
Eu realmente preciso postar a parte 2 da minha série Kerberos...
Quando o serviço SQL Server cria 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 estiver criando SPNs manualmente, você precisará ter uma porta estática em vez da porta dinâmica padrão.