Por que usar o Kerberos em vez do NTLM no IIS?

Isso é algo que eu nunca consegui responder tão bem quanto gosto: Qual é a real vantagem de usar a autenticação Kerberos no IIS em vez do NTLM?

Vi muitas pessoas realmente lutando para configurá-lo (inclusive eu) e não consegui encontrar uma boa razão para usá-lo. Deve haver algumas vantagens bastante significativas, caso contrário, não valeria todo o esforço para configurá-lo, certo?

Somente da perspectiva do Windows:

NTLM

• trabalhos com tanto externa (sem domínio) e internos clientes
• funciona com contas de domínio e contas de usuário local na caixa IIS
  • usando contas de domínio, apenas o servidor requer conectividade direta com um controlador de domínio (DC)
  • usando contas locais, você não precisa de conectividade em nenhum lugar :)
  • você não precisa fazer logon como usuário em questão para usar uma credencial
  • Além : não é incomum para um DC para ser oprimido por um servidor ocupado NTLM (IIS, o Exchange, TMG / ISA, etc) com o volume de solicitações NTLM (para mitigar: MaxConcurrentAPI, AuthPersistSingleRequest(false) ., Mais rápido DCs) ( Auto- bônus referencial .)
• requer conectividade do cliente apenas com o servidor IIS (na porta do site, nada mais. Por exemplo, tudo acontece por HTTP (ou HTTPS).)
• pode atravessar qualquer proxy que suporte HTTP Keep-Alive s
  • você pode usar o TLS / SSL para solucionar outras pessoas
• requer várias viagens de ida e volta para autenticar, com pacotes pequenos
  • (o padrão do log é 401.2, 401.1, 200 com nome de usuário)
• não pode ser usado em cenários em que a autenticação de salto duplo é necessária
  • ou seja, as credenciais do usuário devem ser encaminhadas para um serviço em outro computador
• suporta clientes mais antigos (<Win2000)
• É suscetível a discrepâncias no nível de autenticação LM (incompatível lmcompatibilitylevel)
• é usado como fallback pelo pacote Negotiate se Curb falhar.
  • ( não "se o acesso for negado com o Kerb", o Kerb deve interromper para que o NTLM seja usado - geralmente isso parece não receber um ticket. Se o cliente receber um ticket e não for perfeito, isso não causará um fallback.)

Kerberos

• funciona apenas com clientes ingressados ​​no domínio atualmente
  • requer conectividade do cliente com um AD DC (tcp / udp 88) E o servidor (os tickets são recuperados pelo cliente do DC pela porta Curb e, em seguida, são fornecidos ao servidor usando HTTP)

• pode ser capaz de atravessar um proxy, mas consulte o ponto DC acima: você ainda precisa estar na mesma rede que um DC ativo, assim como o servidor .

  • portanto, em teoria, se você tivesse um domínio no qual clientes conectados à Internet conversassem diretamente com um controlador de domínio conectado à Internet, seria viável. Mas não faça isso a menos que você já saiba disso.
  • Em cenários de proxy reverso (ISA / TMG), o servidor de transição de protocolo precisa estar nessa rede, ou seja, não no cliente ... mas, em seguida, o cliente não é aquele que está realizando o bit Kerberos (necessariamente - pense em Forms auth to Curb transição).

• o ticket tem vida longa (10h), significando menos comunicação DC durante a vida útil do ticket - e para enfatizar: isso pode economizar milhares a milhões de solicitações por cliente durante esse período de vida útil ( AuthPersistNonNTLMainda é uma coisa; a validação Kerberos PAC costumava ser uma coisa)

• requer uma única viagem de ida e volta para autenticar, mas o tamanho da carga útil da autenticação é relativamente grande (geralmente de 6 a 16K) ( 401 , {(codificado) tamanho do token} 200 )
• pode ser usado com a delegação (por favor, sempre restrita ) para habilitar a autenticação do Windows do usuário que está se conectando ao próximo serviço
  • por exemplo, para permitir o UserAacesso ao IIS e usar a mesma conta de usuário quando o IIS acessar o SQL Server, isso é "delegação de autenticação".
  • ( Restringido neste contexto significa "mas não mais nada", por exemplo, Exchange ou outra caixa SQL)
• atualmente é o pacote de segurança principal para autenticação de negociação
  • o que significa que os membros do domínio do Windows preferem quando podem obtê-lo
• requer registro de SPNs , o que pode ser complicado. Regras que ajudam .
• requer o uso de um nome como destino, não um endereço IP
• razões pelas quais o freio pode falhar:
  • usando um endereço IP em vez de um nome
  • nenhum SPN registrado
  • SPNs duplicados registrados
  • SPN registrado com conta incorreta ( KRB_ERR_AP_MODIFIED)
  • sem conectividade DNS / DC do cliente
  • configuração de proxy do cliente / zona da intranet local não usada para o site de destino

