Información general acerca de la autenticación Kerberos para Productos de Microsoft SharePoint 2010

 

Se aplica a: SharePoint Server 2010

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

Productos de Microsoft SharePoint 2010 presenta mejoras significativas en la forma de administrar la identidad en la plataforma. Es muy importante comprender cómo afectan estos cambios al diseño de la solución y a la configuración de la plataforma para habilitar escenarios que requieren la delegación de la identidad del usuario a sistemas integrados. El protocolo Kerberos versión 5 desempeña un papel clave para habilitar la delegación y a veces puede ser necesario en estos escenarios.

Esta serie de artículos proporciona información que le ayudará a:

• Comprender los conceptos de identidad en Productos de SharePoint 2010

• Obtener información acerca de cómo la autenticación Kerberos desempeña un importante papel en escenarios de autenticación y delegación

• Identificar las situaciones en las que la autenticación Kerberos debe aprovecharse o puede ser necesaria en los diseños de soluciones

• Configurar la autenticación Kerberos descentralizada dentro del entorno, incluidos los escenarios que usan varias aplicaciones de servicio en SharePoint Server

• Probar y validar que la autenticación Kerberos está correctamente configurada y que funciona como se esperaba

• Encontrar herramientas y recursos adicionales para configurar la autenticación Kerberos en su entorno

Esta serie de artículos se divide en dos secciones principales:

• Información general de la autenticación Kerberos en Productos de SharePoint 2010

  Este artículo contiene información conceptual acerca de cómo administrar la identidad en Productos de SharePoint 2010, el protocolo Kerberos y cómo la autenticación Kerberos desempeña un papel clave en las soluciones de SharePoint 2010.

• Configuración detallada

  En esta serie de artículos se describen los pasos necesarios para configurar la autenticación y delegación Kerberos en varios escenarios de soluciones de SharePoint.

¿Quiénes deberían leer estos artículos acerca de la autenticación Kerberos?

La identidad y delegación en Productos de SharePoint 2010 es un tema muy amplio, con muchos aspectos y niveles de dificultad. Esta serie de artículos aborda el tema desde el punto de vista conceptual y técnico y está dirigida a diferentes destinatarios:

De principio a fin

"Necesito saberlo todo acerca de la identidad y la autenticación Kerberos en Productos de SharePoint 2010"

Si acaba de empezar y está aprendiendo acerca de los Productos de SharePoint 2010, la autenticación Kerberos y la autenticación basada en notificaciones, le conviene leer la primera sección de este documento. Cubre los conceptos básicos de identidad y delegación y ofrece una introducción acerca de la autenticación basada en notificaciones y Kerberos. Asegúrese de seguir los vínculos a los artículos externos e información adicional para contar con una base sólida de conocimientos antes de continuar con los artículos sobre configuración detallada.

Actualización desde Office SharePoint Server 2007

"Quiero saber qué ha cambiado respecto de la versión 2007 y para qué debería prepararme al actualizar a la versión 2010"

Si ya tiene un entorno de Microsoft Office SharePoint Server 2007 configurado para usar autenticación y delegación Kerberos, debe leer los siguientes artículos:

• Escenarios de identidad en Productos de SharePoint 2010

• Introducción a las notificaciones

• Cambios en la autenticación Kerberos en Windows 2008 R2 y Windows 7

• Cambios en la configuración de Kerberos en Productos de SharePoint 2010

• Consideraciones para tener en cuenta al actualizar desde Office SharePoint Server 2007

Si tiene más preguntas acerca de cómo configurar la delegación para un escenario o una función concretos, lea los artículos sobre configuración detallada, especialmente las listas de comprobación de configuración. Esto le ayudará a asegurarse de que su entorno está configurado correctamente después de la actualización.

Tutorial detallado

"Quiero obtener instrucciones detalladas acerca de cómo configurar la delegación Kerberos en SharePoint Server y en las aplicaciones de servicio de SharePoint Server aplicables"

