¿Qué tienen los híbridos de Office 365 en común?

Híbridos

Cuando digo híbrido, me refiero a una cooperación de tecnologías que son propietarios de las aplicaciones que posee y administra en su empresa con las que administramos en nuestras nubes de Microsoft.

Esta definición funciona no solo con Azure sino también con la mayoría de las cargas de trabajo en Microsoft 365. Si no sabe qué es una carga de trabajo, por cierto, es una aplicación que se ejecuta en la Microsoft 365 plataforma en la nube: Skype empresarial online, Exchange Online y SharePoint Online son ejemplos. La "carga de trabajo" es una forma de mantenerlos diferenciados de sus homólogos locales, lo cual resulta útil para que la escritura y la conversación se confundan.

Las adaptaciones híbridas usan todos los recursos disponibles, sin importar dónde estén en vivo.

Recursos de hardware locales en común

Todos los híbridos sobre los que estoy hablando aquí conectan un entorno de cliente a través de Internet a Microsoft 365 (y Azure Active Directory (AAD) en segundo plano porque actúa como directorio para Microsoft 365 ). Es difícil configurar la infraestructura. A pesar de lo que pueda haber oído, no tiene un grado de "nada". De hecho, la mayoría de los híbridos funcionan de la misma manera con (en la mayoría de los casos) los mismos requisitos de hardware.

A partir de 2016 estos son los elementos que todos los híbridos necesitan. En caso de que las cosas sean opcionales, lo diré.

Todas Microsoft 365 cargas de trabajo híbridas tienen estas buenas características:

1. Algunos servidores locales (como una granja de servidores de SharePoint o un entorno de Skype empresarial).

2. Local de Active Directory donde los usuarios viven o están "alojados" (en S4B terminología).

3. Un servidor de Azure Active Directory Connect (AAD Connect) (que puede ser independiente o combinado con otro servidor, como WA-P). Esto se representa mediante el icono "sincronizar" porque se usa AAD Connect para sincronizar las cuentas de los locales con la nube en un entorno híbrido.

4. [Opcional] Un servidor proxy inverso, que, en todos mis ejemplos, será servidor proxy de aplicación web (WA-P).

5. [Opcional] También puede usar el servidor de Federación de Active Directory (o ADFS).

Además, los asistentes híbridos están integrados en cada carga de trabajo para ayudarle a asociarse con su nube para que pueda usar todas las herramientas de su disposición (independientemente de dónde estén).

Si no tiene ADFS, no tiene solicitudes de cumplimiento que lo requieran y no quiere tener la complejidad adicional, no lo use. AAD Connect está diseñado para realizar el trabajo (y el intervalo de replicación va de aproximadamente 3 horas a 30 minutos, que es una mejora útil para hacer).

Muchas empresas grandes tienen algunos de estos servidores instalados. Muchos controladores de dominio de Active Directory pueden tener servidores ADFS. Si está pensando en configurar un híbrido, es posible que desee consultar a otros administradores para averiguar qué recursos locales ya están en el lugar. Le ayudará a determinar si desea usar piezas de infraestructura existentes o nuevas.

¿Qué hacen estos servidores?

Omita esta sección si ya conoce lo que hacen estos servidores.

La mayoría de las personas están acostumbrados a las operaciones de Active Directory (AD), cómo enumera los usuarios y objetos de un dominio o un bosque (entre otras cosas) y, en el caso del híbrido, es una base de inicio para los usuarios que se replicarán en la nube de Microsoft. Los trabajos de sincronizar (AAD Connect), ADFS y WA-P (nuestro proxy inverso de ejemplo) son un poco más nuevos y más central para procesar solicitudes y identidades HTTPS híbridas, así que vamos a hablar de ellas.

ADFS

