Share via


Planear la conectividad de Microsoft 365 con SharePoint Server

SE APLICA A:yes-img-132013 yes-img-162016 yes-img-192019 yes-img-seSubscription Edition yes-img-sopSharePoint in Microsoft 365

Este artículo está diseñado para ayudarle a planear y prepararse para configurar la conectividad entrante de Microsoft 365 para empresas a SharePoint Server a través de un dispositivo proxy inverso. Esto es necesario para los siguientes entornos híbridos:

  • Búsqueda híbrida de entrada (que muestra los resultados de la búsqueda de SharePoint Server en Microsoft 365)

  • Solución híbrida de Servicios de conectividad empresarial

En este artículo se proporciona la información que necesita saber, como los requisitos previos, y una hoja de cálculo para recopilar la información necesaria antes de comenzar el proceso de configuración.

Este tema le ayudará a realizar lo siguiente:

  • Comprender los requisitos previos y condiciones de la conectividad entrante

  • Planear la arquitectura de su aplicación web

  • Planear los certificados SSL

  • Registrar la información y las decisiones claves

Recopilar y registrar la información de la hoja de cálculo el registro de compilación

Hoja de cálculo. Durante el proceso de planeación, tiene que recopilar información y archivos. Es importante usar la hoja de cálculo híbrida de SharePoint para realizar un seguimiento de la información de planeamiento e implementación como referencia y para compartirla con otros miembros del equipo de implementación. No podemos enfatizar lo suficiente la importancia de usar esta hoja de cálculo para organizar la información antes de comenzar el proceso de configuración.

Crear un registro de compilación. Como en cualquier proyecto de implementación complejo, es muy importante contar con un registro detallado de todas las decisiones de diseño, configuración de servidores, procedimientos, resultados de los comandos y errores como referencia para solucionar problemas, soporte y detección. Le recomendamos especialmente que documente el proceso de implementación.

Precaución

Por motivos de seguridad, almacene la hoja de cálculo y el registro de compilación en un lugar mejorado por la seguridad, como un recurso compartido de archivos protegido o SharePoint en la biblioteca de documentos de Microsoft 365, y conceda permisos solo a los administradores que participan en el proceso de implementación y deben conocer esta información.

Recopilar y registrar la información de direcciones URL y nombres de host

En esta sección, registrará la información sobre las direcciones URL y nombres de host de su entorno. Esta información se usará durante el proceso de implementación.

  • Registre el nombre de dominio DNS público de su empresa (por ejemplo, adventureworks.com).

  • Registre la dirección URL del punto de conexión accesible desde el público del dispositivo proxy inverso que usará para el dispositivo híbrido de SharePoint. Esta es la dirección URL externa. Si este punto de conexión aún no existe, tendrá que decidir cuál será esta dirección URL.

  • Registre la dirección IP del extremo externo del dispositivo de proxy inverso.

  • Asegúrese de que en la zona pública de búsqueda directa del DNS de su dominio público, existe un registro A (también conocido como registro de host) que asigna la dirección URL externa a la dirección IP del extremo accesible desde Internet del dispositivo de proxy inverso. Si aún no tiene este registro A, créelo ahora.

  • Asegúrese de que existe un registro A en la zona de búsqueda directa dns de la intranet que asigna el nombre de host de la granja de servidores de SharePoint a su dirección IP. Si aún no tiene este registro A, créelo ahora.

    Importante

    Si configura direcciones URL internas para acceder a la aplicación web durante el proceso de implementación, asegúrese de crear también registros A para esas direcciones URL en la zona de búsqueda directa de DNS, y regístrelos en la hoja de cálculo.

   
Icono Editar Registre la siguiente información en la tabla 3 de la hoja de cálculo SharePoint Hybrid:
El nombre de dominio del dominio DNS corporativo de acceso público en la fila Public Internet Domain name.
La dirección URL del extremo de acceso público del dispositivo de proxy inverso en la fila External URL.
La dirección IP del extremo externo del dispositivo de proxy inverso en la fila IP Address of the external endpoint.

Planear la arquitectura de su aplicación web

Esta sección le ayuda a planear la arquitectura de las aplicaciones web de SharePoint Server que usará en su entorno híbrido.

La conectividad entrante requiere un canal de comunicación seguro entre la granja de servidores de SharePoint Server local y SharePoint en Microsoft 365. Los datos se intercambian entre una colección de sitios en SharePoint en Microsoft 365 y una aplicación web local a través de este canal de comunicación.

SharePoint en Microsoft 365 envía solicitudes a un servidor proxy inverso que retransmite las solicitudes a una aplicación web específica en la granja de servidores de SharePoint Server local que está configurada para el entorno híbrido de SharePoint. Nos referimos a ella como la aplicación web principal.

Sugerencia

