Nomes principais de serviço MSSQLSvc, Kerberos e NTLM

Question

Estava ajudando recentemente um DBA com um problema que parecia estar relacionado a um SPN inválido. Descobriu que um bom número de contas de serviço SQL simplesmente não tem um conjunto de SPN, resultando em autenticação NTLM.

Eu adicionei a configuração do SPN ao nosso processo de criação, mas não tenho certeza se voltar aos sistemas existentes usando o NTLM e configurar um SPN para permitir a autenticação do Kerberos quebrará qualquer coisa.

Há algum cenário comum em que configurar SPNs MSSQLSvc para permitir a autenticação Kerberos interromperá os sistemas existentes que estão funcionando sem problemas com o NTLM?

Aqui está o código que estou usando:

#Query to identify authentication type for various connections on a SQL server
    $query = "SELECT
        s.session_id,
        c.connect_time,
        s.login_time,
        s.login_name,
        c.protocol_type,
        c.auth_scheme,
        s.HOST_NAME,
        s.program_name
    FROM sys.dm_exec_sessions s
    JOIN sys.dm_exec_connections c
    ON s.session_id = c.session_id"

#Everything comes back NTLM
#Source: https://raw.githubusercontent.com/RamblingCookieMonster/PowerShell/master/Invoke-Sqlcmd2.ps1
    Invoke-Sqlcmd2 -ServerInstance ServerInQuestion -query $query

#Get a list of SPNs associated with ServerInQuestion
#Results indicate no SPNs exist
#Source: http://gallery.technet.microsoft.com/scriptcenter/Get-SPN-Get-Service-3bd5524a
    Get-SPN -ServiceType MSSQLSvc -ComputerName ServerInQuestion

#Configuring SPNs for test systems results in Kerberos working without issue
    setspn -A "MSSQLSvc/ServerInQuestion.DOMAIN.XXX:1433" DOMAIN\SVCACCOUNT
    setspn -A "MSSQLSvc/ServerInQuestion.DOMAIN.XXX" DOMAIN\SVCACCOUNT

Minha preocupação é que, se eu voltar aos sistemas existentes e configurar os SPNs, posso interromper os aplicativos ou processos existentes que funcionam com o NTLM, mas não o Kerberos. Eu suponho que eles iriam falhar no NTLM, se necessário, mas essa não é minha área de especialização e fico desconfortável fazendo essa suposição.

Obrigado!

    

Answer 1

Você provavelmente está certo em estar pelo menos um pouco preocupado. Infelizmente, se um aplicativo específico irá quebrar ou não, tudo depende do aplicativo. Mas, em geral, não é provável que algo seja interrompido, desde que você defina os SPNs corretamente.

Meu conselho principal seria: Um SPN incorreto é pior do que nenhum SPN.

A única coisa que vejo sendo um problema em potencial para você é se os SPNs estiverem definidos, mas configurados incorretamente.

Veja este exemplo:

• Se um cliente remoto tentar se autenticar no SQL e encontrar um SPN válido, ele usará o Kerberos.
• Se o cliente remoto tentar se conectar e não encontrar nenhum SPN, ele usará o NTLM.
• Se o cliente remoto tentar se conectar e encontrar um SPN e tentar usar esse SPN para autenticar via Kerberos, mas falhar porque o SPN era inválido ... ele ainda retornará ao NTLM ou não?

Essa última pergunta é um comportamento muito específico que varia de acordo com o aplicativo e a versão do Windows.

Este é um bom artigo de acompanhamento, embora seja antigo, ainda é relevante:

link

Atualização:

Se for um consolo, acabei de executar um teste usando o SQL Server 2012 e um cliente remoto executando o Server 2012 R2 e o SQL Management Studio. Quando o SPN foi registrado corretamente, o Kerberos foi usado. Quando o SPN estava ausente, o SQL Management Studio passou para o NTLM. Quando propositadamente introduzi um erro de digitação no SPN na conta de serviço, a conexão ainda estava estabelecida e passou para o NTLM. Então, isso é uma boa notícia, mas permanece o fato de que outros aplicativos não especificados podem não implementar a autenticação do Windows corretamente para aproveitar esse protocolo de negociação ... por isso, se você tiver aplicativos estranhos, ainda desejará testá-los. E no seu teste, não se esqueça que o NTLM será sempre usado para conexões locais , independentemente dos SPNs ... dependendo da versão do SO. : D