Partager via

Meilleures pratiques en matière de services de fédération Active Directory (AD FS)

Le présent document décrit les bonnes pratiques pour sécuriser la planification et le déploiement des services de fédération Active Directory (AD FS) et du proxy d’application web. Il contient des recommandations à propos de configurations de sécurité supplémentaires, de cas d’usage spécifiques et d’autres exigences de sécurité.

Ce document s’applique à AD FS et au proxy d’application web dans Windows Server 2012 R2, 2016 et 2019. Ces recommandations peuvent être utilisées sur un réseau local ou dans un environnement hébergé dans le cloud comme Microsoft Azure.

Topologie de déploiement standard

Pour un déploiement dans des environnements locaux, nous recommandons d’utiliser une topologie de déploiement standard composée des éléments suivants :

  • Un ou plusieurs serveurs AD FS sur le réseau d’entreprise interne.
  • Un ou plusieurs serveurs de proxy d’application web dans une zone démilitarisée (DMZ) ou un réseau extranet.

Au niveau de chaque couche, AD FS et proxy d’application web, un équilibreur de charge matérielle ou logicielle est placé devant la batterie de serveurs et gère le routage du trafic. Des pare-feu sont placés devant l’adresse IP externe de l’équilibreur de charge selon les besoins.

Diagramme illustrant une topologie AD FS standard.

Remarque

AD FS nécessite un contrôleur de domaine accessible en écriture complète pour fonctionner par opposition à un contrôleur de domaine en lecture seule. Si une topologie planifiée inclut un contrôleur de domaine en lecture seule, le contrôleur de domaine en lecture seule peut être utilisé pour l’authentification, mais le traitement des revendications LDAP nécessite une connexion au contrôleur de domaine accessible en écriture.

Renforcement de vos serveurs AD FS

Voici la liste des bonnes pratiques et recommandations pour renforcer et sécuriser votre déploiement AD FS :

  • Vérifiez que seuls les administrateurs Active Directory et les administrateurs AD FS disposent de droits d’administrateur sur le système AD FS.
  • Réduisez l’appartenance au groupe Administrateurs local sur tous les serveurs AD FS.
  • Exigez que tous les administrateurs cloud utilisent une authentification multifacteur (MFA).
  • Limitez au minimum les capacités d’administration par le biais d’agents.
  • Limitez l’accès au réseau par le biais d’un pare-feu hôte.
  • Vérifiez que les administrateurs AD FS utilisent des stations de travail dédiées à l’administration pour protéger leurs informations d’identification.
  • Placez les objets ordinateur des serveurs AD FS dans une unité d’organisation de niveau supérieur qui n’héberge pas aussi d’autres serveurs.
  • Tous les GPO applicables aux serveurs AD FS ne doivent s’appliquer qu’à eux, et pas à d’autres serveurs également. Ainsi, toute réaffectation potentielle de privilèges par le biais d’une modification des GPO se retrouve limitée.
  • Vérifiez que les certificats installés sont protégés contre le vol (ne les stockez pas dans un partage sur le réseau) et définissez un rappel dans le calendrier pour vous assurer de leur renouvellement avant leur expiration (un certificat qui a expiré interrompt l’authentification de fédération). En outre, nous vous recommandons de protéger les clés/certificats de signature dans un module de sécurité matériel (HSM) attaché à AD FS.
  • Définissez la journalisation au niveau le plus élevé et envoyez les journaux AD FS (et de sécurité) à un SIEM pour les mettre en corrélation avec l’authentification AD et AzureAD (ou similaire).
  • Supprimez les protocoles et fonctionnalités Windows inutiles.
  • Utilisez un mot de passe long (> 25 caractères) et complexe pour le compte de service AD FS. Nous vous recommandons d’utiliser un compte de service administré de groupe (GMSA) comme compte de service, car vous n’aurez plus besoin de gérer le mot de passe de ce compte de service puisqu’il se gérera automatiquement.
  • Effectuez une mise à jour vers la dernière version d’AD FS pour améliorer la sécurité et la journalisation (comme toujours, testez-la au préalable).