Independientemente de cuántas soluciones híbridas tenga planeado configurar, normalmente solo usará una aplicación web principal. No es necesario crear aplicaciones web principales adicionales para cada solución híbrida adicional.

Tanto la aplicación web principal como una colección de sitios única dentro de la aplicación web principal deben configurarse para aceptar conexiones entrantes desde SharePoint en Microsoft 365.

El administrador de SharePoint asocia los servicios y los objetos de conexión necesarios para admitir las soluciones híbridas que se implementan con la aplicación web principal. Las conexiones salientes se pueden realizar desde cualquier aplicación web local de SharePoint Server mediante las configuraciones específicas de la característica.

Una aplicación web de SharePoint Server se compone de un sitio web de Internet Information Services (IIS) que actúa como una unidad lógica para las colecciones de sitios que se crean. Cada aplicación web está representada por un sitio web de IIS diferente que tiene un grupo de aplicaciones único o compartido, con una dirección URL pública única, y que también se puede configurar para usar hasta cinco direcciones URL internas con asignación de acceso alternativa (AAM). Una aplicación web determinada se asocia con una única base de datos de contenido y se configura para que use un método de autenticación para conectarse a la base de datos. Se pueden configurar varias aplicaciones web para que usen métodos de autenticación diferentes, y opcionalmente AAM, para proporcionar acceso a una única base de contenido.

La dirección URL pública de una aplicación web siempre se usa como dirección URL raíz en todos los vínculos a sitios y contenido a los que se accede a través de la aplicación web. Considere la posibilidad de una aplicación web con la dirección URL https://spexternal.adventureworks.com pública que tiene una dirección URL https://sharepoint interna configurada en AAM. Al ir a la dirección URL https://sharepointinterna, SharePoint Server devuelve el sitio web con la dirección URL https://spexternal.adventureworks.comy todos los vínculos dentro del sitio tendrán direcciones URL basadas en esa ruta de acceso.

La asignación de acceso alternativa (AAM) solo es necesaria si se configura una conectividad entrante que usa una colección de sitios basada en la ruta de acceso con una dirección URL diferente de la dirección URL externa. AAM le permite asociar la dirección URL externa a la dirección URL interna de un sitio de SharePoint en Microsoft 365 dentro de su organización. Esto permite a SharePoint Server enrutar las solicitudes de direcciones URL internas configuradas en AAM a la aplicación web principal correspondiente.

Para obtener más información sobre las aplicaciones web basadas en notificaciones, vea Crear aplicaciones web basadas en notificaciones en SharePoint Server.

Para obtener más información sobre cómo ampliar una aplicación web, vea Extensión de aplicaciones web basadas en notificaciones en SharePoint.

Para obtener más información sobre las colecciones de sitios, vea Información general sobre sitios y colecciones de sitios en SharePoint Server.

Elegir una estrategia de colección de sitios

Antes de decidir usar una aplicación web existente o de crear una nueva, debe comprender los requisitos de configuración que la aplicación web y la colección de sitios deben cumplir para admitir la funcionalidad híbrida. Use la información de esta sección para determinar su estrategia para crear una aplicación web y una colección de sitios nuevas, o para determinar si se puede usar una colección de sitios de una aplicación web existente en su entorno híbrido.

La figura siguiente muestra el flujo de decisión para determinar la estrategia de colección de sitios.

Las tres estrategias de recopilación de sitios posibles para una topología de autenticación híbrida de SharePoint unidireccional o de entrada bidireccional.

Requisitos para aplicaciones web híbridas

Las aplicaciones web que se usan para la funcionalidad híbrida deben cumplir todos estos requisitos:

  • La dirección URL pública de la aplicación web debe ser idéntica a la dirección URL externa.

    El protocolo OAuth proporciona autorización de usuarios en soluciones híbridas de SharePoint. El encabezado de solicitud host de todas las comunicaciones de SharePoint en Microsoft 365 a SharePoint local contiene la dirección URL a la que se envió originalmente la solicitud. Para autenticar las solicitudes entrantes de SharePoint en Microsoft 365, el servicio de autenticación de SharePoint local debe ser capaz de hacer coincidir esta dirección URL en todo el tráfico de SharePoint en Microsoft 365 con la dirección URL pública de la aplicación web principal. Esta es la dirección URL externa. Una ventaja de usar una colección de sitios con nombre de host para entornos híbridos de SharePoint es que puede configurar una colección de sitios con nombre de host para que use la misma dirección URL que la dirección URL externa. Así se elimina la necesidad de configurar asignación de acceso alternativa.

  • La aplicación web debe poder configurarse para usar autenticación de Windows integrada con NTLM.

    La autenticación de Windows integrada con NTML es un requisito de las aplicaciones web que se implementan en escenarios que admiten autenticación de servidor a servidor y autenticación de aplicaciones. Para más información, vea Planear la autenticación de servidor a servidor en SharePoint Server.

    Tipos de autenticación de notificaciones para un entorno híbrido de SharePoint

