Partager via

Étendre les services de fédération Active Directory locaux à Azure

Équilibrage de charge Azure
Microsoft Entra
Microsoft Entra ID

Cette architecture de référence implémente un réseau hybride sécurisé qui étend votre réseau local à Azure et utilise les services de fédération Active Directory (AD FS) pour effectuer l’authentification fédérée et l’autorisation pour les composants qui s’exécutent dans Azure.

Architecture

Diagramme montrant un exemple d’architecture réseau hybride sécurisée avec AD FS.

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

Workflow

Le workflow suivant correspond au diagramme précédent :

  • Sous-réseau Des services de domaine Active Directory (AD DS) : Les serveurs AD DS sont contenus dans leur propre sous-réseau où les règles de groupe de sécurité réseau (NSG) servent de pare-feu.

  • Serveurs AD DS : Contrôleurs de domaine qui s’exécutent 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 et utilisent des règles de groupe de sécurité réseau comme pare-feu.

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

    • Recevez des jetons de sécurité qui contiennent des revendications effectuées par 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 passer les revendications à l’application web s’exécutant dans Azure pour autoriser les demandes.

      L’application qui s’exécute dans Azure est appelée partie de confiance. Le serveur de fédération partenaire doit émettre des revendications que l’application web comprend. 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 ressources , car ils fournissent l’accès aux ressources (l’application web).

    • Authentifiez et autorisez les requêtes entrantes des utilisateurs externes exécutant un navigateur web ou un appareil qui a besoin d’accéder aux applications web à l’aide d’AD DS et du service d’inscription d’appareil Active Directory (DRS).

    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 exposés directement à Internet. Tout le trafic Internet est filtré via des serveurs de proxy d’application web AD FS (WAP) et une zone démilitarisée (DMZ), également appelée réseau de périmètre.

    Pour plus d’informations, consultez la vue d’ensemble d’AD FS.

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

  • Serveurs WAP AD FS : Ces machines virtuelles servent de serveurs AD FS pour les demandes entrantes provenant d’organisations partenaires et d’appareils externes. Les serveurs WAP agissent comme un filtre qui protège les serveurs AD FS contre l’accès direct à partir d’Internet. Comme pour les serveurs AD FS, le déploiement des serveurs WAP dans une batterie avec équilibrage de charge vous offre une plus grande disponibilité et scalabilité que le déploiement d’une collection de serveurs autonomes. Pour plus d’informations, consultez Installer et configurer le serveur WAP.

  • Organisation partenaire : Une organisation partenaire exécute une application web qui demande l’accès à une application web s’exécutant dans Azure. Le serveur de fédération de l’organisation partenaire authentifie les demandes localement et envoie des jetons de sécurité qui contiennent des revendications à AD FS s’exécutant dans Azure. AD FS dans Azure valide les jetons de sécurité. Si les jetons sont valides, AD FS peut transmettre les revendications à l’application web s’exécutant dans Azure pour les autoriser.

    Note

    Vous pouvez également configurer un tunnel VPN à l’aide d’une passerelle Azure pour fournir un accès direct à AD FS pour les partenaires approuvés. Les demandes reçues de ces partenaires ne passent pas par les serveurs WAP.

Components

Cette architecture étend l’implémentation décrite dans Déployer AD DS dans un réseau virtuel Azure. Il contient les composants suivants :

  • Un sous-réseau AD DS est un objet qui mappe une plage d’adresses IP à un site. Ce mappage permet aux contrôleurs de domaine de diriger efficacement l’authentification et la réplication en fonction de l’emplacement réseau d’un client.

  • Les serveurs AD DS sont des contrôleurs de domaine qui hébergent les services de domaine Active Directory. Ils fournissent l’authentification centralisée, l’application des stratégies et la réplication des données d’annuaire sur les réseaux d’entreprise.

  • Un sous-réseau AD FS est une plage d’adresses IP définie au sein du réseau ou de l’infrastructure virtuelle qui héberge des serveurs AD FS ou des serveurs WAP. Cette plage d’adresses IP permet de sécuriser le flux de trafic et l’authentification prenant en compte le site.

  • Les serveurs AD FS sont des serveurs de fédération internes qui émettent des jetons de sécurité et gèrent les demandes d’authentification à l’aide de protocoles d’identité basés sur des revendications.

  • Un sous-réseau proxy AD FS est un segment réseau, généralement dans une zone DMZ, qui héberge des serveurs WAP. Il permet un relais sécurisé du trafic d’authentification externe vers des serveurs AD FS internes.

  • Les serveurs WAP AD FS sont des serveurs proxy inverses déployés dans des réseaux de périmètre qui préauthentifient les demandes d’utilisateur externe et les transfèrent en toute sécurité à AD FS pour l’accès fédéré.

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 à l’intérieur de votre réseau virtuel Azure.

  • Un utilisateur externe inscrit avec des informations d’identification stockées dans Active Directory Domain Services (AD DS) accède à une application web hébergée à l’intérieur 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 à l’intérieur 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 prend en charge la fourniture d’informations d’identification sans interaction utilisateur supplémentaire, mais ce scénario est en dehors de l’étendue de cette architecture.

