Étendre les services de fédération Active Directory (AD FS) locaux à Azure

Cette architecture de référence implémente un réseau hybride sécurisé qui étend votre réseau local dans Azure et utilise les services de fédération Active Directory (AD FS) pour procéder à une authentification et une autorisation fédérées pour les composants en cours d’exécution dans Azure.

Architecture

Téléchargez un fichier Visio de cette architecture.

Workflow

• Sous-réseau AD DS. Les serveurs AD DS sont contenus dans leur propre sous-réseau avec des règles de groupe de sécurité réseau agissant comme un pare-feu.

• Serveurs AD DS. Des contrôleurs de domaine s’exécutant en tant que machines virtuelles dans Azure. Ces serveurs fournissent l’authentification des identités locales au sein du domaine.

• Sous-réseau AD FS. Les serveurs AD FS se trouvent dans leur propre sous-réseau avec des règles de groupe de sécurité réseau agissant comme un pare-feu.

• Serveurs AD FS. Les serveurs AD FS fournissent l’authentification et l’autorisation fédérées. Dans cette architecture, ils effectuent les tâches suivantes :

  • Réception des jetons de sécurité contenant les revendications d’un serveur de fédération partenaire pour le compte d’un utilisateur partenaire. AD FS vérifie que les jetons sont valides avant de transmettre les revendications à l’application web s’exécutant dans Azure pour autoriser les demandes.

    L’application s’exécutant dans Azure est la partie de confiance. Le serveur de fédération partenaire doit émettre les revendications qui sont comprises par l’application web. Les serveurs de fédération partenaires sont appelés partenaires de compte, car ils envoient des demandes d’accès pour le compte de comptes authentifiés dans l’organisation partenaire. Les serveurs AD FS sont appelés partenaires de ressource, car ils fournissent l’accès aux ressources (l’application web).

  • Authentifier et autoriser des requêtes entrantes émises par des utilisateurs externes exécutant un navigateur web ou un appareil qui a besoin d’accéder aux applications web, à l’aide des services AD DS et du service Active Directory Device Registration.

  Les serveurs AD FS sont configurés en tant que batterie de serveurs accessible via un équilibreur de charge Azure. Cette implémentation améliore la disponibilité et l’extensibilité. Les serveurs AD FS ne sont pas directement exposés à Internet. Tout le trafic Internet est filtré à travers les serveurs proxy d’application web AD FS et une zone DMZ (également appelée réseau de périmètre).

  Pour plus d’informations sur le fonctionnement des services AD FS, consultez l’article Vue d’ensemble des services de fédération Active Directory. De plus, l’article Déploiement des services AD FS dans Azure contient une présentation détaillée de la procédure d’implémentation.

• Sous-réseau de proxy AD FS. Les serveurs proxy AD FS peuvent être contenus dans leur propre sous-réseau, avec des règles de groupe de sécurité réseau assurant leur protection. Les serveurs localisés dans ce sous-réseau sont exposés à Internet via un ensemble d’appliances réseau virtuelles qui fournissent un pare-feu entre votre réseau virtuel Azure et Internet.

• Serveurs proxy d’application web (WAP) AD FS. Ces machines virtuelles agissent comme des serveurs AD FS pour les demandes entrantes émises par des appareils externes et des organisations partenaires. Les serveurs proxy d’application web agissent comme un filtre pour protéger les serveurs AD FS d’un accès direct à partir d’Internet. Comme avec les serveurs AD FS, le fait de déployer les serveurs proxy d’application web dans une batterie de serveurs avec équilibrage de charge vous offre une meilleure disponibilité et une plus grande extensibilité qu’en déployant une collection de serveurs autonomes.

  Notes

  Pour plus d’informations sur l’installation des serveurs WAP, consultez l’article Installer et configurer le serveur proxy d’application web

• Organisation partenaire. Une organisation partenaire exécutant une application web qui demande l’accès à une application web s’exécutant dans Azure. Le serveur de fédération au niveau de l’organisation partenaire authentifie les requêtes localement et envoie les jetons de sécurité contenant les revendications aux services AD FS s’exécutant dans Azure. Dans Azure, AD FS valide les jetons de sécurité et, le cas échéant, transmet les revendications à l’application web s’exécutant dans Azure pour autoriser les jetons valides.

  Notes

  Vous pouvez également configurer un tunnel VPN à l’aide de la passerelle Azure pour fournir un accès direct à AD FS pour les partenaires de confiance. Les demandes émises par ces partenaires ne passent pas par les serveurs proxy d’application web.

