Partager via

Batterie de serveurs de fédération AD FS héritée utilisant SQL Server

Cette topologie pour Active Directory Federation Services (AD FS) diffère de la batterie de serveurs de fédération utilisant la topologie de déploiement Base de données interne Windows (WID) en cela qu’elle ne réplique pas les données sur chaque serveur de fédération de la batterie. Au lieu de cela, tous les serveurs de fédération de la batterie de serveurs peuvent lire et écrire des données dans une base de données commune stockée sur un serveur exécutant Microsoft SQL Server qui se trouve dans le réseau d’entreprise.

Important

Si vous voulez créer une batterie AD FS et utiliser SQL Server pour stocker vos données de configuration, vous pouvez utiliser SQL Server 2008 et versions plus récentes, notamment SQL Server 2012 et SQL Server 2014.

Points à prendre en considération pour le déploiement

Cette section décrit différentes considérations relatives à l’audience visée, aux avantages et aux limitations associés à cette topologie de déploiement.

À qui s’adresse cette topologie ?

  • Les grandes organisations avec plus de 100 relations d’approbation qui doivent fournir à leurs utilisateurs internes et externes un accès à l’authentification unique (SSO) aux applications ou services fédérés

  • Les organisations qui utilisent déjà SQL Server et souhaitent tirer parti de leurs outils et de leur expertise existants

Quels sont les avantages de l’utilisation de cette topologie ?

  • Prise en charge d’un plus grand nombre de relations d’approbation (plus de 100)

  • Prise en charge de la détection de relecture de jeton (fonctionnalité de sécurité) et de la résolution d’artefacts (dans le cadre du protocole SAML (Security Assertion Markup Language) 2,0)

  • Prise en charge de tous les avantages des SQL Server, comme la mise en miroir de bases de données, le clustering de basculement et les outils de création de rapports et de gestion

Quelles sont les limitations de l’utilisation de cette topologie ?

  • Cette topologie ne fournit pas de redondance de base de données par défaut. Bien qu’une batterie de serveurs de fédération avec topologie WID réplique automatiquement la base de données WID sur chaque serveur de fédération de la batterie de serveurs, la batterie de serveurs de fédération avec topologie SQL Server contient une seule copie de la base de données

    Remarque

    SQL Server prend en charge de nombreuses options de redondance des données et des applications, notamment le clustering de basculement, la mise en miroir de bases de données et plusieurs types de réplication de SQL Server.

Le service informatique de Microsoft utilise la mise en miroir de bases de données SQL Server en mode de haute sécurité (synchrone) et le clustering de basculement pour fournir une prise en charge haute disponibilité de l’instance SQL Server. La réplication transactionnelle SQL Server (pair à pair) et de fusion n’ont pas été testées par l’équipe produit AD FS de Microsoft. Pour plus d’informations sur SQL Server, consultez Vue d’ensemble des solutions à haute disponibilité ou Sélection du type de réplication approprié.

Versions SQL Server prises en charge

Les versions de SQL Server suivantes sont prises en charge avec AD FS dans Windows Server 2012 R2 :

  • SQL Server 2008/R2

  • SQL Server 2012

  • SQL Server 2014

Recommandations relatives à l’emplacement du serveur et à la disposition du réseau

À l’instar de la batterie de serveurs de fédération avec topologie WID, tous les serveurs de fédération de la batterie de serveurs sont configurés pour utiliser un nom DNS de cluster (qui représente le nom du service de fédération) et une adresse IP de cluster dans le cadre de la configuration du cluster d’équilibrage de charge réseau (NLB). Cela permet à l’hôte NLB d’allouer des requêtes client aux serveurs de fédération individuels. Les proxys de serveur de fédération peuvent être utilisés pour mettre en proxy les demandes clientes vers la batterie de serveurs de fédération.

L’illustration suivante montre comment la société fictive Contoso Pharmaceuticals a déployé sa batterie de serveurs de fédération avec la topologie SQL Server dans le réseau d’entreprise. Elle montre également comment cette entreprise a configuré le réseau de périmètre avec accès à un serveur DNS, un hôte NLB supplémentaire qui utilise le même nom DNS de cluster (fs.contoso.com) que celui utilisé sur le cluster d’équilibrage de charge réseau d’entreprise, et avec deux proxys d’application web (wap1 et wap2).

