Como devem ser minhas entradas SPN para cada instância SQL?

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/FQDN

O 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/sqlbox1
MSSQLSvc/sqlbox1:1433
MSSQLSvc/sqlbox1.mydomain.org
MSSQLSvc/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:1522
MSSQLSvc/sqlbox1:instance2
MSSQLSvc/sqlbox1.mydomain.org:1522
MSSQLSvc/sqlbox1.mydomain.org:instance2
MSSQLSvc/sqlbox1.mydomain.org/instance2
MSSQLSvc/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.)

sql-server kerberos spn

— BradC
fonte

Algum motivo específico para você gerenciar os SPNs em vez de permitir que o SQL (e sua conta de serviço) faça isso por você?

— 18717 Nic

no que diz respeito aos SPNs, se funcionar, importa qual é o formato? Eu segundo comentário @Nic

— Bob Klimes

@Nic Como isso exigiria conceder a várias dezenas de contas de serviço novos direitos do Active Directory, nosso administrador do Active Directory disse que uma adição manual única é mais fácil de gerenciar. Também foram encontrados alguns links dizendo coisas engraçadas quando os SPNs tentam sincronizar entre vários controladores de domínio quando são adicionados / removidos dinamicamente ao iniciar / parar / failover de cluster. Tudo o que disse, deixe-me perguntar o seguinte: quando você fazer permitir que a conta de serviço para adicionar o SPN na inicialização, o que lhe parece? Uma única entrada com FQDN e porta? Ou sem porta? Ou duas entradas?

— BradC

@BobKlimes Bem, alguns deles não funcionam, esse é o problema. Acho que não há mal em ter mais entradas do que o necessário, mas apenas tentando entender quais realmente fazem o trabalho.

— 18717 BradCuritiba

@BradC Eu definitivamente tive problemas com failover de cluster e vários DCs. Esses foram meus únicos SPNs criados manualmente.

— Bob Klimes

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 :

Para pipes nomeados e conexões de memória compartilhada, um SPN no formato MSSQLSvc / FQDN: instancename é usado para uma instância nomeada e MSSQLSvc / FQDN é usado para a instância padrão.

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:

Como uma conta com direitos elevados no domínio, abra o ADSI Edit (adsiedit no prompt de comando)
Clique com o botão direito do mouse em ADSI Edit -> Connect to ...
Conectar-se ao contexto de nomenclatura padrão
Navegue para / Crie o contêiner da UO que contém as contas de serviço às quais você deseja conceder direitos SPN
Clique com o botão direito do mouse na UO -> Propriedades
Clique na guia Segurança
Clique no botão Avançado
Destaque SELF e clique em Editar ... ou se o usuário especial SELF não aparecer na lista de nomes de Grupo ou Usuário, clique em Adicionar ... e insira SELF como o nome do objeto.
Clique na guia Propriedades
Selecione Objetos de Usuário Descendente na lista suspensa ao lado de Aplicar a: Nota: Esse é um pequeno ajuste nas etapas descritas na postagem do blog de Ryan pelos motivos mais destacados nesta postagem do ServerFault / StackExchange .
Marque a caixa Permitir ao lado do seguinte:
- Leia servicePrincipalName
- Escreva servicePrincipalName
Clique em Ok (na janela de entrada de permissões)
Clique em Ok (na janela Configurações avançadas de segurança)
Clique em Ok (na janela de propriedades da OU)
Adicionar contas de serviço executando serviços do SQL Server à UO
(Opcionalmente) Reinicie os serviços do SQL Server em execução nas referidas contas
Desfrute de deleites

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 ...

— John Eisbrener
fonte

Não são Objetos de Usuário Descendentes , são Objetos de Computador Descendentes .

— Isaac Kleiman

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:

MSSQLSvc/servername.domain.com
MSSQLSvc/servername.domain.com:1433

Instância nomeada:

MSSQLSvc/servername.domain.com:54321
MSSQLSvc/servername.domain.com:instancename

Para suas instâncias nomeadas, se você criar SPNs manualmente, precisará ter uma porta estática em vez da porta dinâmica padrão.

— Bob Klimes
fonte