Para revisar, el trabajo de los servicios de Federación de Active Directory es ayudar a que ambos lados del híbrido se reconozcan entre sí y, por eso, Microsoft 365 va a conocer y confiar en el ADFS (o clúster de ADFS) al que pertenece un nombre de dominio público verificado. Esto permite el inicio de sesión único. Eso significa que cuando se muestra a los usuarios con un UPN asociado para autenticarse en los recursos en línea, Microsoft 365 va a conocer su UPN y el servidor de ADFS específico al que desea enviar los usuarios para la autenticación. Cuando Heidi@contoso.com pasa por el proceso de inicio de sesión de Exchange Online, Microsoft 365 va a enviar una solicitud a sus instalaciones para que ADFS pueda intervenir en la autenticación y confirmar a la persona que dice, o bien, denegarle. Esto puede suceder rápidamente si la configuración de la red y la configuración lo permite. ADFS se usa si desea aprovechar el inicio de sesión único: una vez que los usuarios inician sesión en una sesión de ADFS, el servidor de ADFS intercepta silenciosamente todas las demás solicitudes de autenticación (como sucede al cambiar entre cargas de trabajo, por ejemplo) para recordar Microsoft 365 que usted sigue siendo quien dice que es usted. Dado que algunos departamentos de TI tienen una configuración de seguridad de la información o cumplimiento que requiere contraseñas locales y otras no, ADFS es opcional.

Proxy inverso

Acceso web proxy es un proxy inverso (RP) que se ha integrado en sistemas operativos de Windows Server desde el lanzamiento del 2012 R2. Un proxy inverso es el punto de salida para actuar en nombre de su granja de servidores. Tiene un lado en la Internet y conoce el nombre de dominio público de su Microsoft 365 híbrido, y un lado que se acerca a su red de intranet o perimetral y conoce el nombre de dominio de los recursos internos (por ejemplo, la dirección URL de su sitio de SharePoint). Intercepta todas las solicitudes que entran en su empresa y le permite bloquear puertos, restringir el tráfico que aceptará de Internet y ocultar las direcciones URL e internas de su red del mundo exterior. Como todo RPs, es un proxy para los servidores internos de la red siempre que los usuarios de fuera de la red intenten llegar a un recurso.

Los híbridos de SharePoint 2013 usan un proxy inverso como WA-P para interceptar el tráfico entrante (de los usuarios de SPO que hacen consultas contra un índice de búsqueda local en el caso de la Federación de búsqueda), pero como los híbridos de SharePoint 2016 en la nube colocan el índice completo en la nube, el la siguiente generación ya no necesita una (que es el único motivo por el que se marca como opcional en los diagramas). Sin embargo, SharePoint 2013 no es el único lugar en el que verá un proxy inverso que se usa para interceptar el tráfico no solicitado proveniente de Internet. Skype empresarial 2016 usa una con la configuración de la periferia, y Exchange 2016 también usa una en su periferia. Como algunas situaciones lo requieren, WA-P es opcional.

Sincronizar

El gráfico que uso muestra "sincronizar" para Azure Active Directory Connect. En realidad, la sincronización que realiza AAD Connect implica el tránsito continuo de los usuarios y/o la información de usuario de su entorno local y en la nube. AAD Connect puede hacer dos cosas: replica las cuentas de usuario en Microsoft 365 (replicación) y puede sincronizar la información de contraseña en Microsoft 365 (realmente no se sincroniza la contraseña, pero un hash no reversible que represente la contraseña; sincronización). No es necesario que ' sincronice la contraseña ', pero siempre sincroniza (replica) sus cuentas de usuario desde Active Directory (o alguna versión filtrada del directorio de usuarios locales).

AAD Connect funciona con controladores de dominio correctos en el dominio de Active Directory para permitir el "mismo inicio de sesión" en lugar del inicio de sesión único de ADFS. El mismo inicio de sesión significa que, en lugar de iniciar sesión una sola vez y hacer que ADFS intervenga en todas las preguntas de la sesión, inicie sesión con la misma contraseña que local (y, presumiblemente, seleccione la opción de mantener la sesión iniciada para reducir el número de avisos que resultado de navegar por varias cargas de trabajo). AAD Connect for Sync no es opcional.

