Extensión de AD FS local a Azure

Esta arquitectura de referencia implementa una red híbrida segura que extiende la red local a Azure y usa los Servicios de federación de Active Directory (AD FS) para realizar la autenticación y la autorización federada para los componentes que se ejecutan en Azure.

Architecture

Descargue un archivo Visio de esta arquitectura.

Flujo de trabajo

• Subred de AD DS. Los servidores de AD DS se encuentran en su propia subred con reglas de grupo de seguridad de red (NSG) que actúan como un firewall.

• Servidores de AD FS. Controladores de dominio que se ejecutan como máquinas virtuales en Azure. Estos servidores proporcionan autenticación de las identidades locales dentro del dominio.

• Subred de AD FS. Los servidores de AD FS se encuentran dentro de su propia subred con reglas NSG que actúan como un firewall.

• Servidores de AD FS. Los servidores de AD FS proporcionan autenticación y autorización federadas. En esta arquitectura, se realizan las siguientes tareas:

  • Recibir tokens de seguridad que contienen notificaciones realizadas por un servidor de federación asociado en nombre del usuario asociado. AD FS comprueba que los tokens son válidos antes de pasar las notificaciones a la aplicación web que se ejecuta en Azure para autorizar las solicitudes.

    La aplicación que se ejecuta en Azure es el usuario de confianza. El servidor de federación asociado debe emitir notificaciones que la aplicación web entienda. Los servidores de federación asociados se conocen como asociados de cuenta, ya que envían las solicitudes de acceso en nombre de las cuentas autenticadas en la organización del asociado. Los servidores de AD FS se denominan asociados de recursos ya que proporcionan acceso a los recursos (la aplicación web).

  • Autenticar y autorizar las solicitudes entrantes de los usuarios externos que ejecutan un explorador web o un dispositivo que necesita tener acceso a las aplicaciones web, mediante AD DS y el Servicio de registro de dispositivos de Active Directory.

  Los servidores de AD FS se configuran como una granja de servidores a los que se accede a través de un equilibrador de carga de Azure. Esta implementación mejora la disponibilidad y la escalabilidad. Los servidores de AD FS no se exponen directamente a Internet. Todo el tráfico de Internet se filtra a través de servidores proxy de aplicación web de AD FS y una red perimetral (también conocida como DMZ).

  Para más información acerca del funcionamiento de AD FS, consulte Introducción a los Servicios de federación de Active Directory. Además, el artículo Implementación de AD FS en Azure contiene una introducción detallada paso a paso para la implementación.

• Subred de proxy de AD FS. Los servidores proxy de AD FS pueden estar dentro de su propia subred, con reglas NSG que proporcionan la protección. Los servidores de esta subred se exponen a Internet a través de un conjunto de aplicaciones virtuales de red que proporcionan un firewall entre la red virtual de Azure e Internet.

• Servidores proxy de aplicación web (WAP) de AD FS. Estas máquinas virtuales actúan como servidores de AD FS para las solicitudes entrantes de las organizaciones asociadas y los dispositivos externos. Los servidores WAP actúan como un filtro, blindando a los servidores de AD FS frente al acceso directo desde Internet. Al igual que con los servidores de AD FS, implementar los servidores WAP en una granja de servidores con equilibrio de carga ofrece mayor disponibilidad y escalabilidad que la implementación de una colección de servidores independientes.

  Nota

  Para información detallada acerca de cómo instalar los servidores WAP, consulte Instalación y configuración del servidor proxy de aplicación web.

• Organización del asociado. La organización de un asociado ejecuta una aplicación web que solicita acceso a una aplicación web que se ejecuta en Azure. El servidor de federación de la organización del asociado autentica localmente las solicitudes y envía tokens de seguridad que contienen notificaciones a AD FS que se ejecuta en Azure. AD FS en Azure valida los tokens de seguridad y, si son válidos, puede pasar las notificaciones a la aplicación web que se ejecuta en Azure para que las autorice.

  Nota

  También puede configurar un túnel VPN con la puerta de enlace de Azure para proporcionar acceso directo a AD FS para los asociados de confianza. Las solicitudes recibidas desde estos asociados no pasan a través de los servidores WAP.