Ports nécessaires

Le diagramme ci-dessous illustre les ports de pare-feu à activer entre et parmi les composants du déploiement d’AD FS et du proxy d’application web. Si le déploiement n'inclut pas Microsoft Entra ID/Office 365, les exigences de synchronisation peuvent être ignorées.

Remarque

Le port 49443 est uniquement nécessaire si l'authentification par certificat utilisateur est utilisée, ce qui est facultatif pour Microsoft Entra ID et Office 365.

Diagramme montrant les ports et protocoles nécessaires pour un déploiement AD FS.

Notes

Le port 808 (Windows Server 2012 R2) ou le port 1501 (Windows Server 2016+) correspond au port TCP Net. qu’AD FS utilise pour le point de terminaison WCF local afin de transférer les données de configuration vers le processus de service et PowerShell. Ce port peut être vu en exécutant Get-AdfsProperties | select NetTcpPort. Il s’agit d’un port local qui n’a pas besoin d’être ouvert dans le pare-feu, mais qui s’affichera dans une analyse de port.

Communication entre les serveurs de fédération

Les serveurs de fédération sur une batterie de serveurs AD FS communiquent avec d’autres serveurs de la batterie et avec les serveurs du proxy d’application web par le biais du port HTTP 80 pour la synchronisation de la configuration. Vérifiez que seuls ces serveurs peuvent communiquer entre eux et qu’aucun autre n’est une mesure de défense en profondeur.

Les organisations peuvent atteindre cet état en configurant des règles de pare-feu sur chaque serveur. Les règles doivent autoriser uniquement les communications entrantes à partir des adresses IP des serveurs de la batterie et des serveurs du proxy d’application web. Certains équilibreurs de charge réseau (NLB) utilisent le port HTTP 80 pour sonder l’intégrité sur des serveurs de fédération individuels. Veillez à inclure les adresses IP de l’équilibreur de charge réseau dans les règles de pare-feu configurées.

Microsoft Entra Connect et serveurs de fédération AD FS/WAP

Ce tableau décrit les ports et protocoles requis pour la communication entre le serveur Microsoft Entra Connect et les serveurs Federation/WAP.

Protocole Ports Description
HTTP 80 (TCP/UDP) Utilisé pour télécharger des listes de révocation de certificats en vue de vérifier les certificats SSL.
HTTPS 443(TCP/UDP) Utilisé pour synchroniser avec Microsoft Entra ID.
WinRM 5985 Écouteur WinRM.

Proxy d’application web et serveurs de fédération

Ce tableau décrit les ports et les protocoles nécessaires à la communication entre les serveurs de fédération et les serveurs WAP.

Protocol Ports Description
HTTPS 443(TCP/UDP) Utilisé pour l’authentification.

Proxy d’application web et utilisateurs

Ce tableau décrit les ports et les protocoles nécessaires à la communication entre les utilisateurs et les serveurs WAP.

Protocol Ports Description
HTTPS 443(TCP/UDP) Utilisé pour l’authentification des appareils.
TCP 49443 (TCP) Utilisé pour l’authentification par certificat.

Pour plus d’informations sur les ports et protocoles nécessaires pour des déploiements hybrides, consultez Ports de connexion de référence hybride.

Pour plus d'informations sur les ports et les protocoles nécessaires pour un déploiement Microsoft Entra ID et Office 365, consultez le document URL et plages d'adresses IP Office 365.

Points de terminaison activés

Quand AD FS et le proxy d’application web sont installés, un ensemble par défaut de points de terminaison AD FS est activé sur le service de fédération et sur le proxy. Ces points de terminaison par défaut ont été choisis en fonction des scénarios les plus couramment exigés et utilisés. Il n’est pas nécessaire de les modifier.

Ensemble minimal de proxy de points de terminaison activés pour Microsoft Entra ID/Office 365 (facultatif)

