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

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 se controlan los tokens de enlace de canal.

Número de KB original: 976918

Síntomas

Windows 7 y Windows Server 2008 R2 admiten la 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 sea de Windows.
• Errores de autenticación NTLM de servidores proxy.
• Errores de autenticación NTLM de servidores NTLM que no son de Windows.
• Errores de autenticación NTLM cuando hay una diferencia horaria entre el cliente y el servidor de dc o grupo de trabajo.

Causa

Windows 7 y Windows Server 2008 R2 admiten la 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 Windows 7 y Windows 2008 R2 deshabilitan LMv2.

Solución

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

Para los errores en los que los servidores NTLM que no son de Windows o servidores proxy requieren LMv2, compruebe con el proveedor una versión que admita 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. Por lo tanto, asegúrese de que sigue estos pasos con atención. Para la protección añadida, realice una copia de seguridad del Registro antes de modificarlo. A continuación, puede restaurar el Registro si se produce un problema. Para obtener más información sobre cómo realizar copias de seguridad y restaurar el registro, vea Cómo hacer copia de seguridad y restaurar el registro en Windows.

Para controlar el comportamiento de protección ampliada, 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 se pueden autenticar mediante 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 nopatched.
2. Si eso no resuelve el problema, establezca el valor de entrada del Registro en 0x03. Esto configurará Kerberos nunca para emitir 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 podría omitir los enlaces de canal proporcionados por el iniciador, devolviendo el éxito incluso si el iniciador pasó enlaces de canal según RFC 4121. Para obtener más información, consulte 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 ampliada: cambios en la versión 1.6.0_19 (6u19).

Para los clientes de Windows que admiten el enlace de canal que no se pueden autenticar en 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 sin revisión.

Para los servidores NTLM que no son de Windows o servidores proxy 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 horaria es demasiado grande:

1. Corrija el reloj del cliente para reflejar la hora en el controlador de dominio o en el servidor de grupo de trabajo.
2. Si eso 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 asimetría de tiempo.

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

El token de enlace de canal (CBT) forma parte de la protección ampliada para la autenticación. CBT es un mecanismo para enlazar un canal seguro TLS externo a la autenticación de canal interna, 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 incomoda. El servidor valida la información de protección ampliada de acuerdo con su directiva y rechaza los intentos de autenticación para los que no cree que ha sido el destino previsto. De esta manera, los dos canales se enlazan criptográficamente.

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

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 el presente documento se crea en respuesta a temas emergentes o únicos, o se pretende complementar otra información de la base de conocimiento.

Microsoft y/o sus proveedores no realizan 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 se pueden revisar en cualquier momento sin previo aviso.

En la medida máxima permitida por la ley aplicable, Microsoft 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 y idoneidad para un propósito determinado, con respecto a los materiales.