Planear los métodos de autenticación de usuario en SharePoint Server

SE APLICA A:2013 2016 2019 Subscription Edition SharePoint en Microsoft 365

Obtenga información sobre los tipos y los métodos de autenticación de usuario que admite SharePoint Server y sobre cómo determinar los que debe usar para las zonas y las aplicaciones web.

Obtenga información sobre la autenticación de SharePoint en Microsoft 365.

Introducción

La autenticación de usuario es la validación de la identidad de un usuario frente a un proveedor de autenticación, que es un directorio o una base de datos que contiene las credenciales del usuario y puede confirmar que el usuario las envió correctamente. Un ejemplo de un proveedor de autenticación es Servicios de dominio de Active Directory (AD DS). Otras formas de autenticación para el proveedor son el directorio de usuarios y el almacén de atributos.

Un método de autenticación es un intercambio específico de credenciales de cuenta y otra información que afirma la identidad de un usuario. El resultado del método de autenticación es la prueba, normalmente en forma de un token que contiene las notificaciones, de que un proveedor de autenticación ha autenticado a un usuario.

Un tipo de autenticación es una forma específica de validar las credenciales consultando a uno o más proveedores de autenticación, a veces mediante un protocolo estándar del sector. Un tipo de autenticación puede utilizar varios métodos de autenticación.

Después de validar la identidad de un usuario, el proceso de autorización determina los sitios, el contenido y demás características a los que puede obtener acceso el usuario.

El planeamiento de métodos y tipos de autenticación de usuario debe determinar lo siguiente:

• Los tipos de autenticación de usuario y métodos para cada zona y aplicación web

• La infraestructura de autenticación necesaria para admitir los tipos y métodos de autenticación determinados

  Nota:

  La autenticación en modo clásico de Windows ya no se admite en SharePoint Server 2016, SharePoint Server 2019 y SharePoint Server Subscription Edition.

Autenticación basada en notificaciones

La identidad de usuario en AD DS se basa en una cuenta de usuario. Para la autenticación correcta, el usuario proporciona el nombre de cuenta y la prueba de que conoce la contraseña. Para determinar el acceso a los recursos, las aplicaciones deben consultar a AD DS para obtener los atributos de cuenta y otra información, como la pertenencia al grupo o el rol en la red. Aunque esta funcionalidad funciona bien para entornos windows, no se escala horizontalmente a proveedores de autenticación de terceros y entornos de varios proveedores que admiten modelos informáticos basados en Internet, asociados o en la nube.

Con identidades basadas en notificaciones, un usuario obtiene un token de seguridad firmado digitalmente de un proveedor habitual de la identidad de confianza. El token contiene un conjunto de notificaciones. Cada notificación representa un elemento específico de datos sobre los usuarios, como sus nombres, pertenencias a grupos y rol en la red. La autenticación basada en notificaciones es la autenticación de usuario que usa la infraestructura y las tecnologías de la identidad basada en notificaciones. Las aplicaciones que admiten la autenticación basada en notificaciones obtienen un token de seguridad de un usuario, en lugar de credenciales y utilizan la información de las notificaciones para determinar el acceso a los recursos. No se necesita ninguna consulta independiente a un servicio de directorio como AD DS.

La autenticación basada en notificaciones en Windows se construye en Windows Identity Foundation (WIF), que es un conjunto de clases de.NET Framework que se utilizan para implementar la identidad basada en notificaciones. La autenticación basada en notificaciones se basa en estándares como WS-Trust, WS-Federation y protocolos tales como el lenguaje de marcado de aserción de seguridad (SAML).

Para obtener más información sobre la autenticación basada en notificaciones, vea los siguientes recursos:

• Identidad basada en notificaciones para Windows (notas del producto)

• Página principal de Windows Identity Foundation

Debido al uso generalizado de la autenticación basada en notificaciones para la autenticación de usuario, la autenticación de servidor a servidor y la autenticación de la aplicación, se recomienda la autenticación basada en notificaciones para todas las zonas y aplicaciones web de una granja de servidores de SharePoint Server. Para obtener más información, consulte Planear la autenticación de servidor a servidor en SharePoint Server. Al usar la autenticación basada en notificaciones, todos los métodos de autenticación compatibles están disponibles para las aplicaciones web y puede aprovechar las nuevas características y escenarios de SharePoint Server que usan la autenticación de servidor a servidor y la autenticación de la aplicación.