Les organisations déployant AD FS et le WAP uniquement pour des scénarios Microsoft Entra ID et Office 365 peuvent même limiter davantage le nombre de points de terminaison AD FS activés sur le proxy pour obtenir une surface d'attaque encore plus réduite. Voici la liste des points de terminaison à activer sur le proxy dans ces scénarios :

Point de terminaison Objectif
/adfs/ls/ Les flux d'authentification basés sur un navigateur et les versions actuelles de Microsoft Office utilisent ce point de terminaison pour l'authentification Microsoft Entra ID et d'Office 365
/adfs/services/trust/2005/usernamemixed Utilisé pour Exchange Online avec les clients Office antérieurs à la mise à jour de mai 2015 d’Office 2013. Les clients ultérieurs utilisent le point de terminaison \adfs\ls passif.
/adfs/services/trust/13/usernamemixed Utilisé pour Exchange Online avec les clients Office antérieurs à la mise à jour de mai 2015 d’Office 2013. Les clients ultérieurs utilisent le point de terminaison \adfs\ls passif.
/adfs/oauth2/ Utilisé pour toutes les applications modernes (locales ou dans le cloud) que vous avez configurées pour vous authentifier directement auprès d'AD FS (autrement dit, pas par le biais Microsoft Entra ID)
/adfs/services/trust/mex Utilisé pour Exchange Online avec les clients Office antérieurs à la mise à jour de mai 2015 d’Office 2013. Les clients ultérieurs utilisent le point de terminaison \adfs\ls passif.
/federationmetadata/2007-06/federationmetadata.xml Exigé pour tous les flux passifs et utilisé par Office 365/Microsoft Entra ID pour vérifier les certificats AD FS.

Les points de terminaison AD FS peuvent être désactivés sur le proxy à l’aide de l’applet de commande PowerShell suivante :

Set-AdfsEndpoint -TargetAddressPath <address path> -Proxy $false

Set-AdfsEndpoint -TargetAddressPath /adfs/services/trust/13/certificatemixed -Proxy $false

Protection étendue de l'authentification

La protection étendue de l’authentification est une fonctionnalité qui atténue les attaques de l’intercepteur (Man-In-The-Middle). Elle est activée par défaut avec AD FS. Le paramètre peut être vérifié à l’aide de l’applet de commande PowerShell ci-dessous :

Get-ADFSProperties

La propriété est ExtendedProtectionTokenCheck. Le paramètre par défaut est Autoriser, afin que les avantages en matière de sécurité puissent être obtenus sans problèmes de compatibilité avec les navigateurs qui ne prennent pas en charge cette fonctionnalité.

Contrôle de congestion pour protéger le service de fédération

Le proxy du service de fédération (qui fait partie du proxy d’application web) assure un contrôle de congestion pour protéger le service AD FS contre toute inondation de requêtes. Le proxy d’application web rejette les requêtes d’authentification de clients externes si le serveur de fédération est surchargé ; l’état de surcharge est déterminé par la latence entre le proxy d’application web et le serveur de fédération. Cette fonctionnalité est configurée par défaut avec un niveau de seuil de latence recommandé. Pour vérifier les paramètres, vous pouvez effectuer les opérations suivantes :

  1. Sur l'ordinateur proxy d'application web, lancez une fenêtre de commande avec des privilèges élevés.
  2. Accédez au répertoire AD FS situé à l’emplacement %WINDIR%\adfs\config.
  3. Remplacez les valeurs par défaut des paramètres de contrôle de congestion par <congestionControl latencyThresholdInMSec="8000" minCongestionWindowSize="64" enabled="true" />.
  4. Enregistrez et fermez le fichier.
  5. Redémarrez les services AD FS en exécutant successivement net stop adfssrv et net start adfssrv.

Pour obtenir des instructions sur cette fonctionnalité, consultez Configurer l’accès extranet pour les services AD FS sur Windows Server 2012 R2.

Vérifications des requêtes HTTP standard sur le proxy