Requisitos de configuraciones de colección de sitios específicas

Las colecciones de sitios que se usan en la funcionalidad híbrida deben cumplir todos estos requisitos y también deben existir o crearse en una aplicación web que cumpla los requisitos de la aplicación web.

  • Colecciones de sitios con nombre de host

    • La aplicación web debe admitir colecciones de sitios denominados host.

      Para crear una colección de sitios con nombre de host, la aplicación web debe crearse para habilitarlos. No puede habilitar esta funcionalidad después de haber creado la aplicación web.

      Para obtener más información sobre cómo crear una colección de sitios con nombre de host, vea Arquitectura e implementación de colecciones de sitios con nombre de host en SharePoint Server.

      Nota:

      Aunque es un requisito de la aplicación web, se incluye aquí porque se aplica únicamente a entornos que tienen colecciones de sitios denominados host.

    • El servidor DNS local debe configurarse con DNS dividido. Debe crear una zona de búsqueda directa para el dominio de Internet público que usó para la dirección URL pública y un registro A (host) en la zona de búsqueda directa que tenga la dirección IP de SharePoint Server y el nombre de host de la dirección URL externa.

      Importante

      El dispositivo proxy inverso debe poder resolver los nombres de host de esta zona de búsqueda directa para retransmitir las solicitudes entrantes a la granja de servidores de SharePoint Server.

  • Colecciones de sitios basadas en la ruta de acceso

    • Si la dirección URL pública es idéntica a la dirección URL externa

      El servidor DNS local debe configurarse con DNS dividido. Debe crear una zona de búsqueda directa para el dominio de Internet público que usó para la dirección URL pública y un registro A en la zona de búsqueda directa que tenga la dirección IP de SharePoint Server y el nombre de host de la dirección URL externa.

      Importante

      El dispositivo proxy inverso debe poder resolver los nombres de host de esta zona de búsqueda directa para retransmitir las solicitudes entrantes a la granja de servidores de SharePoint Server.

      Esta es una manera fácil de configurar una aplicación web para un entorno híbrido de SharePoint. El objetivo es que el campo Dirección URL pública de la nueva aplicación web coincida con la dirección URL del extremo de acceso público del dispositivo de proxy inverso, que también se conoce como dirección URL externa.

    • Si la dirección URL pública es diferente de la dirección URL externa

      Debe configurar una asignación de acceso alternativa (AAM) para retransmitir las solicitudes entrantes de SharePoint en Microsoft 365.

      Amplíe la aplicación web principal y use la dirección URL externa como Dirección URL pública. Después, cree la dirección URL interna (mediante Add Internal URLs) en la misma zona de seguridad que la aplicación web ampliada para usarla como dirección URL puente. También configurará el dispositivo de proxy inverso para retransmitir las solicitudes entrantes de SharePoint en Microsoft 365 a esta dirección URL de puente.

      Recuerde que la asignación de acceso alternativa (AAM) solo es necesaria si se configura una conectividad entrante que usa una colección de sitios basada en la ruta de acceso con una dirección URL diferente de la dirección URL externa.

Nota:

Recuerde que la dirección URL externa es la dirección URL del extremo accesible desde Internet del dispositivo de proxy inverso.

   
Icono Editar Registre la estrategia de colección de sitios elegida en la hoja de cálculo, en la fila Site collection strategy de la tabla 2.

Elegir una aplicación web existente o crear una nueva

Puede usar una aplicación web existente o crear una nueva para usarla como aplicación web principal.

Si prefiere administrar la aplicación web usada para la funcionalidad híbrida de forma independiente o si su aplicación web existente no cumple los requisitos enumerados en la sección Elegir una estrategia de colección de sitios, debe crear una nueva aplicación web.

   
Icono Editar Registre su decisión en la fila New or existing web application de la tabla 2.

Planear el uso de una aplicación web existente

Si decide usar una aplicación web existente como aplicación web principal, recopile la dirección URL de la aplicación web principal y la dirección URL de la colección de sitios de nivel superior, y anótelas en la hoja de cálculo.

   
Icono Editar Registre la siguiente información en la hoja de cálculo:
Según su estrategia de colección de sitios, registre la dirección URL de la aplicación web principal en la fila Primary web application URL de las tablas 5a, 5b o 5c.
Si va a usar una colección de sitios con nombre de host, registre la dirección URL de la colección de sitios de nivel superior en la fila Host-named site collection URL de la tabla 5a.

Planear el uso de una nueva aplicación web

Si decide crear una nueva aplicación web, le indicaremos cómo hacerlo cuando esté configurando la topología híbrida.

Planear los certificados SSL