Composants

Cette architecture étend l’implémentation décrite dans l’article Extending AD DS to Azure (Étendre AD DS dans Azure). Elle inclut les composants suivants.

• Sous-réseau AD DS
• Serveurs AD DS
• Sous-réseau AD FS
• Serveurs AD FS
• Sous-réseau de proxy AD FS
• Serveurs proxy d’application web (WAP) AD FS

Détails du scénario

Le composant AD FS peut être hébergé localement, mais si votre application est une application hybride dont certaines parties sont implémentées dans Azure, il peut être plus efficace de répliquer AD FS dans le cloud.

Le diagramme antérieur présente les scénarios suivants :

• Le code d’application d’une organisation partenaire accède à une application web hébergée au sein de votre réseau virtuel Azure.
• Un utilisateur externe enregistré dont les informations d’identification sont stockées dans Active Directory Domain Services (DS) accède à une application web hébergée au sein de votre réseau virtuel Azure.
• Un utilisateur connecté à votre réseau virtuel à l’aide d’un appareil autorisé exécute une application web hébergée au sein de votre réseau virtuel Azure.

Cette architecture de référence se concentre sur la fédération passive dans laquelle les serveurs de fédération décident comment et quand authentifier un utilisateur. L’utilisateur fournit des informations de connexion au démarrage de l’application. Ce mécanisme est le plus couramment utilisé par les navigateurs web et implique un protocole qui redirige le navigateur vers un site sur lequel l’utilisateur s’authentifie. AD FS prend également en charge la fédération active, où une application est chargée de fournir des informations d’identification sans intervention supplémentaire de l’utilisateur, mais ce scénario n’est pas couvert par cette architecture.

Pour d’autres informations, consultez Choisir une solution pour intégrer l’environnement Active Directory local à Azure.

Cas d’usage potentiels

Utilisations courantes de cette architecture :

• Les applications hybrides où les charges de travail s’exécutent en partie en local et dans Azure.
• Les solutions qui utilisent l’autorisation fédérée pour exposer les applications web aux organisations partenaires.
• Les systèmes accessibles depuis des navigateurs web s’exécutant en dehors du pare-feu de l’organisation.
• Les systèmes qui permettent aux utilisateurs d’accéder aux applications web en se connectant à partir d’appareils externes autorisés tels que des ordinateurs distants, des ordinateurs portables et d’autres appareils mobiles.

Recommandations

Les recommandations suivantes s’appliquent à la plupart des scénarios. Suivez ces recommandations, sauf si vous avez un besoin spécifique qui vous oblige à les ignorer.

Recommandations pour la mise en réseau

Configurez l’interface réseau pour chacune des machines virtuelles hébergeant des serveurs AD FS et WAP avec des adresses IP privées statiques.

N’attribuez aucune adresse IP publique aux machines virtuelles AD FS. Pour plus d’informations, consultez la section Considérations relatives à la sécurité.

Définissez l’adresse IP des serveurs de nom de domaine (DNS) par défaut et secondaires pour les interfaces réseau de chaque machine virtuelle AD FS et WAP de manière à référencer les machines virtuelles Active Directory DS. Les machines virtuelles Active Directory DS doivent exécuter un serveur DNS. Cette étape est nécessaire pour que chaque machine virtuelle puisse rejoindre le domaine.

Installation des services AD FS

L’article Deploying a Federation Server Farm (Déploiement d’une batterie de serveurs de fédération) fournit des instructions détaillées pour l’installation et la configuration des services AD FS. Avant de configurer le premier serveur AD FS dans la batterie de serveurs, effectuez les tâches suivantes :

