Kerberos e NTLM – como funcionam e qual a melhor escolha para o SQL Server

Como sabemos no SQL Server nós temos duas formas de autenticação.

A primeira delas, a autenticação pelo Windows, utiliza as próprias contas do domínio para realizar a autenticação e é a forma padrão e recomendada de autenticação com o SQL Server.

A segunda forma é utilizando a autenticação do próprio SQL Server, que vem desabilitada por padrão até que você habilite a autenticação mista no servidor. Esta forma de autenticação funciona gerando usuários no próprio SQL Server que será então o responsável por validar também a senha.

Essas diferentes formas de autenticação somente são possíveis devido ao fato do SQL Server utilizar o Security Support Provider Interface (SSPI) (sim, aquela sigla que vemos nas mensagens de erro!) que permite que uma aplicação utilize vários modos de autenticação disponíveis em um computador ou rede, sem mudar a interface do sistema de segurança.

Entre os pontos que definem a autenticação Windows como mais segura podemos citar o fato de não haver tráfego de senha pela rede, pois nesse caso o SQL Server apenas precisa validar o usuário com o controlador do domínio, enquanto que na autenticação SQL Server essa senha é enviada pela rede, podendo ser inclusive capturada pela rede se você não utilizar conexões criptografadas (tema para um outro post).

Outro ponto é a facilidade para o usuário que não precisa memorizar mais uma senha e possivelmente gerar maior esforço de suporte em caso de esquecimento da mesma.

Agora indo ao ponto central desse ponto, temos que lembrar que o simples fato de estarmos utilizando autenticação Windows não garante que o estamos fazendo da forma mais segura possível, pois esta pode acontecer de duas formas, utilizando NTLM ou Kerberos.

O NTLM é o protocolo padrão de autenticação no SQL Server e funciona da seguinte forma:

  1. Cliente envia nome de usuário para o servidor
  2. Servidor gera e envia um “desafio” para o cliente
  3. Cliente encripta o “desafio” utilizando a senha do usuário
  4. Cliente envia o “desafio” encriptado para o servidor
  5. Se o usuário for uma conta local o servidor valida o usuário (ou não!), caso seja uma conta de domínio o servidor encaminha para o controlador de domínio para que este valide a conta

Já o protocolo Kerberos utiliza um Key Distribution Center (KDC), ou centro de distribuição de chaves, e funciona da seguinte forma:

  1. Usuário se autentica com o KDC
  2. Um outro componente do KDC, o AS, recebe a requisição de autenticação e a valida
  3. KDC envia um ticket para o cliente
  4. Cliente recebe o ticket e o coloca em cache
  5. Ao tentar utilizar um recurso da rede o cliente envia o ticket recebido ao componente TGS do KDC
  6. KDC retorna um ticket de sessão para o cliente
  7. Cliente envia o ticket de sessão para o recurso de rede que deseja acessar
  8. Servidor avalia o ticket
  9. Servidor libera ou bloqueia acesso do cliente

Obs: as 3 cabeças do Kerberos (cão mitólogico de 3 cabeças, símbolo do protocolo Kerberos) representam o cliente, servidor e o KDC .

Mas então, qual o problema com o NTLM que me faz escolher o Kerberos?

Bem, não vou entrar no detalhe de cada um deles, mas os problemas em geral são os seguintes (sugiro pesquisar mais na internet sobre esses problemas abaixo!)

Permite “ataques de replay” – alguém captura o pacote de autenticação do NTLM e reutiliza o mesmo para outros fins.

Assume que o servidor é confiável – o cliente se conecta em um servidor que “se diz” ser o SQL Server, mas quem garante isso? Pode ser um servidor “falso” se fazendo passar pelo servidor que desejamos conectar.

Requer mais tráfego de autenticação do que o Kerberos – o NTLM exige a autenticação a cada tentativa de acesso, enquanto que no Kerberos enquanto o ticket for válido (em geral por 10 horas) eu não preciso refazer o processo de autenticação

Não fornece um modo de “passar” a autenticação de uma servidor para outro (processo conhecido como Hop) – Imagine que vou utilizar um servidor SSRS que está em um servidor dedicado e este irá acessar uma base de dados através de um linked server. Com o NTLM, após me autenticar no servidor SSRS, este ao tentar acessar os dados no servidor com a base de dados precisará se autenticar utilizando minhas credenciais,  mas com o NTLM não há como o servidor “repassar” minha identidade para outro servidor, impedindo assim que eu realize a autenticação nesse cenário (que só é possível então com Kerberos).

Esse cenário citado acima é o típico momento onde você recebe as (explicativas!) mensagens de “login null” ou “NT AUTHORITY\ANONYMOUS LOGON“, pois a credencial não é enviada para o segundo servidor que pensa que você está tentando realizar um login anônimo.

Então o que preciso para utilizar autenticação com Kerberos?! Veremos agora!

Pré-requisitos:

  • Cliente e servidor devem fazer parte do mesmo domínio do windows ou domínios com confiança entre eles
  • O SPN deve estar registrado no Active Directory (veremos como fazer isso)
  • Cliente deve conectar ao servidor utilizando TCP/IP (ou seja, named pipes, shared memory não permitem utilizar o Kerberos!)

Agora vem a pergunta, o que é um SPN?

Um SPN (Service Principal Name) provê informação sobre o serviço para o cliente. Ele é formado de 3 ou 4 das partes abaixo (a porta do serviço é opcional)

  • Tipo do serviço (o SQL Server é chamado de MSSQLSvc)
  • Nome do servidor
  • A porta (se necessária)
  • A conta com a qual o serviço está executando

