Error de autenticación de servidores NTLM o Kerberos que no son de Windows

  • Artículo

En este artículo se proporciona una solución a varios problemas de error de autenticación en los que los servidores NTLM y Kerberos no pueden autenticar equipos basados en Windows 7 y Windows Server 2008 R2. Esto se debe a diferencias en la forma en que los tokens de enlace de canal son identificadores.

Se aplica a: Windows Server 7 Service Pack 1, Windows Server 2012 R2
Número de KB original: 976918

Síntomas

Windows 7 y Windows Server 2008 R2 admiten protección ampliada para la autenticación integrada que incluye compatibilidad con el token de enlace de canal (CBT) de forma predeterminada.

Puede experimentar uno o varios de los síntomas siguientes:

  • Los clientes de Windows que admiten el enlace de canal no se pueden autenticar mediante un servidor Kerberos que no es de Windows.
  • Errores de autenticación NTLM de servidores proxy.
  • Errores de autenticación NTLM de servidores NTLM que no son de Windows NTLM.
  • Errores de autenticación NTLM cuando hay una diferencia de tiempo entre el cliente y el servidor de controlador de dominio o grupo de trabajo.

Causa

Windows 7 y Windows Server 2008 R2 admiten protección ampliada para la autenticación integrada. Esta característica mejora la protección y el control de las credenciales al autenticar las conexiones de red mediante la autenticación integrada de Windows (IWA).

Esto es ON de forma predeterminada. Cuando un cliente intenta conectarse a un servidor, la solicitud de autenticación se enlaza al nombre de entidad de seguridad de servicio (SPN) usado. También cuando la autenticación tiene lugar dentro de un canal de seguridad de la capa de transporte (TLS), se puede enlazar a ese canal. NTLM y Kerberos proporcionan información adicional en sus mensajes para admitir esta funcionalidad.

Además, los equipos con Windows 7 y Windows 2008 R2 deshabilitan LMv2.

Solución

Si se producen errores en los servidores NTLM o Kerberos que no son de Windows al recibir CBT, compruebe con el proveedor una versión que controle cbt correctamente.

Si hay errores en los que los servidores NTLM o proxy que no son de Windows requieren LMv2, compruebe con el proveedor una versión compatible con NTLMv2.

Solución alternativa

Importante

Esta sección, método o tarea contiene pasos que le indican cómo modificar el Registro. No obstante, pueden producirse problemas graves si modifica el registro de manera incorrecta. En consecuencia, asegúrese de seguir estos pasos cuidadosamente. Para mayor protección, cree una copia de seguridad del registro antes de modificarlo. Después, puede restaurar el registro si se produce un problema. Para obtener más información sobre cómo hacer una copia de seguridad y restaurar el Registro, vea How to back up and restore the registry in Windows .

Para controlar el comportamiento de protección extendida, cree la siguiente subclave del Registro:

  • Nombre de clave: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA
  • Nombre del valor: SuppressExtendedProtection
  • Tipo: DWORD

Para los clientes de Windows que admiten el enlace de canal que no pueden autenticarse con servidores Kerberos que no son de Windows que no controlan el CBT correctamente:

  1. Establezca el valor de entrada del Registro en 0x01. Esto configurará Kerberos para que no emita tokens CBT para aplicaciones no extendidas.
  2. Si no resuelve el problema, establezca el valor de entrada del Registro en 0x03. Esto configurará Kerberos para que nunca emita tokens CBT.

Nota:

Hay un problema conocido con Sun Java que se ha solucionado para dar cabida a la opción de que el aceptador pueda omitir los enlaces de canal proporcionados por el iniciador, devolviendo el éxito incluso si el iniciador pasó los enlaces de canal según RFC 4121. Para obtener más información, vea Omitir el enlace de canal entrante si el aceptador no establece uno.

Se recomienda instalar la siguiente actualización desde el sitio de Sun Java y volver a habilitar la protección extendida: Cambios en 1.6.0_19 (6u19).

En el caso de los clientes de Windows que admiten el enlace de canal que no pueden autenticarse con servidores NTLM que no son de Windows que no controlan el CBT correctamente, establezca el valor de entrada del Registro en 0x01. Esto configurará NTLM para que no emita tokens CBT para aplicaciones no extendidas.

Para servidores NTLM o servidores proxy que no son de Windows que requieren LMv2, establezca en el valor de entrada del Registro en 0x01. Esto configurará NTLM para proporcionar respuestas LMv2.

Para el escenario en el que la diferencia de tiempo es demasiado grande:

  1. Corrija el reloj del cliente para reflejar la hora en el controlador de dominio o el servidor de grupo de trabajo.
  2. Si no resuelve el problema, establezca el valor de entrada del Registro en 0x01. Esto configurará NTLM para proporcionar respuestas LMv2 que no están sujetas a sesgo de tiempo.

¿Qué es CBT (token de enlace de canal)?

El token de enlace de canal (CBT) forma parte de la protección extendida para la autenticación. CBT es un mecanismo para enlazar un canal seguro TLS externo a la autenticación de canal interno, como Kerberos o NTLM.

CBT es una propiedad del canal seguro externo que se usa para enlazar la autenticación al canal.

La protección ampliada se logra mediante el cliente que comunica el SPN y el CBT al servidor de forma a prueba de alteraciones. El servidor valida la información de protección extendida de acuerdo con su directiva y rechaza los intentos de autenticación para los que no cree que haya sido el destino previsto. De este modo, los dos canales se enlazan criptográficamente.

Ahora se admite la protección ampliada en Windows XP, Windows Vista, Windows Server 2003 y Windows Server 2008.

Aviso de declinación de responsabilidades

Los artículos de publicación rápida proporcionan información directamente desde la organización de soporte técnico de Microsoft. La información contenida en este documento se crea en respuesta a temas emergentes o únicos, o está destinada a complementar otra información knowledge base.

Microsoft y/o sus proveedores no hacen ninguna representación o garantía sobre la idoneidad, confiabilidad o precisión de la información contenida en los documentos y gráficos relacionados publicados en este sitio web (los "materiales") para cualquier propósito. Los materiales pueden incluir imprecisiones técnicas o errores tipográficos y pueden ser revisados en cualquier momento sin previo aviso.

En la medida máxima permitida por la ley aplicable, Microsoft y/o sus proveedores renuncian y excluyen todas las representaciones, garantías y condiciones, ya sean expresas, implícitas o legales, incluidas, entre otras, las representaciones, garantías o condiciones de título, no infracción, condición satisfactoria o calidad, comerciabilidad e idoneidad para un fin determinado, con respecto a los materiales.