Pour d’autres considérations, consultez Intégrer des domaines Active Directory locaux à l’ID Microsoft Entra.

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.

Recommendations

Vous pouvez appliquer les recommandations suivantes à 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 les serveurs AD FS et WAP qui ont 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 DNS (Domain Name Service) préférés et secondaires pour les interfaces réseau de chaque machine virtuelle AD FS et WAP pour référencer les machines virtuelles AD DS. Les machines virtuelles AD DS doivent exécuter DNS. Cette étape est nécessaire pour que chaque machine virtuelle puisse rejoindre le domaine.

Installation des services AD FS

L’article Déployer une batterie de serveurs de fédération fournit des instructions détaillées sur l’installation et la configuration d’AD FS. Effectuez les tâches suivantes avant de configurer le premier serveur AD FS dans votre batterie de serveurs :

  1. Obtenez un certificat approuvé publiquement pour l’authentification du serveur. Le nom de l’objet doit contenir le nom que les clients utilisent pour accéder au service de fédération. Cet identificateur peut être le nom DNS inscrit pour l’équilibreur de charge, tel que adfs.contoso.com. Évitez d’utiliser des noms génériques tels que *.contoso.com pour des raisons de sécurité. 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 approuvée, mais si votre organisation utilise les services de certificats Active Directory, vous pouvez créer votre propre certificat.

    La récupération d’urgence utilise le nom de remplacement de l’objet pour activer l’accès à partir d’appareils externes. Ce nom DNS doit suivre le format enterpriseregistration.contoso.com.

    Pour plus d’informations, consultez Obtenir et configurer un certificat Secure Sockets Layer 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 (KDS). Définissez l’heure effective sur l’heure actuelle moins de 10 heures. Cette configuration réduit le délai qui peut se produire 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 utilisé pour exécuter le service AD FS. La commande PowerShell suivante montre comment générer une nouvelle clé racine KDS avec un décalage de temps :

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

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

Note

Pour installer AD FS, le contrôleur de domaine qui exécute le rôle d’opération maître unique flexible de l’émulateur de contrôleur de domaine principal pour le domaine doit être en cours d’exécution et accessible à partir des machines virtuelles AD FS.

Approbation AD FS

Établissez l’approbation de fédération entre votre installation AD FS et les serveurs de fédération de n’importe quelle organisation partenaire. Configurez tout filtrage et mappage de revendications 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 É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 Publier des applications à l’aide de 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é. À l’aide d’AD FS, lorsque vous configurez les relations d’approbation, vous pouvez effectuer les tâches suivantes :

  • Configurer des transformations de revendication pour les règles d’autorisation. Par exemple, vous pouvez mapper la sécurité de groupe à partir d’une représentation utilisée par une organisation partenaire non-Microsoft à quelque chose que AD 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 AD FS 2012 R2 fournit à la fois une surveillance proactive et réactive de votre déploiement AD FS pour le serveur de fédération. Ce pack d’administration surveille les aspects suivants de votre déploiement AD FS :

  • Événements que le service AD FS enregistre dans ses journaux d’événements

  • Données de performances collectées par les compteurs de performances AD FS

  • Intégrité globale du système AD FS et des applications web (parties de confiance) et pour les problèmes et avertissements critiques

Une autre option consiste à surveiller AD FS à l’aide de Microsoft Entra Connect Health. Connect Health assure la surveillance de votre infrastructure d’identité locale. Il vous permet de maintenir une connexion fiable aux services en ligne Microsoft 365 et Microsoft. Elle assure cette fiabilité en fournissant des fonctionnalités de supervision pour vos composants d’identité clés. Il rend également les points de données clés sur ces composants accessibles.

Considerations

Ces considérations implémentent les piliers d’Azure Well-Architected Framework, un ensemble de principes directeurs que vous pouvez utiliser pour améliorer la qualité d’une charge de travail. Pour plus d’informations, consultez Well-Architected Framework.

Reliability

La fiabilité permet de s’assurer que votre application peut respecter les engagements que vous prenez à vos clients. Pour plus d’informations, consultez liste de vérification de la révision de conception pour lede fiabilité.

Créez une batterie de serveurs AD FS avec un minimum de 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 s’assurer qu’une défaillance dans un seul compte de stockage ne rend pas la batterie de serveurs entière inaccessible.

Créez des groupes à haute disponibilité Azure distincts pour les machines virtuelles AD FS et WAP. Vérifiez qu’il existe au moins deux machines virtuelles dans chaque ensemble. Chaque groupe à haute disponibilité doit avoir au minimum deux domaines de mise à jour et deux domaines d’erreur.