1. Obtenez un certificat approuvé publiquement pour l’authentification du serveur. Le nom de l’objet doit contenir le nom utilisé par les clients pour accéder au service de fédération. Cela peut être le nom DNS enregistré pour l’équilibreur de charge, par exemple, adfs.contoso.com (pour des raisons de sécurité, évitez d’utiliser des noms comprenant des caractères génériques tels que *.contoso.com). Utilisez le même certificat sur toutes les machines virtuelles du serveur AD FS. Vous pouvez acheter un certificat auprès d’une autorité de certification de confiance, mais si votre organisation utilise les services de certificats Active Directory, vous pouvez également créer votre propre certificat.

   L’autre nom de l’objet est utilisé par le service DRS (Device Registration Service) pour activer l’accès à partir d’appareils externes. Il doit être de la forme enterpriseregistration.contoso.com.

   Pour plus d’informations, consultez l’article Obtain and Configure a Secure Sockets Layer (SSL) Certificate for AD FS (Obtenir et configurer un certificat Secure Sockets Layer (SSL) pour AD FS).

2. Sur le contrôleur de domaine, générez une nouvelle clé racine pour le service de distribution de clés. Définissez l’heure effective sur l’heure actuelle à laquelle vous aurez soustrait 10 heures (cette configuration réduit le délai pouvant intervenir lors de la distribution et de la synchronisation des clés dans le domaine). Cette étape est nécessaire pour prendre en charge la création du compte de service de groupe qui est utilisé pour exécuter le service AD FS. La commande PowerShell suivante montre un exemple de la procédure à suivre :

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

3. Ajoutez chaque machine virtuelle du serveur AD FS au domaine.

Approbation AD FS

Établissez une approbation de fédération entre votre installation AD FS et les serveurs de fédération des organisations partenaires. Configurez les paramètres de mappage et de filtrage de revendications tel que requis.

• Le personnel DevOps de chaque organisation partenaire doit ajouter une approbation de partie de confiance pour les applications web accessibles via vos serveurs AD FS.
• Le personnel DevOps de votre organisation doit configurer une approbation de fournisseur de revendications pour que vos serveurs AD FS puissent approuver les revendications émanant des organisations partenaires.
• Le personnel DevOps de votre organisation doit également configurer AD FS pour transmettre les revendications aux applications web de votre organisation.

Pour plus d’informations, consultez l’article Establishing Federation Trust (Établir une approbation de fédération).

Publiez les applications web de votre organisation et rendez-les accessibles aux partenaires externes en activant la préauthentification via les serveurs proxy d’application web (WAP). Pour plus d’informations, consultez l’article Publish Applications using AD FS Preauthentication (Publier des applications avec la préauthentification AD FS)

AD FS prend en charge l’augmentation et la transformation des jetons. Microsoft Entra ID ne fournit pas cette fonctionnalité. Avec AD FS, lorsque vous configurez des relations d’approbation, vous pouvez :

• Configurer des transformations de revendication pour les règles d’autorisation. Par exemple, vous pouvez mapper une sécurité de groupe à partir d’une représentation utilisée par une organisation partenaire non-Microsoft sur un élément que le service Active Directory DS peut autoriser dans votre organisation.
• Convertir des revendications d’un format vers un autre. Par exemple, vous pouvez effectuer un mappage de SAML 2.0 vers SAML 1.1 si votre application prend uniquement en charge les revendications au format SAML 1.1.

Analyse des services AD FS

Le Pack d’administration Microsoft System Center pour les services de fédération Active Directory 2012 R2 fournit une analyse proactive et réactive de votre déploiement AD FS pour le serveur de fédération. Ce pack d’administration surveille :

• Les événements que le service AD FS consigne dans ses journaux d’événements.
• Les données de performance collectées par les compteurs de performances AD FS.
• L’intégrité globale du système AD FS et des applications web (parties de confiance). Enfin, le pack fournit des alertes pour les problèmes critiques et les avertissements.

Une autre option consiste à Surveiller AD FS à l’aide de Microsoft Entra Connect Health. Microsoft Entra Connect Health fournit une supervision robuste de votre infrastructure d’identité locale. Il vous permet de conserver une connexion fiable à Microsoft 365 et aux services en ligne Microsoft. Cette fiabilité est obtenue en fournissant des fonctionnalités de supervision pour vos composants d’identités clés. De plus, il rend les points de données clés relatifs à ces composants facilement accessibles.

Considérations