Para la autenticación basada en notificaciones, SharePoint Server cambia automáticamente todas las cuentas de usuario a las identidades de notificaciones. Este cambio da como resultado un token de seguridad (también conocido como token de notificaciones) para cada usuario. El token de notificaciones contiene las notificaciones relativas al usuario. Las cuentas de Windows se convierten en notificaciones de Windows. Los usuarios de pertenencias basadas en formularios se transforman en notificaciones de autenticación basadas en formularios. SharePoint Server puede usar las notificaciones incluidas en los tokens basados en SAML. Además, los desarrolladores y administradores de SharePoint pueden aumentar los tokens de usuario con más notificaciones. Por ejemplo, las cuentas de usuario de Windows y las cuentas basadas en formularios se pueden aumentar con notificaciones adicionales que usa SharePoint Server.

No es necesario ser un arquitecto de notificaciones para usar la autenticación basada en notificaciones en SharePoint Server. Sin embargo, la implementación de la autenticación basada en token SAML requiere la coordinación con los administradores de su entorno basado en notificaciones, tal como se describe en el Plan para la autenticación basada en token de SAML.

Autenticación de modo clásico en SharePoint Server 2013

En SharePoint 2013, cuando cree una aplicación web en la Administración Central, puede especificar solo los tipos de autenticación y los métodos de autenticación basados en notificaciones. En versiones anteriores de SharePoint, también se podía configurar autenticación de modo clásico para las aplicaciones web en la Administración Central. La autenticación de modo clásico utiliza la autenticación de Windows y SharePoint 2013 trata las cuentas de usuario como cuentas de AD DS.

Para configurar una aplicación web para utilizar la autenticación de modo clásico, debe utilizar el cmdlet de New-SPWebApplication PowerShellpara crearla. Las aplicaciones web de Productos de SharePoint 2010 que están configuradas para la autenticación de modo clásico conservan su configuración de autenticación al actualizar a SharePoint 2013. Sin embargo, recomendamos que migre sus aplicaciones web a la autenticación basada en notificaciones antes de actualizar a SharePoint 2013.

Una granja de SharePoint 2013 puede incluir una combinación de aplicaciones web que utilizan ambos modos. Algunos servicios no diferencian entre las cuentas de usuario que son cuentas de Windows tradicionales y las cuentas de notificaciones de Windows.

Para obtener más información sobre la migración antes de actualizar, vea Migración desde el modo clásico a la autenticación basada en notificaciones.

Para obtener más información acerca de la migración después de actualizar, vea Migrate from classic-mode to claims-based authentication in SharePoint Server.

Para obtener información acerca de cómo crear aplicaciones web que utilizan la autenticación de modo clásico en SharePoint 2013, vea Crear aplicaciones web que utilizan autenticación de modo clásico en SharePoint Server. No se puede migrar una aplicación web que use la autenticación basada en notificaciones para usar la autenticación en modo clásico.

Tipos y métodos de autenticación compatibles

SharePoint Server admite varios métodos de autenticación y proveedores de autenticación para los siguientes tipos de autenticación:

• Autenticación de Windows

• Autenticación basada en formularios

• Autenticación basada en token SAML

Autenticación de Windows

El tipo de autenticación de Windows aprovecha las ventajas de su proveedor de autenticación de Windows existente (AD DS) y los protocolos de autenticación que usa un entorno de dominio de Windows para validar las credenciales de conexión de clientes. El método de autenticación de Windows, que se usa en la autenticación basada en notificaciones, incluye:

• NTLM

• Kerberos

• Implícita

• Básica

Para obtener más información, vea Planeación para la autenticación de Windows en este artículo.

Ver el vídeo sobre la autenticación de notificaciones de Windows en SharePoint 2013 y SharePoint Server 2016

Aunque no se trata de un tipo de autenticación de Windows, SharePoint Server también admite la autenticación anónima. Los usuarios pueden tener acceso a contenido de SharePoint sin validar sus credenciales. La autenticación anónima está deshabilitada de forma predeterminada. Normalmente se usa la autenticación anónima cuando se usa SharePoint Server para publicar contenido que no requiere seguridad y que está disponible para todos los usuarios, como un sitio web público de Internet.