Enquanto estamos nisso:

Basic

• pode multi-hop. Mas o faz expondo seu nome de usuário e senha diretamente ao aplicativo Web de destino
  • que pode fazer o que quiser com eles. Qualquer coisa .
  • "Oh, fez um administrador de domínio apenas usar meu aplicativo? E eu acabei de ler seus e-mails? Então redefinir sua senha? Awww. Pity "
• precisa de segurança da camada de transporte (ou seja, TLS / SSL) para qualquer forma de segurança.
  • e depois, veja a edição anterior
• funciona com qualquer navegador
  • (mas veja a primeira edição )
• requer uma única viagem de ida e volta para autenticar ( 401 , 200 )
• pode ser usado em cenários multi-hop porque o Windows pode executar um logon interativo com credenciais básicas
  • Pode ser necessário LogonTypeque esteja configurado para fazer isso (pense que o padrão foi alterado para texto não criptografado da rede entre 2000 e 2003, mas pode estar errado)
  • mas , novamente , veja a primeira edição .
  • Tem a impressão de que a primeira questão é realmente importante? Isto é.

Resumindo:

O meio-fio pode ser complicado de configurar, mas existem muitos guias (o meu ) por aí que tentam simplificar o processo, e as ferramentas melhoraram bastante de 2003 a 2008 ( SetSPNpodem procurar duplicatas, que é o problema mais comum em questão). ; useSETSPN -S sempre que vir orientação para usar -A e a vida será mais feliz).

Delegação restrita vale o custo de admissão.

• O Kerberos tem a reputação de ser um mecanismo de autenticação mais rápido e seguro que o NTLM.
• Historicamente, também foi mais fácil conectar-se a servidores proxy do que o NTLM, devido à natureza baseada em conexão do NTLM.
• Dito isto, como você observa, o Kerberos é mais difícil de instalar e exige uma conexão com o AD que nem sempre é prático.

Outra abordagem seria definir a autenticação negotiatee usar os dois em vez de um em vez do outro.

No Microsoft Application Verifier , que detecta erros comuns do desenvolvedor. Um desses erros é o uso do NTLM :

O NTLM é um protocolo de autenticação desatualizado com falhas que comprometem potencialmente a segurança dos aplicativos e do sistema operacional. A falha mais importante é a falta de autenticação do servidor, o que poderia permitir que um invasor induzisse os usuários a se conectarem a um servidor falsificado. Como corolário da falta de autenticação do servidor, os aplicativos que usam NTLM também podem ser vulneráveis ​​a um tipo de ataque conhecido como ataque de "reflexão". Este último permite que um invasor seqüestrar a conversa de autenticação de um usuário para um servidor legítimo e usá-lo para autenticar o invasor no computador do usuário. As vulnerabilidades do NTLM e as formas de explorá-las são o objetivo de aumentar a atividade de pesquisa na comunidade de segurança.

Embora o Kerberos esteja disponível há muitos anos, muitos aplicativos ainda são gravados para usar apenas NTLM. Isso desnecessariamente reduz a segurança dos aplicativos. No entanto, o Kerberos não pode substituir o NTLM em todos os cenários - principalmente naqueles em que um cliente precisa se autenticar em sistemas que não estão associados a um domínio (uma rede doméstica talvez seja a mais comum). O pacote de segurança Negociar permite um compromisso compatível com versões anteriores que usa o Kerberos sempre que possível e somente reverte para o NTLM quando não há outra opção. Mudar o código para usar Negociar em vez de NTLM aumentará significativamente a segurança de nossos clientes, ao mesmo tempo em que apresentamos pouca ou nenhuma compatibilidade de aplicativos. Negociar por si só não é uma bala de prata - há casos em que um invasor pode forçar o downgrade para o NTLM, mas estes são significativamente mais difíceis de explorar. No entanto, uma melhoria imediata é que os aplicativos escritos para usar o Negotiate corretamente são automaticamente imunes a ataques de reflexão do NTLM.

Como uma última palavra de cautela contra o uso do NTLM: nas versões futuras do Windows, será possível desativar o uso do NTLM no sistema operacional. Se os aplicativos tiverem uma dependência forte do NTLM, eles simplesmente não serão autenticados quando o NTLM estiver desativado.

Você deve adicionar um ponto muito importante:

O Kerberos é um protocolo padrão e aberto no Unix há mais de 20 anos, enquanto o NTLM é uma solução exclusivamente proprietária da Microsoft e conhecida apenas pela Microsoft.

O Kerberos é necessário se você precisar se passar por um usuário para acessar recursos que não estão no servidor iis.