Precisaremos de TODOS estes itens corretos para fazer a conexão com o Kerberos!

Como configuro o SPN?

Para configurar o SPN você deve ser administrador do domínio ou a conta de sistema do computador ou uma conta como a Network Service.

Como normalmente não configuramos (boas práticas!) o SQL Server com nenhum desses tipos de contas o mesmo não será capaz de configurar o SPN por conta própria. Na verdade o SQL Server até tentará registrar o SPN automaticamente se o protocolo TCP/IP estiver ativo, mas ele vai gerar mensagens no log parecidas com a seguinte:

The SQL Network Interface library could not register the Service Principal Name (SPN) for the SQL Server service. Error: 0x2098. Failure to register an SPN may cause integrated authentication to fall back to NTLM instead of Kerberos. This is an informational message. Further action is only required if Kerberos authentication is required by authentication policies.

Assim teremos que registrar o SPN manualmente com uma conta de administrador de domínio provavelmente.

Para isso precisaremos da ferramenta SETSPN que pode ser encontrada no CD/DVD de instalação do Windows Server ou aqui.

Antes de demonstrar como registrar o SPN faço uma consideração. Apesar de a porta ser um item opcional é prática geral registrar o SPN das duas formas, com a porta e sem a mesma. Além disso também é importante registrar os ambos os nomes NetBIOS (meuServidor) e FQDN (meuServidor.meuDominio.com).

Então os comandos para gerar o SPN seriam no formato:

SETSPN -A MSSQLSvc/<Nome do Servidor>:<porta> <Conta de Servico>

Um exemplo seria:

SETSPN -A MSSQLSvc/MeuServidor MeuDominio\ContaDeServicoDoSQLServer
SETSPN -A MSSQLSvc/MeuServidor:1433 MeuDominio\ContaDeServicoDoSQLServer
SETSPN -A MSSQLSvc/MeuServidor.MeuDominio.com MeuDominio\ContaDeServicoDoSQLServer
SETSPN -A MSSQLSvc/MeuServidor.MeuDominio.com:1433 MeuDominio\ContaDeServicoDoSQLServer

Como verifico qual protocolo utilizado pelas conexões em meu servidor?

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

ou se quiser uma forma simples de verificar apenas uma conexão específica (no exemplo abaixo a sua própria conexão):

select auth_scheme
from sys.dm_exec_connections
where session_id=@@spid

E o que acontece se eu configurar meu ambiente para Kerberos e houver algum problema?

O SQL Server tentará por padrão conectar utilizando o protocolo Kerberos, mas caso haja algum problema ele irá utilizar o protocolo NTLM para a conexão.

Fontes de leitura extra e artigos consultados:

About these ads
Esse post foi publicado em Artigos, Segurança, Virtual PASS BR. Bookmark o link permanente.

9 respostas para Kerberos e NTLM – como funcionam e qual a melhor escolha para o SQL Server

  1. Pingback: Autenticação Kerberos x CNAME | Vladimir M. B. Magalhães – Learn and Share

  2. Pingback: 24 Horas de PASS – Português – Minha Palestra | Vladimir M. B. Magalhães – Learn and Share

  3. Vladimir,

    Post muito esclarecedor.

    Umas dúvidas, minha aplicação, desenvolvida em ASP.NET MVC, já autentica via Windows Authentication com o protocolo NTLM. Tudo funciona corretamente, porém, justamente quando tento conectar no SQL Server com Integrated Security na string de conexão, o erro Login failed for user ‘NT AUTHORITY\ANONYMOUS LOGON’ aparece.

    Se eu seguir os passos que você indica, não preciso fazer mais nada na aplicação pra resolver o problema ou vou precisar mudar algo na aplicação que usa NTLM pra autenticar o usuário? O SETSPN eu tenho que rodar no servidor de domínio ou no servidor SQL Server?

    Como posso entrar em contato contigo, tipo um email…

    Desde já, obrigado!

    • magalhaesv disse:

      Olá Juliano.

      Fazendo as configurações/verificações que cito no artigo deve funcionar sim. A priori você não precisa fazer outra alteração na string de conexão, já que por padrão ele tenta conectar utilizando Kerberos e, caso não consiga, ele tenta em NTLM. Obviamente, estou dizendo isso sem conhecer seu cenário, então pode estar passando algo que eu não saiba.

      Quanto ao SETSPN pode ser em qualquer servidor do domínio, o que importa é que a conta que está executando o comando tenha as devidas permissões.

      Quanto ao contato, vou te mandar um e-mail com o endereço que você informou ao fazer o comentário.

      Abraço,

      Vladimir

  4. Meu cenário é uma rede Windows com Active Directory. Nosso domínio é ‘bandeirantes’

    Para exemplificar, tenho 3 máquinas,:

    • DESKTOP do usuário logado no domínio e usando Internet Explorer autenticado à minha aplicação (apps.band.com.br por exemplo)
    • SERVER-APP que está incluído no domínio bandeirantes e possui um IIS configurado e funcionando. A aplicação conecta no SQL Server
    • SERVER-SQL que também está adicionado no domínio.

    No caso, meu problema está em usar a credencial passada via Internet Explorer para a aplicação no SERVER-APP e usá-la para se autenticar no SERVER-SQL

    Estranhamente, aplicações legadas rodando em outro server com IIS 6, conseguem se conectar no SQL Server usando Integrated Security no mesmo servidor de SQL Server.

  5. Francke Peixoto disse:

    Valeu pelo post! estava precisando muito ler tudo que escreveu! ;-)

  6. Vlad, bom artigo e ótimas referências!

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s