Problemas conocidos de la configuración de Kerberos (SharePoint Server 2010)
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:
Internet Explorer 6 no puede usar el protocolo de autenticación Kerberos para conectarse con un sitio web que usa un puerto no estándar en Windows XP y Windows Server 2003 (https://support.microsoft.com/kb/908209/es-es)
Configuración de la autenticación Kerberos (Office SharePoint Server 2007) (https://go.microsoft.com/fwlink/?linkid=196987&clcid=0xC0A)
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
http://server.contoso.com:5000 AppPool Id: contoso\svcA
http://server.contoso.com:5001 AppPool Id: contoso\svcB
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:
Ejecutar todas las aplicaciones web bajo una cuenta de servicio compartida
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:
Desactivar la autenticación de modo kernel
Configurar HTTP.sys para que use la identidad del grupo de aplicaciones de IIS al descifrar vales de servicio. Vea el tema sobre configuración de la autenticación de modo kernel de Internet Information Services (IIS) 7.0.
Puede que también necesite una revisión al configurar HTTP.sys para que use las credenciales del grupo de aplicaciones: REVISIÓN: Se recibe un mensaje de error Stop 0x0000007e en una pantalla azul cuando el atributo AppPoolCredentials se establece en true y se usa una cuenta de dominio como identidad del grupo de aplicaciones en IIS 7.0
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.