Internet y las partes híbridas disponibles en común

En contraposición a los servidores locales de su Microsoft 365 híbrido y a través de Internet se encuentra la nube de Microsoft, donde, sin importar la Microsoft 365 carga de trabajo, usará algunas tecnologías conocidas. Estas son las siguientes:

• Registros DNS públicos

• Entidades emisoras de certificados públicas

• Azure Active Directory (AAD)

• Microsoft 365 (licencias/Subs) y Microsoft 365 asistentes de implementación híbrida

• Una confianza de servidor a servidor (S2S)

• Expressroute y/o tráfico de Internet

• Módulos de PowerShell

Los registradores de DNS públicos, como GoDaddy, administran y permiten el registro de nombres de dominio. Si desea usar una implementación híbrida, tendrá que registrar un nombre de dominio con DNS público (esto ya puede hacerse para usted en grandes empresas). Este nombre de dominio se agregará a Microsoft 365, lo que verificará también que es el propietario del nombre de dominio público que agregue.

Tradicionalmente, este nombre de dominio público es el mismo que el UPN de Active Directory adjunto a los usuarios híbridos locales, pero no se pone al día con este detalle. Con la llegada del atributo ' onpremisessecurityidentifier ' en PowerShell, que asigna la identidad al SID local, la coincidencia del dominio registrado en Microsoft 365 con el UPN de los usuarios locales ya no es tan importante como lo era. Es más importante saber que necesitará un nombre de dominio público que usted pueda probar, este nombre de dominio público se registrará en Microsoft 365 y representará su presencia de Microsoft 365 en cualquiera de los lados de la conexión híbrida.

Las entidades emisoras de certificados públicas le proporcionan certificados SSL/TLS de confianza para cifrar el tráfico de red. En todas las cargas de trabajo, la comunicación híbrida se realiza a través de una conexión cifrada. Necesitará un certificado de una entidad emisora de certificados pública en Internet. Los certificados de obtención y SSL/TLS son una práctica estándar y generalmente existen procesos de certificados públicos en las grandes empresas para que esto sea más fácil. En empresas más pequeñas, es posible que necesite consultar a su persona de ti, Microsoft 365 documentación y a su proveedor de servicios de Internet.

Azure Active Directory, o Azure AD, está en segundo plano al sincronizar/replicar usuarios de su local a su suscripción de Microsoft 365 (sus instalaciones en la nube). Es exactamente el mismo Active Directory que se usa en Azure más amplio. Potente y perfectamente fusionada en Microsoft 365. Administrará los usuarios y las licencias de usuario en este directorio. La administración de licencias en Microsoft 365 no se realiza de forma automática con ningún asistente híbrido. Las licencias cuestan a los clientes dinero, por lo que la decisión de quién y la cantidad de licencias Get no se realizan automáticamente.

Microsoft 365 es completamente la mitad de su híbrido. Tiene asistentes híbridos en línea por carga de trabajo. Esto no es muy eficaz, pero este es el funcionamiento de híbrido a partir de 2016 (o, en otras palabras, a partir de la versión de SharePoint Server 2016, Exchange Server 2016 y Skype empresarial Server 2015, local). Sin embargo, esta no es la manera más sencilla de configurar todos los elementos en un entorno híbrido. Un único asistente híbrido que permite a los clientes elegir las cargas de trabajo híbridas y pasar por todo el proceso por carga de trabajo, así como un centro de comandos híbrido (un Microsoft 365 panel administrativo) que podría informar de si las tecnologías que se usan en cada híbrido están en buen estado o si ya están en vigor.