Los artículos sobre configuración detallada cubren varios escenarios de Productos de SharePoint 2010 que pueden configurarse mediante la delegación Kerberos. Cada escenario se describe detalladamente e incluye una lista de comprobación de configuración e instrucciones detalladas para ayudarle a configurar correctamente la autenticación Kerberos en su entorno. Se tratarán los siguientes escenarios:

• Escenario 1: Configuración básica

• Escenario 2:Autenticación Kerberos para OLTP de SQL

• Escenario 3:Autenticación Kerberos para SQL Analysis Services

• Escenario 4:Delegación de identidad para SQL Reporting Services

• Escenario 5:Delegación de identidad para Servicios de Excel

• Escenario 6:Delegación de identidad para PowerPivot para SharePoint 2010

• Escenario 7:Delegación de identidad para Servicios de Visio

• Escenario 8:Delegación de identidad para Performance Point Services

• Escenario 9:Delegación de identidad para Servicios de conectividad empresarial

Asegúrese de leer con atención el primer escenario de configuración básico ya que es un requisito previo para todos los escenarios que siguen.

Entornos de Productos de SharePoint 2010 existentes

"Tengo un entorno de Productos de SharePoint 2010 y no puedo lograr que funcione la autenticación Kerberos. ¿Cómo hago para validar y depurar la configuración?"

Los artículos sobre configuración detallada contienen varias listas de comprobación que le ayudarán a evaluar el entorno en diversos escenarios. Preste especial atención al Escenario 1, Configuración básica, que trata sobre las herramientas y técnicas básicas para evaluar los errores de la configuración Kerberos.

Escenarios de identidad en Productos de SharePoint 2010

Al aprender acerca de la identidad en el contexto de la autenticación en Productos de SharePoint 2010, puede observar conceptualmente cómo la plataforma controla la identidad en tres escenarios principales: autenticación entrante, autenticación inter/intra-granja de servidores y autenticación saliente.

Identidad entrante

El escenario de autenticación entrante representa el medio en el que un cliente presenta su identidad a la plataforma o, en otras palabras, se autentica con la aplicación web o el servicio web. SharePoint Server usa la identidad del cliente para autorizarlo a acceder a recursos protegidos de SharePoint Server, como páginas web, documentos, etc.

Productos de SharePoint 2010 admite dos modos de autenticación de un cliente en la plataforma: el modo clásico y el modo basado en notificaciones.

Modo clásico

El modo clásico permite los métodos de autenticación de Internet Information Services (IIS) típicos con los que quizá ya esté familiarizado en versiones anteriores de SharePoint Server. Cuando una aplicación web de SharePoint Server 2010 está configurada para usar el modo clásico, tiene la opción de usar los siguientes métodos de autenticación de IIS:

Autenticación integrada de Windows

La autenticación integrada de Windows permite a los clientes de Windows autenticarse perfectamente con SharePoint Server sin tener que proporcionar manualmente credenciales (nombre de usuario y contraseña). Los usuarios que acceden a SharePoint Server desde Internet Explorer se autenticarán con las credenciales con las que se está ejecutando el proceso de Internet Explorer. De manera predeterminada, estas son las credenciales con las que el usuario inició sesión en el escritorio. Los servicios o aplicaciones que tienen acceso a SharePoint Server en el modo integrado de Windows intentan autenticarse con las credenciales del subproceso en ejecución que, de manera predeterminada, es la identidad del proceso.

NTLM