Además de habilitar la autenticación anónima, también debe configurar el acceso anónimo (permisos) en sitios y recursos del sitio.

Autenticación basada en formularios

La autenticación basada en formularios es un sistema de administración de identidades basado en las notificaciones que se basa en la autenticación de proveedor de pertenencia y roles ASP.NET. La autenticación basada en formularios se puede usar con credenciales almacenadas en un proveedor de autenticación, como:

• AD DS

• Una base de datos como SQL Server

• Un almacén de datos de protocolo ligero de acceso a directorios (LDAP) como Novell eDirectory, Novell Directory Services (NDS) o Sun ONE

La autenticación basada en formularios valida a los usuarios en función de las credenciales que estos escriban en un formulario de inicio de sesión (normalmente una página web). Las solicitudes no autenticadas se redirigen a una página de inicio de sesión, donde un usuario debe proporcionar credenciales válidas y enviar el formulario. El sistema emite una cookie para las solicitudes autenticadas que contiene una clave para restablecer la identidad para las solicitudes posteriores.

Ver el vídeo sobre la autenticación de notificaciones basadas en formularios en SharePoint 2013 y SharePoint Server 2016

Para obtener más información, vea Planeación para la autenticación basada en formularios.

Autenticación basada en token SAML

La autenticación basada en token SAML en SharePoint Server usa el protocolo SAML 1.1 y el perfil de solicitante pasivo de WS-Federation (WS-F PRP). Requiere la coordinación con los administradores de un entorno basado en notificaciones, ya sea en su propio entorno interno o del socio. Si utiliza Active Directory Federation Services (AD FS) 2.0, tendrá un entorno de autenticación basado en un token SAML.

Un entorno de autenticación basado en token SAML incluye un servicio de token de seguridad de proveedor de identidad (IP-STS). El IP-STS emite tokens SAML en nombre de los usuarios cuyas cuentas se incluyen en el proveedor de autenticación asociado. Los tokens pueden incluir cualquier número de notificaciones acerca de un usuario, como un nombre de usuario y los grupos a los que este pertenece. Un servidor AD FS 2.0 es un ejemplo de un IP-STS.

SharePoint Server aprovecha las notificaciones que se incluyen en los tokens que el IP-STS emite para los usuarios autorizados. En los entornos de notificaciones, una aplicación que acepta tokens de SAML se conoce como un STS de usuario de confianza (RP-STS). Una aplicación de usuario de confianza recibe el token SAML y usa las notificaciones dentro del token para decidir si se va a otorgar acceso de cliente al recurso solicitado. En SharePoint Server, cada aplicación web que se ha configurado para usar un proveedor SAML se agrega al servidor IP-STS como entrada RP-STS independiente. Una granja de servidores de SharePoint puede representar varias entradas RP-STS en el IP-STS.

Ver el vídeo sobre la autenticación de notificaciones basadas en SAML en SharePoint 2013 y SharePoint Server 2016

El conjunto de proveedores de autenticación para la autenticación basada en token SAML depende del IP-STS en su entorno de notificaciones. Si usa AD FS 2.0, los proveedores de autenticación (conocidos como almacenes de atributos para AD FS 2.0) pueden incluir:

• Windows Server 2003 Active Directory y AD DS in Windows Server 2008

• Todas las ediciones de SQL Server 2005 y SQL Server 2008

• Almacenes de atributos personalizados

Para obtener más información, vea Planeación para la autenticación basada en token SAML.

Elección de los tipos de autenticación para los entornos LDAP

La autenticación basada en formularios o autenticación basada en token SAML, puede usar los entornos de LDAP. Use el tipo de autenticación que coincida con el entorno LDAP actual. Si aún no tiene un entorno LDAP, se recomienda usar la autenticación basada en formularios porque es menos compleja. Sin embargo, si su entorno de autenticación ya admite WS-Federation 1.1 y SAML 1.1, recomendamos SAML. SharePoint Server tiene un proveedor LDAP integrado.

Planear la autenticación de Windows

El proceso de planeación e implementación de los métodos de autenticación de Windows es similar para la autenticación basada en notificaciones. La autenticación basada en notificaciones para una aplicación web no aumenta la complejidad de implementar métodos de autenticación de Windows. En esta sección se resume la planeación de los métodos de autenticación de Windows.