Ces considérations implémentent les piliers d’Azure Well-Architected Framework qui est un ensemble de principes directeurs qui permettent d’améliorer la qualité d’une charge de travail. Pour plus d'informations, consultez Microsoft Azure Well-Architected Framework.

Efficacité des performances

L’efficacité des performances est la capacité de votre charge de travail à s’adapter à la demande des utilisateurs de façon efficace. Pour plus d’informations, consultez Vue d’ensemble du pilier d’efficacité des performances.

Les considérations suivantes, dont tous les détails sont présentés dans l’article Planifier votre déploiement AD FS, vous donnent un point de départ pour redimensionner les batteries de serveurs AD FS :

• Si vous avez moins de 1 000 utilisateurs, ne créez pas de serveurs dédiés, mais installez plutôt le composant AD FS sur chacun des serveurs Active Directory DS dans le cloud. Assurez-vous de disposer d’au moins deux serveurs Active Directory DS pour garantir la disponibilité. Créez un seul serveur WAP.
• Si vous avez entre 1 000 et 15 000 utilisateurs, créez deux serveurs AD FS dédiés et deux serveurs WAP dédiés.
• Si vous avez entre 15 000 et 60 000 utilisateurs, créez entre trois et cinq serveurs AD FS dédiés et au moins deux serveurs WAP dédiés.

Ces considérations présument que vous utilisez des machines virtuelles doubles à quatre cœurs (Standard D4_v2 ou taille supérieure) dans Azure.

Si vous utilisez la base de données interne Windows pour stocker des données de configuration AD FS, vous ne pouvez ajouter que huit serveurs AD FS dans la batterie de serveurs. Si vous pensez que vous aurez besoin d’autres serveurs à l’avenir, utilisez SQL Server. Pour plus d’informations, consultez l’article The Role of the AD FS Configuration Database (Rôle de la base de données de configuration AD FS).

Fiabilité

La fiabilité permet de s’assurer que votre application tient vos engagements auprès de vos clients. Pour plus d’informations, consultez la page Vue d’ensemble du pilier de fiabilité.

Créez une batterie AD FS comprenant au moins deux serveurs pour augmenter la disponibilité du service. Utilisez des comptes de stockage différents pour chaque machine virtuelle AD FS dans la batterie de serveurs. Cette approche permet de veiller à ce que la batterie de serveurs reste en partie accessible même en cas de panne au niveau d’un compte de stockage spécifique.

Créez des groupes à haute disponibilité Azure distincts pour les machines virtuelles AD FS et WAP. Chaque groupe doit contenir au moins deux machines virtuelles. Chaque groupe à haute disponibilité doit avoir au moins deux domaines de mise à jour et deux domaines d’erreur.

Configurez les équilibreurs de charge pour les machines virtuelles AD FS et WAP tel que suit :

• Utilisez un équilibreur de charge Azure pour fournir un accès externe aux machines virtuelles WAP et un équilibreur de charge interne pour répartir la charge sur les serveurs AD FS au sein de la batterie de serveurs.

• Transmettez uniquement le trafic apparaissant sur le port 443 (HTTPS) aux serveurs AD FS/WAP.

• Attribuez une adresse IP statique à l’équilibreur de charge.

• Créez une sonde d’intégrité à l’aide de HTTP sur /adfs/probe. Pour plus d’informations, consultez Hardware Load Balancer Health Checks and Web Application Proxy / AD FS 2012 R2 (Contrôles d’intégrité et proxy d’application web de l’équilibreur de charge matériel / AD FS 2012 R2).

  Notes

  Les serveurs AD FS utilisent le protocole d’indication du nom de serveur (SNI). Par conséquent, tout test d’intégrité effectué à l’aide d’un point de terminaison HTTPS à partir de l’équilibreur de charge échouera.

• Ajoutez un enregistrement DNS A au domaine pour l’équilibreur de charge AD FS. Spécifiez l’adresse IP de l’équilibreur de charge et donnez-lui un nom dans le domaine (par exemple adfs.contoso.com). Il s’agit du nom que les clients et les serveurs WAP utiliseront pour accéder à la batterie de serveurs AD FS.