Componentes

Esta arquitectura amplía la implementación que se describe en Extensión de AD DS a Azure. Contiene los componentes siguientes.

• Subred de AD DS
• Servidores de AD DS
• Subred de AD FS
• Servidores de AD FS
• Subred proxy de AD FS
• Servidores proxy de aplicación web (WAP) de AD FS

Detalles del escenario

AD FS puede hospedarse de forma local, pero, si la aplicación es un híbrido en el que algunas partes se implementan en Azure, podría ser más eficaz replicar AD FS en la nube.

El diagrama anterior muestra los siguientes escenarios:

• El código de la aplicación de una organización asociada tiene acceso a una aplicación web que se hospeda dentro de la red virtual de Azure.
• Un usuario externo y registrado con las credenciales almacenadas en Active Directory Domain Services (DS) tiene acceso a una aplicación web que se hospeda dentro de la red virtual de Azure.
• Un usuario conectado a la red virtual con un dispositivo autorizado ejecuta una aplicación web que se hospeda dentro de la red virtual de Azure.

Esta arquitectura de referencia se centra en la federación pasiva, en la que los servidores de federación deciden cómo y cuándo autenticar a un usuario. El usuario proporciona información de inicio de sesión cuando se inicia la aplicación. Este mecanismo se usa normalmente en los exploradores web e implica un protocolo que redirige el explorador a un sitio donde el usuario se autentica. AD FS también admite la federación activa, en la que una aplicación asume la responsabilidad de proporcionar las credenciales sin la intervención del usuario, pero ese escenario está fuera del ámbito de esta arquitectura.

Para consideraciones adicionales, consulte Selección de una solución para la integración de Active Directory local con Azure.

Posibles casos de uso

Los usos habituales de esta arquitectura incluyen:

• Aplicaciones híbridas donde una parte de las cargas de trabajo se ejecutan de forma local y otra parte en Azure.
• Soluciones que usan autorización federada para exponer las aplicaciones web a las organizaciones asociadas.
• Sistemas que permiten el acceso desde exploradores web que se ejecutan fuera del firewall de la organización.
• Sistemas que permiten a los usuarios el acceso a las aplicaciones web mediante la conexión de dispositivos externos autorizados como equipos remotos, portátiles y otros dispositivos móviles.

Recomendaciones

Las siguientes recomendaciones sirven para la mayoría de los escenarios. Sígalas a menos que tenga un requisito concreto que las invalide.

Recomendaciones de redes

Configure la interfaz de red para cada una de las máquinas virtuales que hospedan servidores de AD FS y WAP con direcciones IP privadas estáticas.

No asigne direcciones IP públicas a las máquinas virtuales de AD FS. Para más información, consulte la sección Consideraciones de seguridad.

Establezca la dirección IP de los servidores del servicio de nombres de dominio preferido y secundario (DNS) para las interfaces de red de cada máquina virtual AD FS y WAP para hacer referencia a las máquinas virtuales de Active Directory DS. Las máquinas virtuales de Active Directory DS deben ejecutar DNS. Este paso es necesario para permitir que cada máquina virtual se una al dominio.

Instalación de AD FS

El artículo Implementación de una granja de servidores de federación proporciona instrucciones detalladas para instalar y configurar AD FS. Antes de configurar el primer servidor de AD FS en la granja de servidores, haga lo siguiente:

1. Obtenga un certificado público de confianza para realizar la autenticación de los servidores. El nombre de sujeto debe contener el nombre que los clientes usan para tener acceso al servicio de federación. Puede tratarse del nombre DNS registrado para el equilibrador de carga, por ejemplo adfs.contoso.com (por motivos de seguridad, evite utilizar nombres con caracteres comodín como *.contoso.com). Use el mismo certificado en todas las máquinas virtuales de servidores de AD FS. Puede adquirir un certificado de una entidad de certificación de confianza, pero, si su organización usa Servicios de certificados de Active Directory, puede crear los suyos propios.

   El nombre alternativo del firmante se utiliza en el servicio de registro de dispositivos (DRS) para habilitar el acceso desde dispositivos externos. Debe tener el formato enterpriseregistration.contoso.com.

   Para más información, consulte Obtención y configuración de un certificado de Capa de sockets seguros (SSL) para AD FS.

2. En el controlador de dominio, genere una nueva clave raíz para el Servicio de distribución de claves. Establezca el tiempo efectivo en la hora actual menos 10 horas (esta configuración reduce el retardo que se puede producir en la distribución y la sincronización de las claves a través del dominio). Este paso es necesario para permitir la creación de la cuenta del servicio de grupo que se usa para ejecutar el servicio AD FS. El siguiente comando de PowerShell muestra un ejemplo de cómo hacerlo:

   Add-KdsRootKey -EffectiveTime (Get-Date).AddHours(-10)
   

3. Agregue cada máquina virtual del servidor de AD FS al dominio.

Confianza de AD FS

Establezca la confianza de federación entre la instalación de AD FS y los servidores de federación de las organizaciones asociadas. Configure las notificaciones de filtrado y asignación necesarias.

• El personal de DevOps de cada organización asociada debe agregar una relación de confianza para las aplicaciones web accesibles a través de los servidores de AD FS.
• El personal de DevOps de la organización debe configurar la confianza del proveedor de notificaciones a fin de habilitar los servidores de AD FS para confiar en las notificaciones que las organizaciones asociadas proporcionan.
• También debe configurar AD FS para pasar las notificaciones a las aplicaciones web de la organización.

Para más información, consulte Establecimiento de la confianza de la federación.

Publique las aplicaciones web de su organización y haga que estén disponibles para los asociados externos con la autenticación previa a través de servidores WAP. Para más información, consulte Publicación de aplicaciones mediante la autenticación previa de AD FS.

AD FS admite el aumento y la transformación de tokens. Microsoft Entra ID no proporciona esta característica. Con AD FS, al configurar las relaciones de confianza, puede:

• Configurar transformaciones de notificación para las reglas de autorización. Por ejemplo, puede asignar la seguridad de grupo desde una representación utilizada por una organización asociada diferente de Microsoft a algo que Active Directory DS pueda autorizar en la organización.
• Transformar las notificaciones de un formato a otro. Por ejemplo, puede pasar de SAML 2.0 a SAML 1.1, si la aplicación solo admite las notificaciones de SAML 1.1.

Supervisión de AD FS

El paquete de administración de Microsoft System Center para Servicios de federación de Active Directory 2012 R2 proporciona la supervisión tanto reactiva como proactiva de la implementación de ADFS para el servidor de federación. Este módulo de administración supervisa:

• Los eventos que el servicio AD FS incluye en sus registros de eventos.
• Los datos de rendimiento que los contadores de rendimiento de AD FS recopilan.
• El estado general del sistema AD FS y las aplicaciones web (usuarios de confianza), además de proporcionar alertas para los problemas críticos y las advertencias.

Otra opción es Supervisar AD FS mediante Microsoft Entra Connect Health. Microsoft Entra Connect Health proporciona una sólida supervisión de la infraestructura de identidad local. Permite mantener una conexión confiable con Microsoft 365 y Microsoft Online Services. Esta confiabilidad se consigue al proporcionar funcionalidades de supervisión para los componentes de identidad clave. Además, hace que los puntos de datos clave sobre estos componentes sean fácilmente accesibles.

Consideraciones