¿Qué significa esto? Significa que todos los asistentes hacen los mismos pasos y, a menudo, más de una vez. Cada asistente activa OAuth (confianza S2S) por ejemplo (hablaremos de OAuth más adelante). Algunos asistentes, como el selector híbrido de la carga de trabajo de SharePoint Online, instale OAuth, independientemente del botón en el que haga clic (para cada selección que realice), si se necesita OAuth en su escenario híbrido. Otros asistentes, como el Asistente de implementación híbrida de Exchange, configuran OAuth en segundo plano y solo una vez.

Una confianza de S2S no tiene que cruzar Internet, pero en el caso de una implementación híbrida, esta confianza debe. Un sitio S2S no es como una confianza de bosque o de dominio. No hay un gran número de puertos para abrir ni una integración más profunda para crear entre Active Directory. S2S crea una conexión de confianza entre su granja de SharePoint local y una parte de la nube de Microsoft 365 denominada servicio de control de acceso o ACS (un servidor de autorización). La confianza se basa en un certificado SSL/TLS que firma tokens emitidos en nombre de los usuarios, que su entorno local y el Microsoft 365 ACS acuerdan ser fidedignos, como por ejemplo, un nivel cinco entre SharePoint local (y su servicio proxy de ACS) y el ACS de Azure para cada usuario válido que tenga acceso al servicio. La comunicación acerca de las identidades de usuario (el motivo de esta confianza) se realiza a través de HTTP/443.

Los híbridos pueden usar certificados autofirmados o públicos aquí. Muchas empresas grandes elegirán certificados públicos a causa de sus normas de InfoSec, en gran medida porque el tráfico cruza o puede atravesar Internet, un segmento que no es de confianza. En el caso de los entornos híbridos de SharePoint, este certificado puede ser un nuevo certificado autofirmado o uno extraído del certificado de firma token SP STS en local. (Si ha usado un certificado nuevo (público o autofirmado) en un entorno híbrido de SharePoint, necesita reemplazar el certificado de firma del token del SP STS en todos los nodos de la granja de servidores de SharePoint.)

El tráfico en un entorno híbrido sale de una compañía de cliente/organización, cruza Internet y entra en la nube de Microsoft/Microsoft Microsoft 365. Hay una forma de eludir este segmento no confiable y no supercontrolado, y eso es usar una ruta Express basada en un proveedor de terceros de su empresa u organización en la nube de Microsoft 365. Express Route omite Internet al ofrecer una conexión WAN privada a la nube de Microsoft. Sin embargo, es importante tener en cuenta que en los casos en los que la WAN sufre un error, la reserva sigue siendo Internet.

Todos los híbridos usan los módulos de PowerShell para partes de la administración o de la configuración. Es probable que la mayoría de los módulos que necesita incluya el ayudante para el Inicio de sesión de Microsoft Online Servicesy el módulo Azure Active Directory para Windows PowerShell. Puede preparar los servidores para la configuración y la administración de los híbridos con antelación instalando estos módulos de PowerShell de uso frecuente.

Puertos y protocolos en común

Los híbridos son 1/2 sus locales y 1/2 Microsoft 365 (los híbridos de Azure o PaaS no se cubren en este documento). Es muy probable que ambos se ejecuten en HTTPs, pero, al menos, la mitad Microsoft 365 es 100% https/cifrado por certificados TLS y eso significa que se ejecuta sobre el puerto estándar 443. Tendrá que asegurarse de que un certificado público está asociado con el tráfico que sale de su punto de salida. Es decir, tendrá que instalar un certificado en el equipo que habla en el extremo de su red: este tráfico se ejecutará más de 443 y se cifrará.

Todos los híbridos usarán 443 (HTTPS) y 53 (DNS), de forma predeterminada, para el tráfico híbrido. Algunos usarán puertos adicionales como el puerto 25 (SMTP). Pero el caso más complejo en cargas de trabajo híbridas para puertos es Skype empresarial. Afortunadamente, los puertos están documentados.

