Compartir a través de

Problemas conocidos de la configuración de Kerberos (SharePoint Server 2010)

  • Artículo

 

Se aplica a: SharePoint Server 2010

Última modificación del tema: 2016-11-30

Autenticación Kerberos y puertos no predeterminados

También hay un problema conocido en el que algunos clientes Kerberos (incluidos .NET Framework, Internet Explorer 7 y 8) no forman correctamente nombres principales de servicio al intentar autenticarse con aplicaciones web habilitadas para Kerberos que se configuran en puertos no predeterminados (puertos que no son el 80 ni el 443). La raíz del problema es que el cliente no forma correctamente el SPN en la solicitud TGS al especificarlo sin el número de puerto (tal y como se muestra en el Sname de la solicitud TGS).

Ejemplo:

Si la aplicación web se ejecuta en http://intranet.contoso.com:1234, el cliente solicitará un vale para un servicio con un SPN igual que http/intranet.contoso.com en lugar de http/intranet.contoso.com:1234.

Puede obtener información detallada sobre el problema en los siguientes artículos:

Para evitar este problema, registre los SPN con y sin número de puerto. Por ejemplo:

  • http/intranet

  • http/intranet.contoso.com

  • http/intranet:12345

  • http/intranet.contoso.com:12345

Se recomienda que registre el puerto no predeterminado para asegurarse de que si el problema se resuelve en alguna revisión o Service Pack futuro, las aplicaciones que usan la solución sigan funcionando todavía.

Tenga en cuenta que esta solución no funcionará si se cumplen las condiciones siguientes:

  • Se está ejecutando más de una aplicación web en un puerto no predeterminado

  • Las aplicaciones web se enlazan con el nombre de host del servidor o se enlazan con el mismo encabezado host (en distintos puertos)

  • Los grupos de aplicaciones de IIS de la aplicación web usan diferentes cuentas de servicio

Si se cumplen estas condiciones, seguir la recomendación de esta solución producirá SPN duplicados registrados en diferentes cuentas de servicio que interrumpirán la autenticación Kerberos.

Si tiene varios sitios web que comparten el mismo nombre de host que se ejecuta en varios puertos, y usa distintas identidades de grupo de aplicaciones de IIS para las aplicaciones web, no podrá usar la autenticación Kerberos en todos los sitios web. (Una aplicación puede usar Kerberos, el resto requerirá otro protocolo de autenticación). Para usar Kerberos en todas las aplicaciones de este escenario, deberá realizar una de las siguientes acciones:

  1. Ejecutar todas las aplicaciones web bajo una cuenta de servicio compartida

  2. Ejecutar cada sitio con su propio encabezado host

Autenticación Kerberos y CNAME de DNS

Hay un problema conocido con algunos clientes Kerberos (Internet Explorer 7 y 8 incluidos) que intentan autenticarse con servicios habilitados para Kerberos que se configuran para resolver mediante CNAME de DNS, en lugar de registros A. La raíz del problema es que el cliente no forma correctamente el SPN en la solicitud TGS al crearlo mediante el nombre de host (registro A), en lugar del nombre de alias (CNAME).

Ejemplo:

Registro A: wfe01.contoso.com

CNAME: intranet.contoso.com (alias wfe01.contoso.com)

Si el cliente intenta autenticarse con http://intranet.contoso.com, el cliente no forma correctamente el SPN y solicita un vale de Kerberos para http/wfe01.contoso.com, en lugar de http/intranet.contoso.com

Puede obtener información detallada sobre el problema en los siguientes artículos:

https://support.microsoft.com/kb/911149/es-es

https://support.microsoft.com/kb/938305/es-es

Para evitar este problema, configure los servicios habilitados para Kerberos mediante registros A de DNS, en lugar de alias CNAME. La revisión mencionada en el artículo de Knowledge Base corregirá este problema para Internet Explorer, pero no lo corregirá para .NET Framework (utilizado por Microsoft Office SharePoint Server para la comunicación de servicios web).

Autenticación Kerberos y autenticación de modo kernel

Nota

La autenticación de modo kernel no es compatible con los Productos de SharePoint 2010. Esta información se proporciona con fines exclusivamente informativos.

A partir de la versión 7.0 de IIS, hay una nueva característica de autenticación denominada autenticación de modo kernel. Cuando se configure un sitio web de IIS para usar la autenticación de modo kernel, HTTP.sys autenticará las solicitudes del cliente en lugar del proceso de trabajo del grupo de aplicaciones. Dado que HTTP.sys se ejecuta en modo kernel, se produce mejor rendimiento pero también se presenta un poco de complejidad al configurar Kerberos. Esto se debe a que HTTP.sys se ejecuta bajo la identidad del equipo y no bajo la identidad del proceso de trabajo. Cuando HTTP.sys reciba un vale de Kerberos, de manera predeterminada intentará descifrar el vale mediante la clave de cifrado del servidor (también conocida como secreta) y no la clave de la identidad bajo la cual se ejecuta el proceso de trabajo.