Vous pouvez utiliser SQL Server ou la base de données interne Windows pour conserver les informations de configuration AD FS. La base de données interne Windows fournit une redondance de base. Les modifications sont écrites directement dans une seule des bases de données AD FS du cluster AD FS, tandis que les autres serveurs utilisent la réplication par réception pour mettre à jour leurs bases de données. SQL Server peut fournir une redondance de base de données totale et une haute disponibilité grâce à la mise en miroir ou au clustering de basculement.

Sécurité

La sécurité fournit des garanties contre les attaques délibérées, et contre l’utilisation abusive de vos données et systèmes importants. Pour plus d’informations, consultez Vue d’ensemble du pilier Sécurité.

AD FS utilise HTTPS : vérifiez donc que les règles du groupe de sécurité réseau pour le sous-réseau contenant les machines virtuelles de niveau web autorisent les requêtes HTTPS. Ces requêtes peuvent provenir du réseau local, des sous-réseaux contenant la couche web, la couche métier, la couche Données, la zone DMZ privée, la zone DMZ publique et le sous-réseau contenant les serveurs AD FS.

Empêchez l’exposition directe des serveurs AD FS à Internet. Les serveurs AD FS sont des ordinateurs joints à un domaine qui sont autorisés à octroyer des jetons de sécurité. Si un serveur est compromis, un utilisateur malveillant peut émettre des jetons d’accès complet à toutes les applications web et à tous les serveurs de fédération qui sont protégés par AD FS. Si votre système doit gérer des demandes d’utilisateurs externes ne se connectant pas à partir de sites de partenaires de confiance, utilisez des serveurs WAP pour gérer ces demandes. Pour plus d’informations, consultez l’article Where to Place a Federation Server Proxy (Où placer un serveur proxy de fédération).

Placez les serveurs AD FS et les serveurs WAP dans des sous-réseaux distincts avec leur propre pare-feu. Vous pouvez utiliser des règles de groupe de sécurité réseau pour définir les règles du pare-feu. Tous les pare-feu doivent autoriser le trafic sur le port 443 (HTTPS).

Désactivez l’accès en connexion directe aux serveurs AD FS et WAP. Seul le personnel DevOps doit être en mesure de s’y connecter. Ne joignez pas les serveurs WAP au domaine.

Envisagez d’utiliser un ensemble d’appliances réseau virtuelles qui enregistrent tous les détails du trafic transitant par votre réseau virtuel à des fins d’audit.

Optimisation des coûts

L’optimisation des coûts consiste à examiner les moyens de réduire les dépenses inutiles et d’améliorer l’efficacité opérationnelle. Pour plus d’informations, consultez Vue d’ensemble du pilier d’optimisation des coûts.

Les considérations de coûts suivantes s'appliquent aux services utilisés dans cette architecture.

Services de domaine AD

Envisagez d’utiliser Active Directory Domain Services en tant que service partagé entre plusieurs charges de travail pour réduire les coûts. Pour plus d’informations, reportez-vous aux tarifs d’Active Directory Domain Services.

Services de fédération Active Directory (AD FS)

Pour plus d’informations sur les éditions offertes par Microsoft Entra ID, consultez la tarification de Microsoft Entra. La fonctionnalité des services de fédération AD est disponible dans toutes les éditions.

Excellence opérationnelle

Le personnel DevOps doit savoir effectuer les tâches suivantes :

• Gérez les serveurs de fédération, y compris la batterie de serveurs AD FS, la stratégie d’approbation au niveau des serveurs de fédération et les certificats utilisés par les services de fédération.
• Gérez les serveurs WAP, y compris la batterie de serveurs WAP et les certificats.
• Gérez des applications web, notamment la configuration des parties de confiance, les méthodes d’authentification et les mappages de revendications.
• Sauvegardez des composants des services AD FS.

Pour d’autres informations sur DevOps, consultez DevOps : Extension d’Active Directory Domain Services (AD DS) à Azure.

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Auteur principal :

• Sarah Parkes | Architecte de solution cloud

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Étapes suivantes

• Documentation Azure Activity Directory
• Gérer les identités dans les applications multilocataires
• Sécurité de la gestion des identités
• Pare-feu Azure

Ressources associées

• Déployer AD DS dans un réseau virtuel Azure
• Gestion des identités et des accès Microsoft Entra pour AWS