Los certificados SSL establecen la identidad del servidor y proporcionan autenticación de certificado para los diferentes servicios y conexiones de un entorno híbrido de SharePoint. Debe tener dos certificados SSL: un certificado SSL de canal seguro y un certificado STS.

Para obtener más información sobre cómo se usan los certificados SSL en entornos híbridos de SharePoint, vea Topología híbrida de SharePoint 2013: modelo de certificado y autenticación.

Nota:

Si elige ayudar a proteger su granja de servidores de SharePoint local con SSL, necesitará también un certificado SSL para la aplicación web principal. No hay consideraciones específicas híbridas para este certificado, por lo que puede seguir los procedimientos recomendados generales para configurar SharePoint Server con SSL.

Nota:

"Canal seguro" no es una clase de certificado; usamos el término como una manera de diferenciar este certificado concreto de otros certificados SSL usados en el entorno.

Acerca de los certificados SSL de canal seguro

Un certificado SSL de canal seguro proporciona autenticación y cifrado para el canal de comunicación seguro entre el dispositivo de proxy inverso y Microsoft 365, actuando como un servidor y un certificado de cliente. También comprueba la identidad del punto de conexión de proxy inverso que se usa para publicar la colección de sitios de SharePoint Server local.

Este certificado debe ser un certificado comodín o un certificado SAN, y ser emitido por una entidad de certificación raíz pública. El campo Sujeto de este certificado debe contener el nombre de host del extremo externo del servidor proxy inverso, o una dirección URL comodín que abarque todos los nombres de host del espacio de nombres. Debe usar el cifrado de 2048 bits como mínimo.

Importante

Los certificados comodín solo protegen un nivel de un espacio de nombres de DNS. Por ejemplo, si la dirección URL externa es https://spexternal.public.adventureworks.com, el asunto del certificado comodín debe ser *.public.adventureworks.com, no *.adventureworks.com.

En escenarios en los que SharePoint en Microsoft 365 está configurado para solicitar información a SharePoint Server, se requiere un certificado SSL para hacer lo siguiente:

  • Cifrar el tráfico del canal de seguridad.

  • Permitir que el dispositivo de proxy inverso autentique las conexiones entrantes usando la autenticación de certificado.

  • Permitir que SharePoint en Microsoft 365 identifique y confíe en el punto de conexión externo.

Durante la implementación, instalará el certificado SSL en el dispositivo de proxy inverso y en una aplicación de destino de Almacenamiento seguro de Microsoft 365 en SharePoint. Esto se configura durante la configuración de la infraestructura del entorno híbrido.

Obtener un certificado SSL de canal seguro

Obtenga un certificado SAN o comodín SSL de canal seguro (nombre alternativo del firmante) para el dominio público local de una entidad de certificación conocida, por ejemplo, DigiCert, VeriSign, Thawte o GeoTrust.

Nota:

Este certificado debe admitir varios nombres y debe ser de 2048 bits como mínimo. Los certificados suelen expirar en intervalos de un año. Por lo tanto, es importante planear de antemano las renovaciones de certificados para evitar interrupciones del servicio. Los administradores de SharePoint deben programar un recordatorio para el reemplazo de certificados que le proporcione suficiente tiempo de entrega para evitar una interrupción del trabajo.

Acerca de los certificados STS

El certificado STS de la granja de servidores de SharePoint local requiere un certificado predeterminado para validar los tokens entrantes. En un entorno híbrido de SharePoint, Microsoft Entra id. actúa como un servicio de firma de tokens de confianza y usa el certificado STS como certificado de firma. Si decide usar un certificado distinto del certificado STS predeterminado (por ejemplo, un certificado de una entidad de certificación pública), reemplace el certificado predeterminado antes de comenzar el proceso de configuración híbrida.

Registrar las cuentas necesarias para configuración y pruebas

Una configuración de entorno híbrido de SharePoint requiere varias cuentas de usuario tanto en el Active Directory local como en el directorio de Microsoft 365 (identificador de Microsoft Entra que aparece en el directorio de Microsoft 365). Estas cuentas tienen diferentes permisos y pertenencias a grupos o roles. Algunas de las cuentas se usan para implementar y configurar software, y otras se necesitan para probar funcionalidades específicas para ayudar a garantizar que los sistemas de autenticación y seguridad funcionan según lo previsto.

  • Vaya a Accounts needed for hybrid configuration and testing para ver una explicación detallada de las cuentas de usuario necesarias, así como notas sobre los proveedores de identidad y roles.

  • Registre la información necesaria de la cuenta en la hoja de cálculo como se indica.

  • Vuelva a este artículo de planificación cuando haya terminado este paso.

Pasos siguientes

Llegado a este punto, debe haber rellenado completamente la hoja de cálculo necesaria para la conectividad entrante, y estar listo para comenzar el proceso de configuración. El siguiente paso es elegir una guía básica de configuración.