Si se configura un solo servidor web para que use la autenticación de modo kernel, Kerberos funcionará sin ninguna configuración adicional o SPN adicionales porque el servidor registrará automáticamente un SPN de HOST cuando se agregue al dominio. Si se equilibra la carga de varios servidores web, la configuración predeterminada de autenticación de modo kernel no funcionará, o al menos presentará errores intermitentemente, puesto que el cliente no tiene manera de garantizar que el vale de servicio que recibió en la solicitud TGS funcionará con el servidor que autentica la solicitud.

Para evitar este problema, puede hacer lo siguiente:

Autenticación Kerberos y autenticación basada en sesión

Puede que observe un aumento en el tráfico de autenticación al usar la autenticación Kerberos con IIS 7.0 y superior. Esto puede estar relacionado con la configuración de la autenticación de Windows en IIS, en particular:

AuthPersistNonNTLM

Atributo booleano opcional.

Especifica si IIS vuelve a autenticar automáticamente todas las solicitudes que no son NTLM (por ejemplo, Kerberos), incluso las que están en la misma conexión. True habilita varias autenticaciones para las mismas conexiones.

El valor predeterminado es False.

Nota

Un valor False significa que el cliente se autenticará solo una vez en la misma conexión. IIS almacenará en caché un token o vale en el servidor para una sesión TCP que permanece establecida.

authPersistSingleRequest

Atributo booleano opcional.

Al establecer esta marca en True, se especifica que la autenticación solo persiste para una única solicitud en una conexión. IIS restablece la autenticación al final de cada solicitud y obliga a que se realice una nueva autenticación en la siguiente solicitud de la sesión.

El valor predeterminado es False.

Para obtener instrucciones sobre cómo configurar la persistencia de autenticación en IIS 7.0, vea el tema sobre qué hacer cuando se obtiene un rendimiento lento al usar autenticación integrada de Windows junto con el protocolo de autenticación Kerberos en IIS 7.0 y el tema sobre implementación del control de acceso.

Problemas de SPN duplicados o ausentes y autenticación Kerberos

Al configurar la autenticación Kerberos, es fácil configurar por error nombres principales de servicio duplicados, sobre todo si se usa SetSPN -A o la herramienta de edición de ADSI (adsiedit.msc) para crear los SPN. La recomendación general es usar SetSPN -S para crear SPN porque el modificador -S buscará un SPN duplicado antes de crear el SPN especificado.

Si sospecha tener SPN duplicados en el entorno, use el comando SetSPN -X para consultar todos los SPN duplicados en el entorno (Windows 2008 o posterior únicamente). Si se devuelve algún SPN, debe investigar por qué se registraron los SPN y eliminar cualquier SPN duplicado y que no sea necesario. Si tiene dos servicios que se ejecutan con dos identidades distintas y ambos usan el mismo SPN (problema de SPN duplicado), debe volver a configurar uno de esos servicios para que use un SPN distinto o comparta una identidad de servicio común.

Si sospecha que un SPN no se ha registrado, o que no se ha registrado con el formato requerido, puede usar SetSPN -Q <insert SPN> para consultar la existencia de determinado SPN.

Tamaño máximo de token de Kerberos

En algunos entornos, los usuarios pueden ser miembros de varios grupos de Active Directory, lo que puede aumentar el tamaño de sus vales de Kerberos. Si los vales se vuelven demasiado grandes, puede haber un error en la autenticación Kerberos. Para obtener más información acerca de cómo ajustar el tamaño máximo de token, vea la nueva solución para problemas con autenticación Kerberos cuando los usuarios pertenecen a varios grupos (https://support.microsoft.com/kb/327825/es-es).

Nota

Al ajustar el tamaño máximo de token, tenga en cuenta que si configura el tamaño máximo de token más allá del valor máximo para la configuración del registro, pueden aparecer errores de autenticación Kerberos. Se recomienda no superar 65535 decimal, FFFF hexadecimal, para el tamaño máximo de token.

Revisiones de autenticación Kerberos para Windows Server 2008 y Windows Vista

Se produce un error en la autenticación Kerberos junto con el código de error 0X80090302 o 0x8009030f en un equipo que ejecuta Windows Server 2008 o Windows Vista cuando se usa el algoritmo AES (https://support.microsoft.com/kb/969083/es-es).

Puede que necesite instalar una revisión para la autenticación Kerberos en todos los equipos que ejecutan Windows Server 2008 o Windows Vista en el entorno. Esto incluye todos los equipos que ejecutan SharePoint Server 2010, SQL Server o Windows Server 2008 con los que SharePoint Server intenta autenticarse mediante la autenticación Kerberos. Siga las instrucciones en la página de soporte técnico para aplicar la revisión si experimenta los síntomas documentados en el caso de soporte.