Le proxy effectue également les vérifications standard suivantes sur tout le trafic :

  • Le FS-P s’authentifie lui-même auprès d’AD FS par le biais d’un certificat de courte durée. Dans un scénario de suspicion de compromission des serveurs DMZ, AD FS peut « révoquer l’approbation du proxy » afin qu’il n’approuve plus aucune requête entrante provenant de proxys potentiellement compromis. La révocation de l’approbation du proxy permet de révoquer le certificat de chaque proxy afin qu’il ne puisse pas s’authentifier correctement auprès du serveur AD FS, quel que soit son but.
  • Le FS-P arrête toutes les connexions et crée une connexion HTTP au service AD FS sur le réseau interne. Un tampon est ainsi fourni au niveau de la session entre les appareils externes et le service AD FS. L’appareil externe ne se connecte jamais directement au service AD FS.
  • Le FS-P effectue la validation des requêtes HTTP qui filtre précisément les en-têtes HTTP qui ne sont pas exigés par le service AD FS.

Vérifiez que tous les serveurs AD FS et du proxy d’application web reçoivent les mises à jour les plus récentes. La recommandation de sécurité la plus importante pour votre infrastructure AD FS consiste à vérifier que vous disposez d’un moyen en place pour tenir à jour vos serveurs AD FS et vos serveurs de proxy d’application web avec toutes les mises à jour de sécurité, ainsi que les mises à jour facultatives spécifiées comme étant importantes pour AD FS dans cette page.

La méthode recommandée pour que les clients Microsoft Entra surveillent et conservent leur infrastructure actuelle via Microsoft Entra Connect Health pour AD FS, une fonctionnalité de Microsoft Entra ID P1 ou P2. Microsoft Entra Connect Health inclut des moniteurs et des alertes qui se déclenchent si une machine AD FS ou une machine WAP ne disposent pas de l'une des mises à jour importantes pour AD FS et du WAP.

Pour en savoir plus sur le monitoring de l'intégrité pour AD FS, consultez Installation de l'agent Microsoft Entra Connect Health.

Meilleures pratiques pour la sécurisation et la supervision de l’approbation AD FS avec Microsoft Entra ID

Lorsque vous fédérez votre AD FS avec Microsoft Entra ID, il est essentiel que la configuration de la fédération (relation d’approbation configurée entre AD FS et Microsoft Entra ID) soit supervisée de près et que toute activité inhabituelle ou suspecte soit capturée. Pour ce faire, nous vous recommandons de configurer des alertes et de recevoir une notification chaque fois que des modifications sont apportées à la configuration de la fédération. Pour découvrir comment configurer des alertes, consultez Superviser les modifications apportées à la configuration de la fédération.

Autres configurations de sécurité

Les fonctionnalités supplémentaires suivantes peuvent être configurées pour renforcer la protection.

Protection par verrouillage « logiciel » extranet pour les comptes

Avec la fonctionnalité de verrouillage extranet dans Windows Server 2012 R2, un administrateur AD FS peut définir un nombre maximal autorisé de requêtes d’authentification ayant échoué (ExtranetLockoutThreshold) et une période observation window (ExtranetObservationWindow). Lorsque ce nombre maximal (ExtranetLockoutThreshold) de requêtes d’authentification est atteint, AD FS arrête d’essayer d’authentifier les informations d’identification de compte fournies auprès d’AD FS pendant la période définie (ExtranetObservationWindow). Cette action protège ce compte contre un verrouillage de compte AD, en d’autres termes, elle le protège contre la perte d’accès aux ressources d’entreprise qui s’appuient sur AD FS pour authentifier l’utilisateur. Ces paramètres s’appliquent à tous les domaines que le service AD FS peut authentifier.

Vous pouvez utiliser la commande Windows PowerShell suivante pour définir le verrouillage extranet AD FS (exemple) :

Set-AdfsProperties -EnableExtranetLockout $true -ExtranetLockoutThreshold 15 -ExtranetObservationWindow ( new-timespan -Minutes 30 )

À titre de référence, consultez Configuration du verrouillage extranet AD FS pour en savoir plus sur cette fonctionnalité.