NT LAN Manager (NTLM) es el protocolo predeterminado cuando se selecciona la autenticación integrada de Windows. Este protocolo aprovecha una secuencia de desafío-respuesta de tres partes para autenticar a los clientes. Para obtener más información sobre NTLM, vea el tema sobre Microsoft NTLM (https://go.microsoft.com/fwlink/?linkid=196643&clcid=0xC0A).

Ventajas:

• Es fácil de configurar y normalmente no requiere ninguna configuración de infraestructura/entorno adicional para funcionar.

• Funciona cuando el cliente no forma parte del dominio, o no está en un dominio de confianza para el dominio en el que SharePoint Server reside.

Inconvenientes:

• Requiere que SharePoint Server se ponga en contacto con el controlador de dominio cada vez que una respuesta de autenticación de cliente necesita validación, lo que aumenta el tráfico a los controladores de dominio.

• No permite la delegación de credenciales del cliente para sistemas back-end, lo que también se conoce como regla de salto doble.

• Es un protocolo propietario.

• No admite la autenticación de servidor.

• Se considera menos segura que la autenticación Kerberos

Protocolo Kerberos

Kerberos es un protocolo más seguro que admite la autenticación mediante vales. Un servidor de autenticación Kerberos concede un vale en respuesta a una solicitud de autenticación de un equipo cliente si la solicitud contiene credenciales de usuario válidas y un nombre principal de servicio (SPN) válido. A continuación, el equipo cliente usa el vale para tener acceso a los recursos de la red. Para habilitar la autenticación Kerberos, los equipos cliente y servidor deben tener una conexión de confianza con el centro de distribución de claves (KDC) del dominio. El KDC distribuye claves secretas compartidas para habilitar el cifrado. Los equipos cliente y servidor también deben poder acceder a los servicios de directorio de Active Directory. En el caso de Active Directory, el dominio raíz del bosque es el centro de referencias de autenticación Kerberos. Para obtener más información sobre el protocolo Kerberos, vea el tema sobre el funcionamiento del protocolo de autenticación Kerberos versión 5 (https://go.microsoft.com/fwlink/?linkid=196644&clcid=0xC0A) y el tema sobre Microsoft Kerberos. (https://go.microsoft.com/fwlink/?linkid=196645&clcid=0xC0A).

Ventajas:

• Un protocolo de autenticación integrada de Windows más seguro

• Permite la delegación de credenciales de cliente

• Admite la autenticación mutua de clientes y servidores

• Genera menos tráfico en controladores de dominio

• Protocolo abierto compatible con muchas plataformas y proveedores

Inconvenientes:

• Requiere una configuración adicional de la infraestructura y el entorno para funcionar correctamente

• Requiere que los clientes tengan conectividad con el KDC (controlador de dominio de Active Directory en entornos de Windows) a través del puerto TCP/UDP 88 (Kerberos) y el puerto TCP/UDP 464 (Kerberos Change Password – Windows)

Otros métodos

Además de las autenticaciones NTLM y Kerberos, SharePoint Server admite otros tipos de autenticación IIS, como, por ejemplo, autenticación básica, implícita y basada en certificado, que no se cubren en este documento. Para obtener más información sobre el funcionamiento de estos protocolos, vea el tema sobre métodos de autenticación admitidos en IIS 6.0 (IIS 6.0) (https://go.microsoft.com/fwlink/?linkid=196646&clcid=0xC0A).

Autenticación basada en notificaciones

La compatibilidad con la autenticación basada en notificaciones es una característica nueva de Productos de SharePoint 2010 y se basa en Windows Identity Foundation (WIF). En un modelo basado en notificaciones, SharePoint Server acepta una o varias notificaciones sobre un cliente de autenticación para identificar y autorizar al cliente. Las notificaciones se realizan en forma de tokens SAML y son datos sobre el cliente especificados por una autoridad de confianza. Por ejemplo, una notificación puede especificar: ”Carlos pertenece al grupo Administradores empresariales del dominio Contoso.com."Si esta notificación proviene de un proveedor de confianza de SharePoint Server, la plataforma podría usar esta información para autenticar a Carlos y autorizarlo a obtener acceso a recursos de SharePoint Server. Para obtener más información sobre la autenticación basada en notificaciones, vea la guía sobre el control de identidad y acceso basado en notificaciones (https://go.microsoft.com/fwlink/?linkid=187911&clcid=0xC0A).

El tipo de notificaciones que admite Productos de SharePoint 2010 para la autenticación entrante son notificaciones de Windows, notificaciones de autenticación basada en formularios y notificaciones SAML.

Notificaciones de Windows

En el inicio de sesión con el modo de notificaciones de Windows, SharePoint Server autentica el cliente mediante la autenticación integrada de Windows estándar (NTLM/Kerberos) y, a continuación, convierte la identidad de Windows resultante en una identidad de notificaciones.

Notificaciones de autenticación basada en formularios

En el modo de notificaciones de autenticación basada en formularios, SharePoint Server redirige el cliente a una página de inicio de sesión que hospeda los controles de inicio de sesión ASP.NET estándar. La página autentica el cliente mediante proveedores de pertenencia y roles ASP.NET, de forma similar al funcionamiento de la autenticación basada en formularios en Office SharePoint Server 2007. Después de crear el objeto de identidad que representa al usuario, SharePoint Server convierte dicha identidad en un objeto de identidad de notificaciones.

Notificaciones SAML

En el modo de notificaciones SAML, SharePoint Server acepta los tokens SAML de un proveedor de tokens de seguridad (STS) externo de confianza. Cuando el usuario intenta iniciar una sesión, se le dirige a un proveedor de notificaciones externo (por ejemplo, el proveedor de notificaciones Windows Live ID) que autentica el usuario y produce un token SAML. SharePoint Server acepta y procesa este token y, de esa forma, aumenta las notificaciones y crea un objeto de identidad de notificaciones para el usuario.

Para obtener más información sobre la autenticación basada en notificaciones en Productos de SharePoint 2010, vea el tema sobre identidad basada en notificaciones de SharePoint.

Nota acerca de la autenticación basada en notificaciones entrante y las Notificaciones del servicio de token de Windows (C2WTS)

Algunas aplicaciones de servicio requieren el uso de Notificaciones del servicio de token de Windows (C2WTS) Windows Identity Foundation (WIF) para convertir las notificaciones del conjunto o granja de servidores en credenciales de Windows para la autenticación saliente. Es importante entender que C2WTS solo funciona si el método de autenticación entrante es el modo clásico o el de notificaciones de Windows. Si se configuraron las notificaciones, C2WTS requiere solo notificaciones de Windows; la aplicación web no puede usar varias formas de notificaciones en la aplicación web, ya que, de lo contrario, C2WTS no funcionará.

Identidad en un entorno de Productos de SharePoint 2010

Los entornos de Productos de SharePoint 2010 usan autenticación basada en notificaciones para las comunicaciones intra/inter-granja de servidores con la mayoría de las aplicaciones de servicio de SharePoint y los productos integrados de SharePoint independientemente del mecanismo de autenticación entrante usado. Esto significa que, incluso en los casos en que se use autenticación clásica para autenticar una aplicación web determinada, Productos de SharePoint convierte la identidad entrante en una identidad basada en notificaciones para autenticarse con aplicaciones de servicios de SharePoint y productos para notificaciones. Mediante la estandarización del modelo de notificaciones para comunicaciones intra/inter-granja de servidores, la plataforma puede abstraerse de los protocolos entrantes que se usen.

Identidad saliente

La identidad saliente en Productos de SharePoint 2010 representa los escenarios en los que los servicios de la granja de servidores deben autenticarse con sistemas y servicios de línea de negocio externos. Según el escenario, la autenticación puede realizarse en uno de los dos modelos conceptuales básicos:

Subsistema de confianza

En el subsistema de confianza, el servicio front-end autentica y autoriza al cliente y, a continuación, se autentica con servicios back-end adicionales sin pasar la identidad del cliente al sistema back-end. El sistema back-end confía en el servicio front-end para realizar la autenticación y autorización en su nombre. La forma más habitual de implementar este modelo es usar la cuenta de servicio compartida para autenticarse con el sistema externo:

En SharePoint Server, este modelo se puede implementar de varias maneras:

• Mediante la identidad del grupo de aplicaciones de IIS. Normalmente, se consigue mediante la ejecución de código en la aplicación web que eleva los permisos mientras realiza una llamada a un sistema externo. Otros métodos, como, por ejemplo, RevertToSelf, también pueden usar la identidad del grupo de aplicaciones para autenticarse con sistemas externos.

• Mediante una cuenta de servicio. Normalmente, se consigue mediante el almacenamiento de credenciales de la aplicación en el almacenamiento seguro y, a continuación, mediante dichas credenciales para autenticarse con un sistema externo. Otros métodos incluyen almacenar las credenciales de cuenta de servicio de otras maneras, como cadenas de conexión incrustadas.

• Mediante autenticación anónima. En ese caso, el sistema externo no requiere autenticación. Por lo tanto, el servicio front-end de SharePoint Server no debe pasar ninguna identidad al sistema back-end.

Delegación

En el modelo de delegación, el servicio front-end primero autentica el cliente y, a continuación, usa la identidad de este para autenticarse con otro sistema back-end que realiza su propia autenticación y autorización:

En Productos de SharePoint 2010, este modelo se puede implementar de varias maneras:

• Delegación Kerberos: si el cliente se autentica con el servicio front-end mediante autenticación Kerberos, se puede usar la delegación Kerberos para pasar la identidad del cliente al sistema back-end.

• Notificaciones: la autenticación basada en notificaciones permite pasar las notificaciones del cliente entre servicios mientras haya confianza entre los dos servicios y ambos sean compatibles con notificaciones.

Delegación a través de límites de dominios y bosques

Los escenarios de esta serie de artículos acerca de la autenticación Kerberos requieren que el servicio de SharePoint Server y los orígenes de datos externos se encuentren en el mismo dominio de Windows. Esto es necesario para la delegación limitada de Kerberos. El protocolo Kerberos admite dos tipos de delegación: básica (no limitada) y limitada. La delegación Kerberos básica puede cruzar los límites del dominio dentro de un solo bosque, pero no puede cruzar el límite del bosque, independientemente de la relación de confianza. La delegación limitada de Kerberos no puede cruzar los límites de dominios ni de bosques en ningún caso.

Algunos servicios de SharePoint Server pueden configurarse para que usen delegación Kerberos básica, pero otros servicios requieren el uso de delegación limitada. Cualquier servicio que se base en Notificaciones del servicio de token de Windows (C2WTS) debe usar delegación limitada de Kerberos para permitir que C2WTS use la transición a protocolo Kerberos para convertir las notificaciones a credenciales de Windows.

Los siguientes productos y aplicaciones de servicio requieren C2WTS y delegación limitada de Kerberos:

• Servicios de Excel

• PerformancePoint Services

• InfoPath Forms Services

• Servicios de Visio

Los siguientes productos y aplicaciones de servicio no están afectados por estos requisitos y, por lo tanto, pueden usar delegación básica, si fuera necesario:

• Servicio de conectividad a datos empresariales y Servicios de conectividad empresarial de Microsoft

• Servicios de Access

• Microsoft SQL Server Reporting Services (SSRS)

• Microsoft Project Server 2010

La siguiente aplicación de servicio no permite la delegación de credenciales de cliente y, por lo tanto, no está afectada por estos requisitos:

• Microsoft SQL Server PowerPivot para Microsoft SharePoint

Introducción a las notificaciones

Para ver una introducción a los conceptos de notificaciones y autenticación basada en notificaciones, vea la introducción a las notificaciones (https://go.microsoft.com/fwlink/?linkid=196648&clcid=0xC0A) y el tema sobre la identidad basada en notificaciones de SharePoint (https://go.microsoft.com/fwlink/?linkid=196647&clcid=0xC0A).

Introducción al protocolo Kerberos

Para ver información general conceptual sobre el protocolo Kerberos, vea el tema sobre Microsoft Kerberos (Windows) (https://go.microsoft.com/fwlink/?linkid=196645&clcid=0xC0A), la explicación de Kerberos (https://go.microsoft.com/fwlink/?linkid=196649&clcid=0xC0A) y las preguntas sobre Kerberos al equipo de Directory Services para el administrador ocupado (https://go.microsoft.com/fwlink/?linkid=196650&clcid=0xC0A).

Ventajas del protocolo Kerberos

Antes de examinar los detalles de cómo se configura SharePoint Server (o cualquier aplicación web) para usar el protocolo Kerberos, hablemos acerca del protocolo Kerberos en general y por qué es conveniente usarlo.

Normalmente hay tres razones principales para usar el protocolo Kerberos:

1. Delegación de credenciales de cliente: el protocolo Kerberos permite que un servicio suplante la identidad de un cliente para permitir que el servicio de suplantación pase esa identidad a otros servicios de red en nombre del cliente. NTLM no permite esta delegación. (Esta limitación de NTLM se denomina "regla de salto doble"). La autenticación basada en notificaciones, como la autenticación Kerberos, se puede usar para delegar las credenciales de cliente, pero requiere que la aplicación back-end sea compatible con notificaciones.

2. Seguridad : ciertas características, como cifrado AES, autenticación mutua, compatibilidad con integridad y privacidad de datos, entre otras, hacen que el protocolo Kerberos sea más seguro que su homólogo NTLM.

3. Rendimiento potencialmente superior: la autenticación Kerberos requiere menos tráfico a los controladores de dominio que NTLM (según la verificación PAC, vea el blog del equipo de soporte técnico de Microsoft Open Specification sobre la validación de Microsoft Kerberos PAC). Si la verificación PAC está deshabilitada o no es necesaria, el servicio que autentica el cliente no debe realizar una llamada RPC al DC (vea el tema sobre retrasos en el proceso de autenticación del usuario al ejecutar un programa de servidor de alto volumen en un miembro de dominio en Windows 2000 o Windows Server 2003). La autenticación Kerberos también requiere menos tráfico entre el cliente y el servidor en comparación con NTLM. Los clientes pueden autenticarse con servidores web en dos solicitudes/respuestas en lugar de usar el típico protocolo de enlace triple con NTLM. No obstante, esta mejora por lo general no se observa en redes de baja latencia en cada transacción, sino en el rendimiento general del sistema. Recuerde que muchos factores ambientales pueden afectar al rendimiento de la autenticación; por lo tanto, es aconsejable probar el rendimiento de la autenticación Kerberos y NTLM en su entorno antes de determinar cuál ofrece el mejor rendimiento.

Esta es una lista de algunas de las ventajas de usar el protocolo Kerberos. Existen otras razones, como la autenticación mutua, la interoperabilidad entre plataformas y la confianza transitiva entre dominios, entre otras. Sin embargo, en la mayoría de los casos la delegación y la seguridad son los principales factores determinantes para la adopción del protocolo Kerberos.

Delegación Kerberos, delegación limitada y transición de protocolos

El protocolo Kerberos versión 5 de la plataforma Windows admite dos tipos de delegación de identidad: delegación básica (no limitada) y delegación limitada:

Tipo	Ventajas	Inconvenientes
Delegación básica	Puede cruzar los límites del dominio dentro del mismo bosque Requiere menos configuración que la delegación limitada.	No es compatible con la transición de protocolos Es segura. Si el servicio front-end no funciona correctamente, la identidad del cliente puede delegarse a cualquier servicio del bosque que acepte la autenticación Kerberos.
Delegación limitada	Puede realizar la transición de un protocolo de autenticación entrante que no sea Kerberos (por ejemplo, NTLM a Kerberos, notificaciones a Kerberos) Más segura. Solo se pueden delegar las identidades al servicio especificado.	No puede cruzar los límites del dominio Requiere configuración adicional

Los servicios habilitados para Kerberos pueden delegar la identidad varias veces entre varios servicios y saltos. Mientras una identidad se desplaza de un servicio a otro, el método de delegación puede cambiar de básico a limitado, pero no en sentido inverso. Este es un detalle de diseño importante de entender: si un servicio back-end requiere delegación básica (por ejemplo, para delegar fuera de un límite de dominio), todos los servicios que están delante del servicio back-end deben usar delegación básica. Si un servicio front-end usa delegación limitada, el servicio back-end no puede cambiar el token limitado por un token no limitado para cruzar un límite de dominio.

La transición de protocolos permite que un servicio de autenticación habilitado para Kerberos (servicio front-end) convierta una identidad que no sea de Kerberos en una identidad de Kerberos que se pueda delegar a otros servicios habilitados para Kerberos (servicio back-end). La transición de protocolos requiere delegación limitada de Kerberos y, por lo tanto, las identidades de la transición de protocolos no pueden cruzar los límites del dominio. Según los derechos de usuario del servicio front-end, el vale de Kerberos que devuelve la transición de protocolos puede ser un token de identificación o un token de suplantación. Para obtener más información acerca de la delegación limitada y la transición de protocolos, vea los artículos siguientes:

• Transición de protocolos y delegación limitada de Kerberos (https://technet.microsoft.com/es-es/library/cc739587(ws.10).aspx)

• Suplemento técnico de transición de protocolos con delegación limitada (https://msdn.microsoft.com/es-es/library/ff650469.aspx)

• La delegación limitada de Kerberos puede requerir transición de protocolos en escenarios de varios saltos (https://support.microsoft.com/kb/2005838/es-es)

Como procedimiento recomendado general, si es necesaria la delegación Kerberos, se debe usar la delegación limitada, siempre que sea posible. Si se requiere la delegación fuera de los límites del dominio, todos los servicios en la ruta de acceso de delegación deben usar delegación básica.

Cambios en la autenticación Kerberos en Windows 2008 R2 y Windows 7

Windows Server 2008 R2 y Windows 7 presentan nuevas características en la autenticación Kerberos. Para ver información general sobre estos cambios, vea el tema sobre cambios en la autenticación Kerberos (https://go.microsoft.com/fwlink/?linkid=196655&clcid=0xC0A) y el tema sobre mejoras en Kerberos (https://go.microsoft.com/fwlink/?linkid=196656&clcid=0xC0A). Además, debería familiarizarse con la autenticación de modo kernel de IIS 7.0 (Configuración de autenticación de modo kernel de Internet Information Services (IIS) 7.0, (https://go.microsoft.com/fwlink/?linkid=196657&clcid=0xC0A)) aunque no sea compatible con granjas de servidores de SharePoint Server.

Cambios en la configuración de Kerberos en Productos de SharePoint 2010

La mayoría de los conceptos básicos de configuración de la autenticación Kerberos de Productos de SharePoint 2010 no han sufrido cambios. Aún es necesario configurar los nombres principales de servicio y las opciones de delegación en las cuentas de equipo y de servicio. Sin embargo, hay varios cambios que se deben tener en cuenta:

• Delegación limitada: es obligatoria para los servicios que usan Notificaciones del servicio de token de Windows. La delegación limitada es necesaria para permitir que la transición de protocolos convierta las notificaciones en tokens de Windows.

• Aplicaciones de servicio: en Office SharePoint Server 2007, los servicios SSP requieren SPN especiales y cambios en el el Registro del servidor para habilitar la delegación. En Productos de SharePoint 2010, las aplicaciones de servicio usan la autenticación basada en notificaciones y Notificaciones del servicio de token de Windows, por lo que estos cambios ya no son necesarios.

• Windows Identity Foundation (WIF): las notificaciones del servicio de token de Windows de WIF es un nuevo servicio que Productos de SharePoint 2010 aprovecha para convertir las notificaciones en tokens de Windows para escenarios de delegación.

Consideraciones para tener en cuenta al actualizar desde Office SharePoint Server 2007

Si está actualizando una granja de servidores de Office SharePoint Server 2007 a SharePoint Server 2010, hay varias cosas que debe tener en cuenta al realizar la actualización:

• Si las aplicaciones web cambian de direcciones URL, asegúrese de actualizar los nombres principales de servicio para reflejar los nombres DNS.

• Elimine los nombres principales del servicio SSP, ya que no son necesarios en SharePoint Server 2010.

• Inicie Notificaciones del servicio de token de Windows en los servidores que ejecutan aplicaciones de servicio que requieren delegación (por ejemplo, Servicios de Excel, Servicio de gráficos de Visio).

• Configure la delegación limitada de Kerberos como "Usar cualquier protocolo de autenticación" para permitir la delegación limitada de Kerberos con C2WTS.

• Asegúrese de que la autenticación de modo kernel está deshabilitada en IIS.