Configurez les équilibreurs de charge pour les machines virtuelles AD FS et les machines virtuelles WAP en procédant comme suit :

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

  • Passez uniquement le trafic qui s’affiche sur le port 443 (HTTPS) vers les serveurs AD FS ou WAP.

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

  • Créez une sonde d’intégrité à l’aide de HTTP par rapport /adfs/probeà . Pour plus d’informations, consultez Créer une sonde d’intégrité HTTP/HTTPS personnalisée pour Azure Load Balancer.

    Note

    Les serveurs AD FS utilisent le protocole d’indication du nom du serveur, ce qui entraîne l’échec des sondes de point de terminaison HTTPS de l’équilibreur de charge.

  • Ajoutez un enregistrement DNS A au domaine de l’équilibreur de charge AD FS. Spécifiez l’adresse IP de l’équilibreur de charge et attribuez-lui un nom dans le domaine, par adfs.contoso.comexemple . Cet enregistrement DNS est le nom que les clients et les serveurs WAP utilisent 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. L’utilisation de SQL Server peut fournir une redondance de base de données complète et une haute disponibilité à l’aide du clustering de basculement ou de la mise en miroir.

Security

La sécurité offre des garanties contre les attaques délibérées et l’utilisation abusive de vos données et systèmes précieux. Pour plus d’informations, consultez liste de vérification de la révision de conception pour security.

AD FS utilise HTTPS. Assurez-vous donc que les règles de groupe de sécurité réseau pour le sous-réseau qui contiennent les machines virtuelles de niveau web autorisent les requêtes HTTPS. Ces requêtes peuvent provenir du réseau local, des sous-réseaux qui contiennent le niveau web, le niveau Business, la couche Données, la zone DMZ privée, la zone DMZ publique et le sous-réseau qui contient 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 les demandes des invités qui ne se connectent pas à partir de sites partenaires approuvés, utilisez des serveurs WAP pour gérer ces demandes. Pour plus d’informations, consultez Où placer un proxy de serveur de fédération.

Placez les serveurs AD FS et les serveurs WAP dans des sous-réseaux distincts qui ont leurs propres 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).

Limitez l’accès de 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 virtuelles réseau qui journalisent des informations détaillées sur le trafic parcourant la périphérie de votre réseau virtuel à des fins d’audit.

Optimisation des coûts

L’optimisation des coûts se concentre sur les moyens de réduire les dépenses inutiles et d’améliorer l’efficacité opérationnelle. Pour plus d’informations, consultez liste de vérification de la révision de conception pour l’optimisation des coûts.

Services de domaine Microsoft Entra

Envisagez d’avoir Microsoft Entra Domain Services en tant que service partagé que plusieurs charges de travail consomment pour réduire les coûts. Pour plus d’informations, consultez la tarification des services de domaine.

AD FS

Pour plus d’informations sur les éditions fournies par l’ID Microsoft Entra, consultez la tarification de Microsoft Entra. La fonctionnalité AD FS est disponible dans toutes les éditions.

Excellence opérationnelle

L’excellence opérationnelle couvre les processus d’exploitation qui déploient une application et la conservent en production. Pour plus d’informations, consultez liste de vérification de la révision de conception pour l’excellence opérationnelle.

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

  • Gérer les serveurs de fédération, notamment la gestion de la batterie de serveurs AD FS, la gestion de la stratégie d’approbation sur les serveurs de fédération et la gestion des certificats utilisés par les services de fédération

  • Gérer les serveurs WAP, notamment la gestion de la batterie de serveurs et des certificats WAP

  • Gérer les applications web, notamment la configuration des parties de confiance, des méthodes d’authentification et des mappages de revendications

  • Sauvegarder des composants AD FS

Pour obtenir d’autres considérations relatives à DevOps, consultez Déployer AD DS dans un réseau virtuel Azure.

Efficacité des performances

L’efficacité des performances fait référence à la capacité de votre charge de travail à mettre à l’échelle pour répondre efficacement aux demandes des utilisateurs. Pour plus d’informations, consultez liste de vérification de la révision de conception pour l’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. Au lieu de cela, installez AD FS sur chacun des serveurs AD DS dans le cloud. Assurez-vous que vous disposez d’au moins deux serveurs AD DS pour maintenir 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 les données de configuration AD FS, vous êtes limité à huit serveurs AD FS dans la batterie de serveurs. Si vous pensez que vous en aurez besoin plus à l’avenir, utilisez SQL Server. Pour plus d’informations, consultez Le rôle de la base de données de configuration AD FS.

Contributors

Microsoft gère cet article. Les contributeurs suivants ont écrit cet article.

Auteur principal :

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

Étapes suivantes