Désactiver les points de terminaison Windows WS-Trust sur le proxy à partir de l’extranet

Les points de terminaison Windows WS-Trust (/adfs/services/trust/2005/windowstransport et /adfs/services/trust/13/windowstransport) sont destinés uniquement à être des points de terminaison intranet qui utilisent une liaison WIA sur HTTPS. Les exposer à un extranet peut permettre aux requêtes effectuées sur ces points de terminaison de contourner les protections par verrouillage. Ces points de terminaison doivent être désactivés sur le proxy (c’est-à-dire, désactivés à partir de l’extranet) à des fins de protection contre un verrouillage de compte AD à l’aide des commandes PowerShell suivantes. La désactivation de ces points de terminaison sur le proxy n’a aucun impact connu sur l’utilisateur final.

Set-AdfsEndpoint -TargetAddressPath /adfs/services/trust/2005/windowstransport -Proxy $false

Set-AdfsEndpoint -TargetAddressPath /adfs/services/trust/13/windowstransport -Proxy $false

Notes

Si votre batterie de serveurs AD FS s’exécute sur des bases de données internes Windows (WID) et dispose d’un serveur AD FS secondaire, après avoir désactivé les points de terminaison sur le serveur principal, attendez que la synchronisation se produise sur les nœuds secondaires avant de redémarrer le service AD FS sur ceux-ci. Utilisez la commande PowerShell Get-AdfsSyncProperties sur le nœud secondaire pour suivre le dernier processus de synchronisation.

Différencier les stratégies d’accès pour l’accès intranet et extranet

Les services AD FS ont la capacité de différencier les stratégies d’accès pour les requêtes qui proviennent du réseau local d’entreprise et celles qui proviennent d’Internet par le biais du proxy. Cette différenciation peut être effectuée par application ou globalement. Pour les applications à forte valeur métier ou les applications contenant des informations sensibles, envisagez d'exiger une authentification multifacteur. L'authentification multifacteur est configurable par le biais du composant logiciel enfichable de gestion AD FS.

Exiger l’authentification multifacteur (MFA)