Estas consideraciones implementan los pilares del marco de buena arquitectura de Azure, que es un conjunto de principios guía que se pueden usar para mejorar la calidad de una carga de trabajo. Para más información, consulte Marco de buena arquitectura de Microsoft Azure.

Eficiencia del rendimiento

La eficiencia del rendimiento es la capacidad de la carga de trabajo para escalar con el fin de satisfacer de manera eficiente las demandas que los usuarios hayan ejercido sobre ella. Para obtener más información, vea Resumen del pilar de eficiencia del rendimiento.

Las consideraciones siguientes, que se resumen a partir del artículo Planeamiento de la implementación de AD FS, proporcionan un punto de partida para ajustar el tamaño de las granjas de servidores de AD FS:

• Si tiene menos de 1000 usuarios, no cree servidores dedicados, sino que, en su lugar, instale AD FS en cada uno de los servidores de Active Directory DS de la nube. Asegúrese de que tiene al menos dos servidores de Active Directory DS para mantener la disponibilidad. Cree un único servidor WAP.
• Si tiene entre 1000 y 15 000 usuarios, cree dos servidores de AD FS dedicados y dos servidores WAP dedicados.
• Si tiene entre 15 000 y 60 000 usuarios, cree entre tres y cinco servidores AD FS dedicados y al menos dos servidores WAP dedicados.

Para estas consideraciones, se supone que se utilizan los tamaños de máquinas virtuales duales de cuatro núcleos (D4_v2 Estándar o superiores) en Azure.

Si usa Windows Internal Database para almacenar los datos de configuración de AD FS, estará limitado a ocho servidores de AD FS en la granja. Si prevé que necesitará más en el futuro, utilice SQL Server. Para más información, consulte Rol de base de datos de configuración de AD FS.

Confiabilidad

La confiabilidad garantiza que la aplicación pueda cumplir los compromisos contraídos con los clientes. Para más información, consulte Resumen del pilar de fiabilidad.

Cree una granja de servidores de AD FS con al menos dos servidores para aumentar la disponibilidad del servicio. Use cuentas de almacenamiento diferentes para cada máquina virtual de AD FS en la granja de servidores. Este enfoque ayuda a garantizar que un error en una única cuenta de almacenamiento no provoque que toda la granja quede inaccesible.

Cree conjuntos de disponibilidad de Azure diferentes para las máquinas virtuales de AD FS y WAP. Asegúrese de que hay al menos dos máquinas virtuales en cada conjunto. Cada conjunto de disponibilidad debe tener dos dominios de actualización y dos dominios de error, como mínimo.

Configure los equilibradores de carga para las máquinas virtuales de AD FS y WAP de la manera siguiente:

• Use un equilibrador de carga de Azure para proporcionar acceso externo a las máquinas virtuales de WAP y uno interno para distribuir la carga entre los servidores de AD FS en la granja de servidores.

• Pase únicamente el tráfico que aparezca en el puerto 443 (HTTPS) a los servidores de AD FS y WAP.

• Asigne al equilibrador de carga una dirección IP estática.

• Crear un sondeo de mantenimiento mediante HTTP en /adfs/probe. Para más información, consulte Hardware Load Balancer Health Checks and Web Application Proxy / AD FS 2012 R2 (Comprobaciones de mantenimiento de equilibrador de carga de hardware y proxy de aplicación web / AD FS 2012 R2).

  Nota

  Los servidores de AD FS usan el protocolo Indicación de nombre de servidor (SNI), por lo que el intento de sondear con un punto de conexión HTTPS desde el equilibrador de carga fracasa.

• Agregue un registro A DNS al dominio para el equilibrador de carga de AD FS. Especifique la dirección IP del equilibrador de carga y asígnele un nombre en el dominio (por ejemplo, adfs.contoso.com). Se trata del nombre que los clientes y los servidores WAP usan para tener acceso a la granja de servidores de AD FS.

