Planear la autenticación Kerberos en SharePoint Server
SE APLICA A:
2013 2016 2019 Subscription Edition 
SharePoint en Microsoft 365
El protocolo es compatible con un método de autenticación que usa vales proporcionados por un origen de confianza. Los vales de Kerberos indican que se han autenticado las credenciales de red de un usuario asociado con un equipo cliente. El protocolo Kerberos define el modo en que los usuarios interactúan con un servicio de red para obtener acceso a los recursos de la red. El centro de distribución de claves (KDC) de Kerberos emite un vale de concesión de vales (TGT) a un equipo cliente en nombre de un usuario. En Windows, el equipo cliente es un miembro de un dominio de servicios de dominio de Active Directory (AD DS) y el TGT es la prueba de que el controlador de dominio ha autenticado las credenciales del usuario.
Antes de establecer una conexión de red a un servicio de red, el equipo cliente presenta su TGT al KDC y solicita un vale de servicio. Según el TGT emitido anteriormente, que confirma que el equipo cliente se ha autenticado, el KDC emite un vale de servicio en el equipo cliente. El equipo cliente envía el vale de servicio para el servicio de red. El vale de servicio también debe contener un nombre principal de servicio aceptable (SPN) que identifique al servicio. Para habilitar la autenticación Kerberos, los equipos cliente y servidor ya deben tener una conexión de confianza con el KDC. Tanto el equipo cliente como el cliente servidor deben ser capaces de obtener acceso a AD DS.
Autenticación Kerberos y SharePoint Server
Las razones por las que debería plantearse el uso de la autenticación Kerberos son las siguientes:
El protocolo Kerberos es el protocolo de autenticación integrada de Windows más sólido y es compatible con características de seguridad avanzada incluido el cifrado Estándar de cifrado avanzado (AES) y la autenticación mutua de clientes y servidores.
El protocolo Kerberos permite la delegación de credenciales de cliente.
Entre los métodos de autenticación segura disponibles, Kerberos requiere la menor cantidad posible de tráfico de red hacia los controladores de dominio AD DS. Kerberos puede reducir la latencia de páginas en determinados escenarios o aumentar el número de páginas que un servidor front-end web puede servir en determinados escenarios. Kerberos también puede reducir la carga en los controladores de dominio.
Kerberos es un protocolo abierto compatible en muchas plataformas y proveedores.
Las razones por las que la autenticación Kerberos puede no ser apropiada son las siguientes-.
A diferencia de otros métodos de autenticación, la autenticación Kerberos requiere una configuración adicional de infraestructura y entorno para funcionar correctamente. En muchos casos, se requiere el permiso de administrador de dominio para configurar la autenticación Kerberos, que puede ser difícil de configurar y administrar. Una configuración incorrecta de Kerberos puede impedir la autenticación satisfactoria en los sitios.
La autenticación Kerberos requiere conectividad del equipo cliente a un centro KDC y a un controlador de dominio de Servicios de dominio de Active Directory (AD DS). En una implementación de Windows, el KDC es un controlador de dominio AD DS. Si bien se trata de una configuración de red común en una intranet de empresa, las implementaciones orientadas a Internet no suelen configurarse de este modo.
Delegación Kerberos
La autenticación Kerberos es compatible con la delegación de la identidad del cliente. Esto significa que un servicio puede suplantar la identidad de un cliente autenticado. La suplantación permite a un servicio pasar la identidad autenticada a otros servicios de la red en nombre del cliente. La autenticación basada en notificaciones también puede usarse para delegar credenciales de cliente, pero requiere que la aplicación back-end sea compatible con notificaciones.
Usada con SharePoint Server, la delegación Kerberos permite a un servicio front-end autenticar a un cliente y luego usar la identidad del cliente para autenticarse en un sistema back-end. El sistema back-end lleva a cabo entonces su propia autenticación. Cuando un cliente usa la autenticación Kerberos para autenticarse con un servicio front-end, puede usarse la delegación Kerberos para pasar la identidad de un cliente a un sistema back-end. El protocolo Kerberos admite dos tipos de delegación:
Delegación Kerberos básica (sin restricciones)
Delegación Kerberos con restricciones
Delegación Kerberos básica y delegación Kerberos con restricciones
La delegación Kerberos básica puede cruzar los límites del domino dentro del mismo bosque, pero no puede cruzar el límite del bosque. La delegación Kerberos restringida no puede cruzar los límites de dominio ni los límites de bosque, excepto cuando utiliza los controladores de dominio que ejecutan Windows Server 2012.
En función de las aplicaciones de servicio que formen parte de una implementación de SharePoint Server, la implementación de la autenticación Kerberos con SharePoint Server puede requerir el uso de la delegación Kerberos con restricciones.
Importante
Para implementar la autenticación Kerberos con cualquiera de las siguientes aplicaciones de servicio, SharePoint Server y todos los orígenes de datos externos deben residir en el mismo dominio de Windows: > Excel Services > PerformancePoint Services > InfoPath Forms Services > Visio Services > Estas aplicaciones de servicio no están disponibles en SharePoint Foundation 2013. Servicios de Excel no está disponible en SharePoint Server 2016.
Para implementar la autenticación Kerberos con cualquiera de las aplicaciones o productos de servicio siguientes, SharePoint Server puede usar la delegación Kerberos básica o la delegación Kerberos con restricciones:
Servicio de conectividad a datos empresariales (esta aplicación de servicio no está disponible en SharePoint Foundation 2013)
Servicios de Access (esta aplicación de servicio no está disponible en SharePoint Foundation 2013)
SQL Server Reporting Services (SSRS) (un producto independiente)
Project Server 2016 (un producto independiente)
Los servicios habilitados para la autenticación Kerberos pueden delegar la identidad varias veces. Mientras una identidad se desplaza de un servicio a otro, el método de delegación puede cambiar de la delegación Kerberos básica a delegación Kerberos con restricciones. Sin embargo, el cambio no es posible en sentido inverso. El método de delegación no puede cambiar de delegación Kerberos con restricciones a delegación Kerberos básica. Por consiguiente, es importante anticipar y planear si un servicio back-end va a requerir delegación Kerberos básica. Esto puede afectar la planeación y el diseño de los límites de dominio.
Un servicio habilitado para Kerberos puede usar la transición de protocolo para convertir una identidad que no sea Kerberos en una identidad Kerberos que pueda delegarse a otros servicios habilitados para Kerberos. Esta capacidad puede usarse, por ejemplo, para delegar una identidad que no sea Kerberos de un servicio front-end a una identidad Kerberos de un servicio back-end.
Importante
La transición de protocolo requiere la delegación Kerberos con restricciones. Por lo tanto, las identidades de la transición de protocolos no pueden cruzar los límites de dominio.
La autenticación basada en notificaciones puede usarse como alternativa a la delegación Kerberos. Este tipo de autenticación permite pasar la notificación de autenticación de un cliente entre servicios distintos si los servicios cumplen los criterios siguientes:
Debe haber una relación de confianza entre los servicios
Los servicios deben ser compatibles con notificaciones.
Para obtener más información sobre la autenticación Kerberos, vea los siguientes recursos:
Autenticación Kerberos y autenticación basada en notificaciones
SharePoint 2013 y SharePoint Server 2016 son compatibles con la autenticación basada en notificaciones. La autenticación basada en notificaciones se basa en Windows Identity Foundation (WIF), que es un conjunto de clases de .NET Framework que se usan para implementar la identidad basada en notificaciones. La autenticación basada en notificaciones depende de estándares como WS-Federation y WS-Trust. Para obtener más información sobre la autenticación basada en notificaciones, vea los siguientes recursos:
Al crear una aplicación web de UNRESOLVED_TOKEN_VAL(SharePoint Server) mediante Administración central, debe seleccionar uno o más tipos de autenticación basada en notificaciones. Cuando crea una aplicación web de UNRESOLVED_TOKEN_VAL(SharePoint Server) mediante el cmdlet New-SPWebApplication de PowerShell de Microsoft, puede especificar autenticación de notificaciones y tipos de autenticación de notificaciones, o bien autenticación de modo clásico. La autenticación basada en notificaciones se recomienda para todas las aplicaciones web de UNRESOLVED_TOKEN_VAL(SharePoint Server). Al usar la autenticación basada en notificaciones, todos los tipos de autenticación compatibles están disponibles para sus aplicaciones web, y puede aprovechar la autenticación de servidor a servidor y la autenticación de aplicaciones. Para obtener más información, consulte What's new in authentication for SharePoint Server 2013.
Importante
The following service applications in SharePoint Server require the translation of claims-based credentials to Windows credentials. Este proceso de traducción usa notificaciones al servicio de token de Windows (C2WTS): >Servicios de Excel>PerformancePoint Services>InfoPath Forms Services>Visio Services>> Estas aplicaciones de servicio no están disponibles en SharePoint Foundation 2013. Excel Services is not available in SharePoint Server 2016.
Las aplicaciones de servicio que requieren que el C2WTS deben utilizar la delegación Kerberos restringida, debido a que C2WTS requiere la transición de protocolos, que solo es compatible con la delegación restringida de Kerberos. Para las aplicaciones de servicio en la lista anterior, el C2WTS traduce las notificaciones dentro de la granja en las credenciales de Windows para la autenticación de salida. Es importante entender que estas aplicaciones de servicio pueden utilizar solo el C2WTS si el método de autenticación entrante es el modo de notificaciones de Windows o el modo clásico de Windows. Las aplicaciones de servicios a las que se tiene acceso a través de las aplicaciones web y que utilizan las notificaciones de lenguaje de marcado de aserción de seguridad (SAML) o las notificaciones de autenticación basada en formularios no utilizan el C2WTS. Por lo tanto, no pueden convertir las notificaciones en credenciales de Windows.
La autenticación Kerberos y el nuevo modelo de aplicación de SharePoint
Si está utilizando el modo de notificaciones de Windows para la autenticación de usuario y la aplicación web está configurada para utilizar solo la autenticación Kerberos sin recurrir a NTLM como protocolo de autenticación, la autenticación de aplicaciones no funcionará. Para obtener más información, consulte Planear la autenticación de aplicaciones en SharePoint Server.
Vea también
Conceptos
Planear los métodos de autenticación de usuario en SharePoint Server