Les services AD FS peuvent être configurés pour exiger une authentification forte (comme l'authentification multifacteur) particulièrement pour des requêtes qui entrent par le biais du proxy, pour des applications individuelles et pour un accès conditionnel aux ressources Microsoft Entra ID/Office 365 et locales. Les méthodes d’authentification multifacteur prises en charge incluent à la fois Microsoft Azure MF et des fournisseurs tiers. L’utilisateur est invité à fournir des informations supplémentaires (comme un code unique fourni dans un SMS) et AD FS fonctionne avec le plug-in propre au fournisseur pour autoriser l’accès.

Les fournisseurs MFA externes pris en charge incluent ceux listés dans la page Configurer des méthodes d’authentification supplémentaires pour AD FS.

Activer la protection pour empêcher le passage d'une authentification multifacteur Microsoft Entra cloud lorsqu'elle est fédérée avec Microsoft Entra ID

Activez une protection pour empêcher le contournement de l'authentification multifacteur Microsoft Entra ID cloud lorsqu'elle est fédérée avec Microsoft Entra ID et l'utilisation de l'authentification multifacteur Microsoft Entra comme authentification multifacteur pour vos utilisateurs fédérés.

L'activation de la protection de domaine fédéré dans votre client Microsoft Entra garantit que l'authentification multifacteur Microsoft Entra ID est toujours exécutée lorsqu'un utilisateur fédéré accède à une application régie par une stratégie d'accès conditionnel exigeant une authentification multifacteur. Cela inclut l'exécution de l'authentification multifacteur Microsoft Entra, même lorsque le fournisseur d'identité fédérée a indiqué (via des revendications de jeton fédéré) que l'authentification multifacteur locale a été effectuée. L'application de l'authentification multifacteur Microsoft Entra à chaque fois garantit qu'aucun compte local compromis ne peut la contourner en imitant une authentification multifacteur déjà effectuée par le fournisseur d'identité. Cette pratique est fortement recommandée, sauf si vous effectuez une authentification multifacteur pour vos utilisateurs fédérés à l'aide d'un fournisseur d'authentification multifacteur tiers.

La protection peut être activée à l’aide d’un nouveau paramètre de sécurité, federatedIdpMfaBehavior, exposé dans le cadre de l’API MS Graph de fédération interne ou des applets de commande PowerShell MS Graph. Le paramètre federatedIdpMfaBehavior détermine si Microsoft Entra ID accepte l'authentification multifacteur effectuée par le fournisseur d'identité fédérée lorsqu'un utilisateur fédéré accède à une application régie par une stratégie d'accès conditionnel qui exige une authentification multifacteur.

Les administrateurs peuvent choisir l’une des valeurs suivantes :

Propriété Description
acceptIfMfaDoneByFederatedIdp Microsoft Entra ID accepte l'authentification multifacteur effectuée par le fournisseur d'identité fédérée. Si ce n'est pas le cas, l'authentification multifacteur de Microsoft Entra est effectuée.
enforceMfaByFederatedIdp Microsoft Entra ID accepte l'authentification multifacteur effectuée par le fournisseur d'identité fédérée. Dans le cas contraire, une requête est redirigée vers le fournisseur d’identité pour que l’authentification multifacteur soit effectuée.
rejectMfaByFederatedIdp Microsoft Entra ID effectue toujours l'authentification multifacteur Microsoft Entra et rejette l'authentification multifacteur si elle est effectuée par le fournisseur d'identité.

Vous pouvez activer la protection en définissant federatedIdpMfaBehavior sur rejectMfaByFederatedIdp à l’aide de la commande suivante.

API MS GRAPH

 PATCH /domains/{domainsId}/federationConfiguration/{internalDomainFederationId} 

{ 

"federatedIdpMfaBehavior": "rejectMfaByFederatedIdp" 

}

Exemple :

PATCH /domains/contoso.com/federationConfiguration/2a8ce608-bb34-473f-9e0f-f373ee4cbc5a 

{ 

"federatedIdpMfaBehavior": "rejectMfaByFederatedIdp"

Exemple :

Update-MgDomainFederationConfiguration -DomainId <domainsId> -InternalDomainFederationId <internalDomainFederationId> federatedIdpMfaBehavior "rejectMfaByFederatedIdp"

Exemple :

Update-MgDomainFederationConfiguration -DomainId “contoso.com” -InternalDomainFederationId “2a8ce608-bb34-473f-9e0f-f373ee4cbc5a” federatedIdpMfaBehavior "rejectMfaByFederatedIdp"

Module de sécurité matériel (HSM)

Dans sa configuration par défaut, les clés utilisées par AD FS pour signer les jetons ne quittent jamais les serveurs de fédération sur l’intranet. Elles ne sont jamais présentes dans la zone démilitarisée ni sur les machines proxy. Pour éventuellement renforcer la protection, nous vous recommandons de protéger ces clés dans un module de sécurité matériel (HSM) attaché à AD FS. Microsoft ne produit pas de modules de sécurité matériels, mais il en existe plusieurs sur le marché qui prennent en charge AD FS. Pour implémenter cette recommandation, suivez les instructions du fournisseur pour créer les certificats X509 nécessaires à la signature et au chiffrement, puis utilisez les applets de commande PowerShell d’installation d’AD FS, en spécifiant vos certificats personnalisés comme suit :

Install-AdfsFarm -CertificateThumbprint <String> -DecryptionCertificateThumbprint <String> -FederationServiceName <String> -ServiceAccountCredential <PSCredential> -SigningCertificateThumbprint <String>

où :

  • CertificateThumbprint correspond à votre certificat SSL.
  • SigningCertificateThumbprint correspond à votre certificat de signature (avec une clé protégée par HSM).
  • DecryptionCertificateThumbprint correspond à votre certificat de chiffrement (avec une clé protégée par HSM).