Puede usar SQL Server o Windows Internal Database para contener la información de configuración de AD FS. Windows Internal Database proporciona redundancia básica. Los cambios se escriben directamente en una de las bases de datos de AD FS en el clúster de AD FS, mientras que los demás servidores usan replicación de extracción para mantener sus bases de datos actualizadas. Con SQL Server, puede proporcionar una redundancia completa de las bases de datos y una elevada disponibilidad mediante clústeres de conmutación por error o la creación de reflejo.

Seguridad

La seguridad proporciona garantías contra ataques deliberados y el abuso de datos y sistemas valiosos. Para más información, consulte Introducción al pilar de seguridad.

AD FS usa HTTPS, así que asegúrese de que las reglas de NSG para la subred que contiene las máquinas virtuales del nivel web permiten solicitudes de HTTPS. Estas solicitudes pueden originarse en la red local, las subredes que contienen el nivel web, el nivel empresarial, el nivel de datos, la red perimetral privada, la red perimetral pública y la subred que contiene los servidores de AD FS.

Evite la exposición directa de los servidores de AD FS a Internet. Los servidores de AD FS son equipos unidos a un dominio que tienen autorización completa para conceder tokens de seguridad. Si un servidor se ve comprometido, un usuario malintencionado puede emitir tokens de acceso completo a todas las aplicaciones web y a todos los servidores de federación que estén protegidos por AD FS. Si el sistema debe controlar las solicitudes de los usuarios externos que no se conectan desde sitios de confianza asociados, use los servidores WAP para controlar estas solicitudes. Para más información, consulte Ubicación de un servidor proxy de federación.

Coloque los servidores de AD FS y los servidores WAP en subredes independientes con sus propios firewalls. Puede usar las reglas NSG para definir las reglas de firewall. Todos los firewalls deben permitir el tráfico en el puerto 443 (HTTPS).

Restrinja el acceso de inicio de sesión directo a los servidores de AD FS y WAP. Solo el personal de DevOps debe ser capaz de conectarse. No una los servidores WAP al dominio.

Considere usar un conjunto de aplicaciones de red virtual que registre información detallada sobre el tráfico que atraviesa la frontera de la red virtual con fines de auditoría.

Optimización de costos

La optimización de costos trata de buscar formas de reducir los gastos innecesarios y mejorar las eficiencias operativas. Para más información, vea Información general del pilar de optimización de costos.

Estas son las consideraciones de costo de los servicios que se usan en esta arquitectura.

Servicios de dominio de AD

Considere la posibilidad de que Active Directory Domain Services sea un servicio compartido que lo consuman varias cargas de trabajo para reducir costos. Para más información, consulte Precios de Active Directory Domain Services.

Servicios de federación de Active Directory

Para obtener información sobre las ediciones que ofrece Microsoft Entra ID, consulte Precios de Microsoft Entra. La característica Servicios de federación de AD está disponible en todas las ediciones.

Excelencia operativa

El personal de DevOps debe estar preparado para realizar las siguientes tareas:

• Administrar los servidores de federación, incluida la administración de la granja de servidores de AD FS, de la directiva de confianza en los servidores de federación y de los certificados usados por los servicios de federación.
• Administrar los servidores WAP, incluida la administración de la granja de servidores WAP y los certificados.
• Administrar las aplicaciones web, incluida la configuración de los usuarios de confianza, los métodos de autenticación y las asignaciones de notificaciones.
• Realizar copias de seguridad de los componentes de AD FS.

Para consideraciones adicionales sobre DevOps, consulte DevOps: extensión de Active Directory Domain Services (AD DS) a Azure.

Colaboradores

Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.

Autor principal:

• Sarah Parkes | Arquitecta sénior de soluciones en la nube

Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.

Pasos siguientes

• Documentación de Azure Active Directory
• Administración de identidades en aplicaciones multiinquilino
• Seguridad de la administración de identidades
• Azure Firewall

Recursos relacionados

• Implementación de AD DS en una red virtual de Azure
• Administración de identidades y acceso de Microsoft Entra para AWS