NTLM y el protocolo Kerberos

Tanto NTLM como el protocolo Kerberos son métodos de autenticación integrada de Windows que permiten a los usuarios autenticarse sin problemas, sin que se les pida las credenciales. Por ejemplo:

• Los usuarios que tienen acceso a sitios de SharePoint desde el explorador de Internet utilizan las credenciales bajo las que se ejecuta el proceso de Internet Explorer para autenticarse. De forma predeterminada, estas credenciales son las credenciales que el usuario usó para iniciar sesión en el equipo.

• Los servicios o aplicaciones que utilizan los métodos de autenticación integrada de Windows para obtener acceso a los recursos de SharePoint intentarán utilizar las credenciales del subproceso en ejecución, que es la identidad del proceso de manera predeterminada para autenticarse.

NTLM es la forma más sencilla de implementar la autenticación de Windows y normalmente no requiere ninguna configuración adicional de la infraestructura de autenticación. Seleccione esta opción al crear o configurar la aplicación web.

El protocolo Kerberos admite la autenticación mediante vales. El uso del protocolo Kerberos requiere más configuración del entorno. 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. Para configurar el protocolo Kerberos es necesario configurar nombres principales de servicio (SPN) en AD DS antes de instalar SharePoint Server.

Los motivos por los que se debe tener en cuenta la autenticación Kerberos son los 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.

• El protocolo Kerberos es un protocolo abierto que admiten muchas plataformas y proveedores.

Los motivos por los que la autenticación Kerberos podría no ser apropiada son los siguientes:

• La autenticación Kerberos requiere más configuración de la infraestructura y del entorno para su buen funcionamiento que otros métodos de autenticación. En muchos casos, para configurar el protocolo Kerberos, se necesita permiso de administrador. La configuración y administración de la autenticación Kerberos pueden ser complejas. 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 KDC y a un controlador de dominio AD DS. En una implementación de Windows, el KDC es un controlador de dominio AD DS. Aunque esta configuración de red es común en una intranet de la organización, las implementaciones accesibles desde Internet normalmente no se configuran de esta manera.

Los pasos siguientes resumen la configuración de la autenticación Kerberos:

1. Configure la autenticación Kerberos para las comunicaciones de SQL Server mediante la creación de SPN en AD DS para la cuenta de servicio de SQL Server.

2. Cree SPN para las aplicaciones web que usarán autenticación Kerberos.

3. Instale la granja de servidores de SharePoint Server.

4. Configure servicios específicos dentro de la granja de servidores para usar cuentas específicas.

5. Cree las aplicaciones web que usarán autenticación Kerberos.

Implícita y Básica

Con el método de autenticación implícita, las credenciales de la cuenta de usuario se envían como una síntesis de un mensaje MD5 al servicio de Internet Information Services (IIS) en el servidor web que hospeda la zona o aplicación web. Con el método de autenticación básica, las credenciales de cuenta de usuario se envían como texto sin formato. Por lo tanto, no debe usar el método de autenticación básica a menos que también use SSL para cifrar el tráfico del sitio web.

Es posible que deba utilizar estos métodos de autenticación más antiguos si su entorno utiliza exploradores web o servicios que solo admiten la autenticación implícita o básica a los sitios web.

A diferencia de los métodos de autenticación NTLM, Kerberos y anónima, se configuran los métodos de autenticación básica e implícita de las propiedades del sitio web que corresponden a la aplicación web o la zona en el complemento de Internet Information Services (IIS).

Si usa la autenticación basada en notificaciones, consulte:

• Configurar la autenticación implícita para una aplicación web basada en notificaciones en SharePoint Server

• Configurar la autenticación básica para una aplicación web basada en notificaciones en SharePoint Server

Planeación para la autenticación basada en formularios

Para usar la autenticación basada en formularios para autenticar a los usuarios en un sistema de administración de identidades que no se basa en Windows o que es externo, debe registrar el proveedor de pertenencia y el administrador de roles en el archivo Web.config. SharePoint Server usa la interfaz de administrador de roles estándar de ASP.NET para recopilar información de grupo sobre el usuario actual. Cada rol ASP.NET se trata como un grupo de dominio por el proceso de autorización en SharePoint Server. Registre los administradores de roles en el archivo Web.config tal y como registra los proveedores de pertenencia para la autenticación.