El protocolo standout usado por todos los híbridos (aparte de las pruebas comparativas que se usan para la búsqueda de DNS, el tráfico HTTPS, SMTP y otros estándares), es OAuth (autorización abierta), que también se usa en la biblioteca de autenticación de Active Directory. Se usa cuando un recurso de servidor de un lado de la conexión tiene que actuar en nombre de un usuario para acceder a los recursos de otro servidor, a menudo, en la nube. Es un medio por el cual el nivel de acceso de los usuarios a un archivo o recurso puede ser medidor para un usuario autenticado. También se denomina "autenticación moderna" (aunque OAuth hace referencia a la autorización).

Todas las cargas de trabajo usan OAuth/S2S cuando se encuentra en un entorno híbrido (aunque no para todas las características híbridas). Por lo general, los asistentes híbridos configuran este protocolo útil de forma automática. Sin embargo, no hay ninguna desunificación de este esfuerzo en todas las cargas de trabajo, sin informes de estado de OAuth para el cliente y ninguna manera centralizada de administrar este recurso universal a partir de 2016.

En algunos casos, los asistentes híbridos activan OAuth cuando no es necesario (como cuando el selector híbrido de SharePoint lo activa para el redireccionamiento de OneDrive para la empresa a la nube), o bien, en cada selección de una opción híbrida del asistente (de nuevo, consulte el selector híbrido de SharePoint) , o incluso fuera del selector híbrido de scripts de configuración personalizada, como la búsqueda híbrida en la nube.

Tabla de elementos comunes en Microsoft 365 híbridos

Ahora tenemos una lista de elementos comunes con el aspecto siguiente:

En última instancia, en todas las cargas de trabajo, el objetivo es conseguir que los usuarios sean los mismos en todos los límites, de modo que podamos simplificar dos de las funciones más importantes que realiza un híbrido, es decir, la identidad del usuario y lo que se permite hacer con la información que se permite ver.

Una nota sobre "opcional"

Algunos de estos elementos se establecen en "opcional", pero ¿cómo sabrá si son necesarios? Algunos elementos de Microsoft 365 híbridos son realmente opcionales o no opcionales en todos los paneles:

Dentro de un entorno híbrido de trabajo hay otras características que se dividen en un área gris. Probablemente, la más importante de estas es la confianza de S2S/OAuth. Esta confianza es creada por todos los asistentes híbridos creados en Microsoft y la confianza se genera de forma predeterminada, incluso cuando no es necesaria, a fin de que los híbridos ' sean comparables en el futuro. Una vez que se haya desplazado híbrido a través de un asistente, esta característica estará activada. Pero (como vimos antes) no se usa actualmente en todos los casos.

Es necesario un proxy inverso (WA-P en nuestro ejemplo) siempre que haya una solicitud no solicitada entrante a la organización del cliente para obtener información o información (como, por ejemplo, al usar BCS híbridas, al publicar Office Web Apps u Office Online Server for document Preview en Search resultados). También es necesario al publicar un extremo en una DMZ de su empresa, como cuando Exchange usa WA-P como proxy de ADFS (por lo tanto, si usa ADFS en un entorno híbrido de Exchange, necesitará WA-P).

Los bordes son necesarios para mantener canales de comunicación coherentes para las conversaciones en curso en una implementación híbrida de Skype empresarial y se pueden usar para enrutar tráfico SMTP a la red desde un perímetro en un entorno híbrido de Exchange. Como se ha explicado, ADFS se usa para el inicio de sesión único.

Hay tablas similares para S2S, como esta tabla para servidores de SharePoint en configuraciones híbridas. Las tablas de este tipo se pueden crear con la lógica del protocolo S2S, que se usa cuando un recurso de servidor de un lado de la conexión híbrida tiene que actuar en nombre de un usuario para obtener acceso a los recursos de otro servidor en la nube.

* El selector híbrido de SharePoint seguirá activando OAuth, pero esto es para cualquier configuración híbrida futura.