Falha de autenticação de servidores NTLM ou Kerberos não Windows

Este artigo fornece uma solução para vários problemas de falha de autenticação nos quais os servidores NTLM e Kerberos não podem autenticar computadores baseados no Windows 7 e no Windows Server 2008 R2. Isso é causado por diferenças na maneira como os tokens de associação de canal são identificados.

Número original do KB: 976918

Sintomas

O Windows 7 e o Windows Server 2008 R2 dão suporte à Proteção Estendida para Autenticação Integrada, que inclui suporte para CBT (Token de Associação de Canal) por padrão.

Você pode experimentar um ou mais dos seguintes sintomas:

• Os clientes Windows que dão suporte à associação de canal não são autenticados por um servidor Kerberos não Windows.
• Falhas de autenticação NTLM de servidores proxy.
• Falhas de autenticação NTLM de servidores NTLM não Windows.
• Falhas de autenticação NTLM quando há uma diferença de horário entre o cliente e o DC ou o servidor de grupo de trabalho.

Motivo

O Windows 7 e o Windows Server 2008 R2 dão suporte à Proteção Estendida para Autenticação Integrada. Esse recurso aprimora a proteção e o tratamento de credenciais ao autenticar conexões de rede usando a IWA (Autenticação Integrada do Windows).

Isso está ATIVADO por padrão. Quando um cliente tenta se conectar a um servidor, a solicitação de autenticação é associada ao SPN (Nome da Entidade de Serviço) usado. Além disso, quando a autenticação ocorre dentro de um canal TLS (Transport Layer Security), ela pode ser vinculada a esse canal. NTLM e Kerberos fornecem informações adicionais em suas mensagens para dar suporte a essa funcionalidade.

Além disso, os computadores com Windows 7 e Windows 2008 R2 desativam o LMv2.

Resolução

Para falhas em que servidores NTLM ou Kerberos não Windows estão falhando ao receber CBT, verifique com o fornecedor se há uma versão que lide com o CBT corretamente.

Para falhas em que servidores NTLM não Windows ou servidores proxy exigem LMv2, verifique com o fornecedor uma versão que dê suporte a NTLMv2.

Solução alternativa

Importante

Esta seção, método ou tarefa contém etapas que descrevem como modificar o Registro. Entretanto, sérios problemas poderão ocorrer caso você modifique o Registro incorretamente. Portanto, certifique-se de seguir essas etapas com atenção. Para proteção acrescida, faça backup do Registro antes de modificá-lo. Em, é possível restaurar o Registro caso ocorra um problema. Para obter mais informações sobre como fazer backup e restaurar o Registro, consulte Como fazer backup e restaurar o Registro no Windows.

Para controlar o comportamento de proteção estendida, crie a seguinte subchave do Registro:

• Nome da chave: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA
• Nome do valor: SuppressExtendedProtection
• Tipo: DWORD

Para clientes Windows que dão suporte à associação de canal que não estão sendo autenticados por servidores Kerberos não Windows que não lidam com o CBT corretamente:

1. Defina o valor da entrada do Registro como 0x01. Isso configurará o Kerberos para não emitir tokens CBT para aplicativos sem patch.
2. Se isso não resolver o problema, defina o valor da entrada do Registro como 0x03. Isso configurará o Kerberos para nunca emitir tokens CBT.

Observação

Há um problema conhecido com o Sun Java que foi resolvido para acomodar a opção de que o aceitador pode ignorar quaisquer ligações de canal fornecidas pelo iniciador, retornando sucesso mesmo que o iniciador tenha passado as ligações de canal de acordo com o RFC 4121. Para obter mais informações, consulte ignorar a vinculação de canal de entrada se o aceitador não definir uma.

Recomendamos que você instale a seguinte atualização do site Sun Java e reative a proteção estendida: Alterações na versão 1.6.0_19 (6u19).

Para clientes Windows que dão suporte à associação de canal que não estão sendo autenticados por servidores NTLM não Windows que não lidam com o CBT corretamente, defina o valor de entrada do Registro como 0x01. Isso configurará o NTLM para não emitir tokens CBT para aplicativos sem patch.

Para servidores NTLM não Windows ou servidores proxy que exigem LMv2, defina o valor de entrada do Registro como 0x01. Isso configurará o NTLM para fornecer respostas LMv2.

Para o cenário em que a diferença de horário é muito grande:

1. Corrija o relógio do cliente para refletir a hora no controlador de domínio ou no servidor do grupo de trabalho.
2. Se isso não resolver o problema, defina o valor da entrada do Registro como 0x01. Isso configurará o NTLM para fornecer respostas LMv2 que não estão sujeitas a distorção de tempo.

O que é CBT (Channel Binding Token)?

O CBT (Token de Associação de Canal) faz parte da Proteção Estendida para Autenticação. O CBT é um mecanismo para vincular um canal seguro TLS externo à autenticação de canal interno, como Kerberos ou NTLM.

CBT é uma propriedade do canal seguro externo usado para vincular a autenticação ao canal.

A proteção estendida é realizada pelo cliente comunicando o SPN e o CBT ao servidor de maneira inviolável. O servidor valida as informações de proteção estendida de acordo com sua política e rejeita tentativas de autenticação para as quais não acredita ter sido o destino pretendido. Desse modo, os dois canais tornam-se criptograficamente associados juntos.

A proteção estendida agora tem suporte no Windows XP, Windows Vista, Windows Server 2003 e Windows Server 2008.

Aviso de isenção de responsabilidade

Os artigos de publicação rápida fornecem informações diretamente de dentro da organização de suporte da Microsoft. As informações aqui contidas são criadas em resposta a tópicos emergentes ou exclusivos, ou destinam-se a complementar outras informações da base de conhecimento.

A Microsoft e/ou seus fornecedores não fazem representações ou garantias sobre a adequação, confiabilidade ou precisão das informações contidas nos documentos e gráficos relacionados publicados neste site (os "materiais") para qualquer finalidade. Os materiais podem incluir imprecisões técnicas ou erros tipográficos e podem ser revisados a qualquer momento sem aviso prévio.

Na extensão máxima permitida pela lei aplicável, a Microsoft e/ou seus fornecedores se isentam e excluem todas as representações, garantias e condições, sejam expressas, implícitas ou estatutárias, incluindo, mas não se limitando a, representações, garantias ou condições de título, não violação, condição ou qualidade satisfatória, comercialização e adequação a uma finalidade específica, com relação aos materiais.