Si desea administrar la pertenencia a usuarios o roles desde el sitio web de Administración central, debe registrar el proveedor de suscripciones y el Administrador de roles en el archivo Web.config para el sitio web de Administración central. Registre el proveedor de pertenencia y el administrador de roles en el archivo Web.config de la aplicación web que hospeda el contenido.

Para obtener instrucciones detalladas para configurar la autenticación basada en formularios, vea Configure forms-based authentication for a claims-based web application (Configurar la autenticación basada en formularios para una aplicación web basada en notificaciones en SharePoint Server).

Planeación para la autenticación basada en token SAML

La arquitectura para implementar proveedores basados en token SAML incluye los siguientes componentes:

• Servicio de token de seguridad de SharePoint Este servicio crea los tokens SAML que usa la granja de servidores. El servicio se crea e inicia automáticamente en todos los servidores de una granja de servidores. El servicio se usa para la comunicación entre granjas de servidores porque toda la comunicación entre granjas de servidores usa la autenticación basada en notificaciones. Este servicio también se usa para los métodos de autenticación que se implementan para las aplicaciones web que usan la autenticación basada en notificaciones. Estos métodos incluyen la autenticación de Windows, la autenticación basada en formularios y la autenticación basada en tokens saml.

• Certificado de firma de tokens (ImportTrustCertificate) Este certificado es el que se exporta desde un IP-STS y, a continuación, se copia en un servidor de la granja de servidores y se agrega a la lista de entidades raíz de confianza de la granja de servidores. Una vez que use este certificado para crear un SPTrustedIdentityTokenIssuer, no podrá usarlo para crear otro. Para usar el certificado para crear un objeto SPTrustedIdentityTokenIssuer diferente, primero debe eliminar el objeto existente. Antes de eliminar el objeto existente, debe desasociarlo de todas las aplicaciones web que puedan estar usándolo.

• Notificación de identidad La notificación de identidad es la notificación de un token SAML que funciona como identificador único del usuario. Solo el propietario de IP-STS conoce el valor en el token que siempre es exclusivo para cada usuario. La notificación de identidad se crea como una asignación de notificaciones habitual durante la asignación de todas las notificaciones deseadas. La notificación que debe funcionar como la notificación de identidad se determina al crear el objeto SPTrustedIdentityTokenIssuer.

• Otras notificaciones Estas notificaciones constan de notificaciones adicionales de un vale saml que describe a los usuarios. Estas notificaciones pueden incluir roles de usuario, grupos de usuarios u otros tipos de notificaciones como la edad. Todas las asignaciones de notificaciones se crean como objetos que se replican en todos los servidores de una granja de servidores de SharePoint Server.

• Dominio En la arquitectura de notificaciones de SharePoint, el identificador URI o la dirección URL que se asocia a una aplicación web de SharePoint configurada para usar un proveedor basado en token SAML representa un dominio. Al crear un proveedor de autenticación basado en SAML en la granja de servidores, debe especificar los dominios, o las direcciones URL de la aplicación web, que desea que IP-STS reconozca, uno cada vez. El primer dominio se especifica al crear el objeto SPTrustedIdentityTokenIssuer. Después de crear SPTrustedIdentityTokenIssuer, puede agregar dominios adicionales. Los dominios se especifican mediante una sintaxis similar a la siguiente: $realm = "urn:sharepoint:mysites". Después de agregar el dominio a SPTrustedIdentityTokenIssuer, debe crear un RP-STS de confianza con el dominio del servidor de IP-STS. Este proceso consiste en especificar la dirección URL de la aplicación web.

• SPTrustedIdentityTokenIssuer Este es el objeto que se crea en la granja de servidores de SharePoint que incluye los valores necesarios para comunicarse con IP-STS y recibir tokens de IP-STS. Al crear SPTrustedIdentityTokenIssuer, se especifica qué certificado de firma de tokens se va a usar, el primer dominio, la notificación que representa la notificación de identidad y cualquier otra notificación. Puede asociar un certificado de firma de tokens de un STS a un solo objeto SPTrustedIdentityTokenIssuer. Sin embargo, después de crear SPTrustedIdentityTokenIssuer, puede agregar más dominios para aplicaciones web adicionales. Después de agregar un dominio kerberos al objeto SPTrustedIdentityTokenIssuer, también deberá agregarlo al IP-STS como usuario de confianza. El objeto SPTrustedIdentityTokenIssuer se replica a través de todos los servidores de la granja de servidores de SharePoint Server.