Illustration that shows how the fictional Contoso Pharmaceuticals company deployed its federation server farm with SQL Server topology in the corporate network.

Pour plus d’informations sur la configuration d’un environnement réseau avec des serveurs de fédération ou des proxys d’application web, consultez la section « Exigences de résolution de noms » dans Configuration requise pour AD FS et Planification de l’infrastructure de Proxy d’application Web (WAP).

Options de haute disponibilité pour les batteries de serveurs SQL Server

Pour AD FS dans Windows Server 2012 R2, il existe deux nouvelles options pour prendre en charge la haute disponibilité dans les batteries de serveurs AD FS à l’aide de SQL Server.

  • Prise en charge des groupes de disponibilité SQL Server AlwaysOn

  • Prise en charge de la haute disponibilité distribuée géographiquement à l’aide de la réplication de fusion SQL Server

Cette section décrit chacune de ces options, les problèmes qu’elles résolvent respectivement et certaines considérations clés pour décider des options à déployer.

Notes

Les batteries de serveurs AD FS qui utilisent la base de données interne Windows (WID) fournissent une redondance des données de base avec un accès en lecture/écriture sur le nœud du serveur de fédération principal et un accès en lecture seule sur les nœuds secondaires.  Cela peut être utilisé dans une topologie géographiquement locale ou géographiquement distribuée.

L’utilisation de WID présente les limitations suivantes :

  • Une batterie WID est limitée à 30 serveurs de fédération si vous avez 100 approbations de parties de confiance ou moins.
  • Une batterie WID ne prend pas en charge la détection des relectures de jetons ni la résolution d’artefacts (qui font partie du protocole SAML (Security Assertion Markup Language)).

Le tableau suivant résume l’utilisation d’une batterie WID :

Approbations de partie de confiance 1-100 Plus de 100 approbations de partie de confiance
Nœuds AD FS 1-30 : WID pris en charge Nœuds AD FS 1-30 : Non pris en charge avec WID - SQL Server requis
Plus de 30 nœuds AD FS : Non pris en charge avec WID - SQL Server requis Plus de 30 nœuds AD FS : Non pris en charge avec WID - SQL Server requis

Groupes de disponibilité AlwaysOn

Présentation

Les groupes de disponibilité AlwaysOn ont été introduits dans SQL Server 2012 et offrent un nouveau moyen de créer une instance SQL Server haute disponibilité.  Les groupes de disponibilité AlwaysOn combinent des éléments de clustering et de mise en miroir de bases de données pour la redondance et le basculement au niveau de la couche d’instance SQL et de la couche de base de données.  Contrairement aux options de haute disponibilité précédentes, les groupes de disponibilité AlwaysOn ne nécessitent pas de stockage commun (ou réseau de zone de stockage) au niveau de la couche de base de données.

Un groupe de disponibilité se compose d’un réplica principal (ensemble de bases de données primaires en lecture-écriture) et d’un à quatre réplicas de disponibilité (ensembles de bases de données secondaires correspondantes).  Le groupe de disponibilité prend en charge une copie en lecture-écriture unique (le réplica principal) et un à quatre réplicas de disponibilité en lecture seule.  Chaque réplica de disponibilité doit résider sur un nœud différent d'un cluster de clustering de basculement Windows Server (WSFC).  Pour plus d’informations sur les groupes de disponibilité AlwaysOn, consultez Vue d’ensemble des groupes de disponibilité AlwaysOn (SQL Server).

Du point de vue des nœuds d’une batterie AD FS SQL Server, le groupe de disponibilité AlwaysOn remplace l’instance SQL Server unique en tant que base de données de stratégie/artefact.  L’écouteur de groupe de disponibilité est ce que le client (le service d’émission de jeton de sécurité AD FS) utilise pour se connecter à SQL.

Le diagramme suivant illustre une batterie de serveurs AD FS SQL Server avec un groupe de disponibilité AlwaysOn.

Diagram that shows an AD FS SQL Server Farm with AlwaysOn Availability group.

Note

