Granja de servidores de federación de AD FS heredada mediante SQL Server
Esta topología para Servicios de federación de Active Directory (AD FS) difiere de la granja de servidores de federación mediante la topología de implementación de Windows Internal Database (WID) en que no replica los datos en cada servidor de federación de la granja de servidores. En su lugar, todos los servidores de federación de la granja de servidores pueden leer y escribir datos en una base de datos común que se almacena en un servidor que ejecuta Microsoft SQL Server que se encuentra en la red corporativa.
Importante
Si desea crear una granja de AD FS y usar SQL Server para almacenar los datos de configuración, puede usar SQL Server 2008 y versiones posteriores, incluido SQL Server 2012, y SQL 2014.
Consideraciones de la implementación
En esta sección se describen varias consideraciones sobre el público a la que está dirigida, así como las ventajas y las limitaciones asociadas a esta topología de implementación.
¿Quién debe usar esta topología?
Organizaciones grandes con más de 100 relaciones de confianza que necesitan proporcionar a sus usuarios internos y externos acceso de inicio de sesión único (SSO) a servicios o aplicaciones federadas.
Organizaciones que ya usan SQL Server y quieren aprovechar sus herramientas y conocimientos existentes.
¿Cuáles son las ventajas de usar esta topología?
Compatibilidad con un mayor número de relaciones de confianza (más de 100)
Compatibilidad con la detección de reproducción de tokens (una característica de seguridad) y la resolución de artefactos (parte del protocolo Lenguaje de marcado de aserción de seguridad (SAML) 2.0)
Compatibilidad con las ventajas completas de SQL Server, como la creación de reflejo de la base de datos, los clústeres de conmutación por error, los informes y las herramientas de administración
¿Cuáles son las limitaciones de usar esta topología?
Esta topología no proporciona redundancia de base de datos de forma predeterminada. Aunque una granja de servidores de federación con topología WID replica automáticamente la base de datos WID en cada servidor de federación de la granja de servidores, la granja de servidores de federación con topología de SQL Server contiene solo una copia de la base de datos.
Nota
SQL Server admite muchas opciones de redundancia de aplicaciones y datos diferentes, como clústeres de conmutación por error, creación de reflejo de la base de datos y varios tipos diferentes de replicación de SQL Server.
El departamento de Tecnología de la información de Microsoft (TI) usa la creación de reflejo de la base de datos de SQL Server en modo de alta seguridad (sincrónica) y clústeres de conmutación por error para proporcionar compatibilidad de alta disponibilidad para la instancia de SQL Server. La replicación transaccional (punto a punto) y la replicación de mezcla de SQL Server no se han probado por el equipo de productos de AD FS en Microsoft. Para obtener más información sobre SQL Server, consulte Información general sobre soluciones de alta disponibilidad o Selección del tipo de replicación adecuado.
Versiones de SQL Server admitidas
Las siguientes versiones de SQL Server se admiten con AD FS en Windows Server 2012 R2:
SQL Server 2008 / R2
SQL Server 2012
SQL Server 2014
Recomendaciones de ubicación del servidor y distribución de red
De forma similar a la granja de servidores de federación con topología WID, todos los servidores de federación de la granja de servidores están configurados para usar un nombre de sistema de nombres de dominio (DNS) de clúster (que representa el nombre del servicio de federación) y una dirección IP del clúster como parte de la configuración del clúster de equilibrio de carga de red (NLB). Esto ayuda al host NLB a asignar solicitudes de cliente a los servidores de federación individuales. Los servidores proxy de federación se pueden usar para representar las solicitudes de cliente ante la granja de servidores de federación.
En la ilustración siguiente se muestra cómo la empresa ficticia Contoso Pharmaceuticals implementó su granja de servidores de federación con SQL Server topología en la red corporativa. También muestra cómo esa empresa configuró la red perimetral con acceso a un servidor DNS, un host NLB adicional que usa el mismo nombre DNS de clúster (fs.contoso.com) que se usa en el clúster NLB de red corporativa y con dos servidores proxy de aplicación web (wap1 y wap2).
Para obtener más información sobre cómo configurar el entorno de red para su uso con servidores de federación o servidores proxy de aplicación web, consulte la sección "Requisitos de resolución de nombres" de Requisitos de AD FS y Planear la infraestructura del Proxy de aplicación web (WAP).
Opciones de alta disponibilidad para granjas de SQL Server
En Windows Server 2012 R2, AD FS hay dos nuevas opciones para admitir la alta disponibilidad en granjas de servidores de AD FS mediante SQL Server.
Compatibilidad para Grupos de disponibilidad AlwaysOn de SQL Server
Compatibilidad con alta disponibilidad distribuida geográficamente mediante la replicación de mezcla de SQL Server
En esta sección se describe cada una de estas opciones, qué problemas resuelven respectivamente y algunas consideraciones clave para decidir qué opciones implementar.
Nota
Las granjas de servidores de AD FS que usan Windows Internal Database (WID) proporcionan redundancia de datos básica con acceso de lectura y escritura en el nodo del servidor de federación principal y acceso de solo lectura en nodos secundarios. Esto se puede usar en una topología geográficamente local o distribuida geográficamente.
Al usar WID, debe tener en cuenta que existen las siguientes limitaciones:
- Una granja de servidores WID tiene un límite de 30 servidores de federación si tiene 100 o menos confianzas para usuario autenticado.
- Una granja de servidores WID no admite la detección de reproducción de tokens ni la resolución de artefactos (parte del protocolo Lenguaje de marcado de aserción de seguridad (SAML)).
En la tabla siguiente se proporciona un resumen del uso de una granja de WID:
| 1-100 relaciones de confianza para usuario autenticado | Más de 100 relaciones de confianza para usuario autenticado |
|---|---|
| 1-30 nodos de AD FS: Compatible con WID | 1-30 nodos de AD FS: No compatible con WID, se requiere SQL |
| Más de 30 nodos de AD FS: No compatible con WID, se requiere SQL | Más de 30 nodos de AD FS: No compatible con WID, se requiere SQL |
Grupos de disponibilidad AlwaysOn
Información general
Los grupos de disponibilidad AlwaysOn se introdujeron en SQL Server 2012 y proporcionan una nueva manera de crear una instancia de SQL Server de alta disponibilidad. Los grupos de disponibilidad AlwaysOn combinan elementos de agrupación en clústeres y creación de reflejo de la base de datos para la redundancia y la conmutación por error tanto en la capa de instancia de SQL como en la capa de base de datos. A diferencia de las opciones de alta disponibilidad anteriores, los grupos de disponibilidad AlwaysOn no requieren un almacenamiento común (o una red de área de almacenamiento) en el nivel de base de datos.
Un grupo de disponibilidad se compone de una réplica principal (un conjunto de bases de datos principales de lectura y escritura) y una a cuatro réplicas de disponibilidad (conjuntos de bases de datos secundarias correspondientes). El grupo de disponibilidad admite una sola copia de lectura y escritura (la réplica principal) y una a cuatro réplicas de disponibilidad de solo lectura. Cada réplica de disponibilidad debe residir en otro nodo de un único clúster de clústeres de conmutación por error de Windows Server (WSFC). Para obtener más información sobre los grupos de disponibilidad AlwaysOn, consulte Grupos de disponibilidad AlwaysOn (SQL Server).
Desde la perspectiva de los nodos de una granja de SQL Server de AD FS, el grupo de disponibilidad AlwaysOn reemplaza a la instancia de SQL Server única como la base de datos de artefactos o directivas. El agente de escucha del grupo de disponibilidad es lo que usa el cliente (el servicio de token de seguridad de AD FS) para conectarse a SQL.
En el siguiente diagrama se muestra una granja de servidores de SQL Server de AD FS con un grupo de disponibilidad AlwaysOn.
Nota:
Los grupos de disponibilidad AlwaysOn requieren que las instancias de SQL Server residan en nodos de clústeres de conmutación por error de Windows Server (WSFC).
Nota
Solo una réplica de disponibilidad puede actuar como destino de conmutación automática por error; las otras tres se basarán en las conmutaciones por error manuales.
Consideraciones acerca de la implementación
Si tiene previsto usar grupos de disponibilidad AlwaysOn en combinación con SQL Server replicación de mezcla, tome nota de los problemas descritos en "Consideraciones de implementación clave para usar AD FS con SQL Server replicación de mezcla" a continuación. En particular, cuando el grupo de disponibilidad AlwaysOn que contiene la base de datos que es un suscriptor de replicación realiza una conmutación por error, se produce un error en la suscripción de replicación. Para reanudar la replicación, un administrador de replicación debe configurar manualmente el suscriptor. Consulte la descripción SQL Server de un problema específico en Suscriptores de replicación y grupos de disponibilidad AlwaysOn (SQL Server) y instrucciones de compatibilidad general para grupos de disponibilidad AlwaysOn con opciones de replicación en Replicación, Change Tracking, Captura de datos modificados y Grupos de disponibilidad AlwaysOn (SQL Server).
Configurar AD FS para usar grupos de disponibilidad AlwaysOn
La configuración de una granja de servidores de AD FS con grupos de disponibilidad AlwaysOn requiere una ligera modificación en el procedimiento de implementación de AD FS:
Las bases de datos de las que desea realizar una copia de seguridad deben crearse antes de que se puedan configurar los grupos de disponibilidad AlwaysOn. AD FS crea sus bases de datos como parte de la configuración e configuración inicial del primer nodo de servicio de federación de una nueva granja de servidores de SQL Server de AD FS. Como parte de la configuración de AD FS, debe especificar una cadena de conexión SQL, por lo que tendrá que configurar el primer nodo de la granja de servidores de AD FS para conectarse directamente a una instancia de SQL (solo es temporal). Para obtener instrucciones específicas sobre cómo configurar una granja de AD FS, incluida la configuración de un nodo de granja de AD FS con una cadena de conexión de SQL Server, consulte Configurar un servidor de federación.
Una vez creadas las bases de datos de AD FS, asígnelas a grupos de disponibilidad AlwaysOn y cree el agente de escucha TCPIP común mediante SQL Server herramientas y procesos en creación y configuración de grupos de disponibilidad (SQL Server).
Por último, use PowerShell para editar las propiedades de AD FS para actualizar la cadena de conexión SQL para usar la dirección DNS del agente de escucha del grupo de disponibilidad AlwaysOn.
Comandos PSH de ejemplo para actualizar la cadena de conexión SQL para la base de datos de configuración de AD FS:
PS:\>$temp= Get-WmiObject -namespace root/ADFS -class SecurityTokenService PS:\>$temp.ConfigurationdatabaseConnectionstring="data source=<SQLCluster\SQLInstance>; initial catalog=adfsconfiguration;integrated security=true" PS:\>$temp.put()Comandos PSH de ejemplo para actualizar la cadena de conexión SQL para la base de datos del servicio de resolución de artefactos de AD FS:
PS:\> Set-AdfsProperties –artifactdbconnection "Data source=<SQLCluster\SQLInstance >;Initial Catalog=AdfsArtifactStore;Integrated Security=True"
Replicación de mezcla de SQL Server
También se introdujo en SQL Server 2012, la replicación de mezcla permite la redundancia de datos de directiva de AD FS con las siguientes características:
Capacidad de lectura y escritura en todos los nodos (no solo la principal)
Cantidades más pequeñas de datos replicados de forma asincrónica para evitar la introducción de la latencia al sistema
En el diagrama siguiente se muestra una granja de servidores de SQL Server de AD FS con redundancia geográfica con replicación de mezcla (1 publicador, 2 suscriptores):
Consideraciones clave de implementación para usar AD FS con SQL Server replicación de mezcla (tenga en cuenta los números del diagrama anterior)
La base de datos de distribución no se admite para utilizarse con Grupos de disponibilidad AlwaysOn o con la creación de reflejo de la base de datos. Consulte SQL Server instrucciones de compatibilidad para grupos de disponibilidad AlwaysOn con opciones de replicación en Replicación, Change Tracking, Captura de datos modificados y Grupos de disponibilidad AlwaysOn (SQL Server).
Cuando el grupo de disponibilidad AlwaysOn que contiene la base de datos que es un suscriptor de replicación realiza una conmutación por error, se produce un error en la suscripción de replicación. Para reanudar la replicación, un administrador de replicación debe configurar manualmente el suscriptor. Consulte la descripción SQL Server de un problema específico en Suscriptores de replicación y grupos de disponibilidad AlwaysOn (SQL Server) y instrucciones de compatibilidad general para grupos de disponibilidad AlwaysOn con opciones de replicación en Replicación, Change Tracking, Captura de datos modificados y Grupos de disponibilidad AlwaysOn (SQL Server).
Para obtener instrucciones más detalladas sobre cómo configurar AD FS para usar una replicación de mezcla de SQL Server, consulte Configuración de redundancia geográfica con Replicación de SQL Server.
Consulte también
Planeamiento de la topología de la implementación de AD FSGuía de diseño de AD FS en Windows Server 2012 R2