• Servicio de token de seguridad de usuario de confianza (RP-STS) En SharePoint Server, cada aplicación web configurada para usar un proveedor SAML se agrega al servidor de IP-STS como una entrada de RP-STS. Una granja de servidores de SharePoint Server puede incluir varias entradas de RP-STS.

• Servicio de token de seguridad del proveedor de identidades (IP-STS) Este servicio es el token seguro uno del entorno de notificaciones que emite tokens SAML en nombre de los usuarios que se incluyen en el directorio de usuarios asociado.

En el siguiente diagrama se muestra la arquitectura de notificaciones de token SAML de SharePoint Server.

Arquitectura de notificaciones de token SAML

El objeto SPTrustedIdentityTokenIssuer se crea con varios parámetros, entre los que se incluyen:

• Una notificación de identidad.

• Un único parámetro SignInURL .

  El parámetro SignInURL especifica la dirección URL a la que se redirigirá una solicitud de usuario para autenticarse en ip-STS.

• Un único parámetro Wreply .

  Algunos servidores IP-STS requieren el parámetro Wreply , que se establece en true o false. "False" es el valor predeterminado. Use el parámetro Wreply solo si el IP-STS lo requiere.

• Múltiples dominios.

• Asignación de notificaciones múltiples.

Para implementar la autenticación basada en tokens saml con SharePoint Server, implemente los pasos siguientes que requieren planeamiento de antemano:

1. Exporte el certificado de firma de tokens de IP-STS. Copie el certificado en un equipo servidor de la granja de servidores de SharePoint Server.

2. Defina la notificación que se debe usar como identificador único del usuario. Esta notificación se conoce como notificación de identidad. Habitualmente se utiliza el nombre principal de usuario (UPN) o el nombre de correo electrónico del usuario como identificador de usuario. Coordine la operación con el administrador de IP-STS para determinar el identificador correcto, ya que solo el propietario de IP-STS conoce el valor en el token que siempre es exclusivo para cada usuario. Determinar el identificador único del usuario es parte del proceso de asignación de notificaciones. Utilice PowerShell de Microsoft para crear asignaciones de notificaciones.

3. Defina asignaciones de notificaciones adicionales. Defina las notificaciones adicionales del token entrante que usará la granja de servidores de SharePoint Server. Los roles de usuario son un ejemplo de notificación que se puede usar para asignar permisos a los recursos en la granja de servidores de SharePoint Server. Se descartarán todas las notificaciones de un token entrante que no tengan una asignación.

4. Use PowerShell para crear un nuevo proveedor de autenticación para importar el certificado de firma de tokens. Este proceso crea el objeto SPTrustedIdentityTokenIssuer. Durante este proceso, especifique la notificación de identidad y las notificaciones adicionales que ha asignado. Cree y especifique un dominio que esté asociado a las primeras aplicaciones web de SharePoint que va a configurar para la autenticación basada en tokens saml. Después de crear SPTrustedIdentityTokenIssuer, puede crear y agregar más dominios para aplicaciones web de SharePoint adicionales. Este procedimiento le permite configurar varias aplicaciones web para usar el mismo SPTrustedIdentityTokenIssuer.

5. Por cada dominio kerberos que agregue a SPTrustedIdentityTokenIssuer, deberá crear una entrada de RP-STS en IP-STS. Puede crear esta entrada antes de que exista la aplicación web de SharePoint. No obstante, debe planear la dirección URL antes de crear las aplicaciones web.

6. Para una aplicación web de SharePoint nueva o existente, configúrela para usar el proveedor de autenticación recientemente creado. El proveedor de autenticación aparece como proveedor de identidad de confianza en Administración central al crear la aplicación web.

Puede configurar varios proveedores de autenticación basados en tokens de SAML. Sin embargo, solo puede usar un certificado de firma de tokens una vez en una granja de servidores. Todos los proveedores configurados se muestran como opciones en Administración central. Las notificaciones de diferentes entornos de STS de confianza no entran en conflicto.