Les groupes de disponibilité AlwaysOn nécessitent que les instances SQL Server résident sur des nœuds WSFC (Windows Server Failover Clustering).

Notes

Un seul réplica de disponibilité peut faire office de cible de basculement automatique ; les trois autres s’appuient sur des basculements manuels.

Considérations clés relatives au déploiement

Si vous envisagez d’utiliser des groupes de disponibilité AlwaysOn en combinaison avec la réplication de fusion SQL Server, notez les problèmes décrits sous « Considérations clés en matière de déploiement pour l’utilisation d’AD FS avec la réplication de fusion SQL Server » ci-dessous.  En particulier, lorsqu’un groupe de disponibilité AlwaysOn contenant une base de données est un abonné de réplication et bascule, l’abonnement de réplication échoue. Pour reprendre la réplication, un administrateur de réplication doit reconfigurer l'abonné manuellement.  Consultez la description SQL Server d’un problème spécifique dans Abonnés de réplication et groupes de disponibilité AlwaysOn (SQL Server) et les instructions de support générales pour les groupes de disponibilité AlwaysOn avec des options de réplication dans Réplication, suivi des modifications, capture des données modifiées et groupes de disponibilité AlwaysOn (SQL Server).

Configuration d’AD FS pour utiliser un groupe de disponibilité AlwaysOn

La configuration d’une batterie AD FS avec des groupes de disponibilité AlwaysOn nécessite une légère modification de la procédure de déploiement d’AD FS :

  1. Les bases de données que vous souhaitez sauvegarder doivent être créées avant que les groupes de disponibilité AlwaysOn puissent être configurés.  AD FS crée ses bases de données dans le cadre de l’installation et de la configuration initiale du premier nœud de service de fédération d’une nouvelle batterie AD FS SQL Server.  Dans le cadre de la configuration d’AD FS, vous devez spécifier une chaîne de connexion SQL. Vous devez donc configurer le premier nœud de la batterie AD FS pour qu’il se connecte directement à une instance SQL (ce n’est que temporaire).   Pour obtenir des conseils spécifiques sur la configuration d’une batterie AD FS, notamment la configuration d’un nœud de batterie AD FS avec une chaîne de connexion SQL Server, consultez Configurer un serveur de fédération.

  2. Une fois les bases de données AD FS créées, affectez-les aux groupes de disponibilité AlwaysOn et créez l’écouteur TCPIP commun à l’aide d’outils et de processus SQL Server dans Création et configuration des groupes de disponibilité Always On (SQL Server).

  3. Enfin, utilisez PowerShell pour modifier les propriétés d’AD FS afin de mettre à jour la chaîne de connexion SQL afin d’utiliser l’adresse DNS de l’écouteur du groupe de disponibilité AlwaysOn.

    Exemples de commandes PSH pour mettre à jour la chaîne de connexion SQL pour la base de données de configuration 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()

  4. Exemples de commandes PSH pour mettre à jour la chaîne de connexion SQL pour la base de données du service de résolution d’artefacts AD FS :

    PS:\> Set-AdfsProperties –artifactdbconnection "Data source=<SQLCluster\SQLInstance >;Initial Catalog=AdfsArtifactStore;Integrated Security=True"

Réplication de fusion SQL Server

Également introduite dans SQL Server 2012, la réplication de fusion permet la redondance des données de stratégie AD FS avec les caractéristiques suivantes :

  • Capacité de lecture et d’écriture sur tous les nœuds (et pas seulement sur le serveur principal)

  • De plus petites quantités de données répliquées de manière asynchrone pour éviter d’introduire une latence dans le système

Le diagramme suivant montre une batterie AD FS SQL Server géographiquement redondante avec réplication de fusion (1 éditeur, 2 abonnés) :

server farm using SQL

Considérations clés relatives au déploiement pour l’utilisation d’AD FS avec la réplication de fusion SQL Server (notez les numéros dans le diagramme ci-dessus)

Pour obtenir des instructions plus détaillées sur la configuration d’AD FS pour utiliser une réplication de fusion SQL Server, consultez Configurer une redondance géographique avec la réplication SQL Server.

Voir aussi

Planification d’une topologie de déploiement AD FSGuide de conception AD FS dans Windows Server 2012 R2