Si se implementa la autenticación basada en token SAML con una compañía asociada y su entorno incluye IP-STS, se recomienda que junto con el administrador de su entorno de notificaciones interno establezca una relación de confianza unidireccional desde el IP-STS interno hasta el STS del asociado. Este enfoque no requiere que agregue un proveedor de autenticación a la granja de servidores de SharePoint Server. También permite a los administradores de notificaciones administrar todo el entorno de notificaciones.

Para seguir los pasos detallados para configurar la autenticación basada en tokens de SAML con AD FS, vea Configure SAML-based claims authentication with AD FS in SharePoint Server (Configurar la autenticación de reclamaciones basada en SAML con ADFS en SharePoint Server).

Planeación de zonas para aplicaciones web

Las zonas representan diferentes rutas de acceso lógicas para obtener acceso a los mismos sitios en una aplicación web. Cada aplicación web puede incluir hasta cinco zonas. Al crear una aplicación web, Administración central crea la zona predeterminada. Para crear zonas adicionales, amplíe la aplicación web y seleccione uno de los restantes nombres de zona: intranet, extranet, Internet o personalizada.

El plan para las zonas dependerá de lo siguiente:

• Autenticación basada en notificaciones (recomendado): puede implementar varios proveedores de autenticación en una sola zona. También puede usar varias zonas.

Implementación de más de un tipo de autenticación en una sola zona

Si utiliza la autenticación basada en notificaciones e implementa más de un método de autenticación, se recomienda implementar varios métodos de autenticación en la zona predeterminada. El resultado es la misma dirección URL para todos los usuarios.

Cuando se implementan varios métodos de autenticación en la misma zona, se aplican las siguientes restricciones:

• puede implementar una única instancia de la autenticación basada en formularios en una zona.

• Administración central permite utilizar un método de autenticación integrada de Windows y básica al mismo tiempo. De lo contrario, no puede implementar más de un tipo de autenticación de Windows en una zona.

Si se configuran varios proveedores de autenticación basada en token SAML para una granja de servidores, aparecerán como opciones al crear una aplicación web o una zona nueva. En la misma zona, se pueden configurar varios proveedores SAML.

En el siguiente diagrama se muestran varios tipos de autenticación que se implementan en la zona predeterminada para un sitio de colaboración de asociados.

Varios tipos de autenticación que se implementan en la zona predeterminada

En el diagrama, los usuarios de almacenes de directorios diferentes utilizan la misma dirección URL para obtener acceso al sitio web asociado. Un cuadro de líneas discontinuas que rodea a las compañías asociadas muestra la relación entre el directorio de usuarios y el tipo de autenticación configurado en la zona predeterminada.

Planeación para el rastreo de contenido

El componente de rastreo requiere que NTLM obtener acceso al contenido. Para usar la autenticación NTLM, es necesario configurar al menos una zona. Si la autenticación NTLM no está configurada en la zona predeterminada, el componente de rastreo puede usar una zona diferente que esté configurada para usar la autenticación NTLM.

Implementación de más de una zona

Si tiene previsto implementar más de una zona para las aplicaciones web, utilice las siguientes pautas:

• Use la zona predeterminada para implementar la configuración de autenticación más segura. Si una solicitud no se puede asociar a una zona específica, se aplican la configuración de autenticación y otras directivas de seguridad de la zona predeterminada. La zona predeterminada es la que se crea al crear inicialmente una aplicación web. Normalmente, la configuración de autenticación más segura está diseñada para el acceso de usuarios finales. Por lo tanto, es probable que los usuarios finales accedan a la zona predeterminada.

• Use el número de zonas mínimo necesario para proporcionar acceso a los usuarios. Cada zona se asocia a un nuevo dominio y sitio de IIS para obtener acceso a la aplicación web. Agregue solo nuevos puntos de acceso cuando sean necesarios.

• Asegúrese de que al menos una zona esté configurada para usar la autenticación NTLM para el componente de rastreo. No cree una zona dedicada para el componente de índice a menos que sea necesario.

En el siguiente diagrama se muestran varias zonas que se implementan para incluir diferentes tipos de autenticación para un sitio de colaboración de asociados.

Una zona por cada tipo de autenticación

En el diagrama, la zona predeterminada se usa para los empleados remotos. Cada zona tiene una dirección URL diferente asociada. Los empleados usan una zona diferente en función de si trabajan en la oficina o si trabajan de forma remota.