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

Ce document fournit les meilleures pratiques pour la planification et le déploiement sécurisés d’Services ADFS (AD FS) et de Proxy d'application Web (WAP). Il contient des recommandations pour des configurations de sécurité supplémentaires, des cas d’usage spécifiques et des exigences de sécurité.

Ce document s’applique à AD FS et WAP dans Windows Server 2012 R2, 2016 et 2019. Ces recommandations peuvent être utilisées pour un réseau local ou dans un environnement hébergé dans le cloud tel que Microsoft Azure.

Topologie de déploiement standard

Pour le déploiement dans des environnements locaux, nous recommandons 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 web Proxy d'application (WAP) dans une zone DMZ ou un réseau extranet.

Au niveau de chaque couche, AD FS et WAP, un équilibreur de charge matériel ou logiciel est placé devant la batterie de serveurs et gère le routage du trafic. Les pare-feu sont placés devant l’adresse IP externe de l’équilibreur de charge en fonction des besoins.

Diagramme illustrant une topologie AD F S standard.

Notes

AD FS nécessite un contrôleur de domaine accessible en écriture complète pour fonctionner par opposition à un contrôleur de domaine Read-Only. Si une topologie planifiée inclut un contrôleur de domaine Read-Only, le contrôleur de domaine Read-Only 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 une liste de bonnes pratiques et de 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 locaux sur tous les serveurs AD FS.
  • Exiger que tous les administrateurs cloud utilisent l’authentification multifacteur (MFA).
  • Fonctionnalité d’administration minimale via des agents.
  • Limitez l’accès au réseau via le pare-feu hôte.
  • Vérifiez que les administrateurs AD FS utilisent Administration stations de travail pour protéger leurs informations d’identification.
  • Placez les objets d’ordinateur serveur AD FS dans une unité d’organisation de niveau supérieur qui n’héberge pas également d’autres serveurs.
  • Tous les objets de stratégie de groupe qui s’appliquent aux serveurs AD FS ne doivent s’appliquer qu’à eux, et non à d’autres serveurs. Cela limite l’escalade potentielle des privilèges via la modification de l’objet de stratégie de groupe.
  • Vérifiez que les certificats installés sont protégés contre le vol (ne les stockez pas sur un partage sur le réseau) et définissez un rappel de calendrier pour vous assurer qu’ils sont renouvelés avant l’expiration (le certificat 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 (& sécurité) à un SIEM pour mettre en corrélation l’authentification AD ainsi qu’AzureAD (ou similaire).
  • Supprimer les protocoles & inutiles fonctionnalités Windows.
  • Utilisez un mot de passe long (>25 caractères) complexe pour le compte de service AD FS. Nous vous recommandons d’utiliser un compte de service managé de groupe (gMSA) comme compte de service, car il supprime la nécessité de gérer le mot de passe du compte de service au fil du temps en le gérant 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 d’abord).

Ports requis

Le diagramme ci-dessous illustre les ports de pare-feu qui doivent être activés entre et parmi les composants du déploiement AD FS et WAP. Si le déploiement n’inclut pas Azure AD/Office 365, les exigences de synchronisation peuvent être ignorées.

Notes

Le port 49443 n’est requis que si l’authentification par certificat utilisateur est utilisée, ce qui est facultatif pour Azure AD et Office 365.

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

Notes

Le port 808 (Windows Server 2012R2) ou le port 1501 (Windows Server 2016+) est le Réseau. Le port TCP 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 | sélectionnez NetTcpPort. Il s’agit d’un port local qui n’a pas besoin d’être ouvert dans le pare-feu, mais qui sera affiché 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 de serveurs et les serveurs de Proxy d'application Web (WAP) via le port HTTP 80 pour la synchronisation de la configuration. Assurez-vous 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 de serveurs et des serveurs WAP. 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’équilibrage de charge réseau dans les règles de pare-feu configurées.

Serveurs Azure AD Connect et de fédération/WAP

Ce tableau décrit les ports et les protocoles nécessaires à la communication entre le serveur Azure AD Connect et les serveurs de fédération/WAP.

Protocol 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 établir une synchronisation avec Azure AD.
WinRM 5985 Écouteur WinRM.

Serveurs WAP et 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.

WAP 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 requis pour les déploiements hybrides, consultez Ports de connexion de référence hybride.

Pour plus d’informations sur les ports et les protocoles requis pour un déploiement Azure AD et Office 365, consultez le document Office 365 plages d’adresses IP et d’URL.

Points de terminaison activés

Quand AD FS et WAP 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 valeurs par défaut ont été choisies en fonction des scénarios les plus couramment requis et utilisés, et il n’est pas nécessaire de les modifier.

Jeu minimal de proxy de points de terminaison activé pour Azure AD / Office 365 (facultatif)

Les organisations déployant AD FS et WAP uniquement pour azure AD et Office 365 scénarios peuvent limiter encore davantage le nombre de points de terminaison AD FS activés sur le proxy pour obtenir une surface d’attaque plus minimale. Voici la liste des points de terminaison qui doivent être activés 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 Azure AD et 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 passif \adfs\ls.
/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 passif \adfs\ls.
/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 (c’est-à-dire pas via Azure AD)
/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 passif \adfs\ls.
/federationmetadata/2007-06/federationmetadata.xml Exigence pour tous les flux passifs ; et utilisés par Office 365/Azure AD 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 pour l’authentification est une fonctionnalité qui atténue les attaques d’homme au milieu (MITM) et 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 la fonctionnalité.

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

Le proxy de service de fédération (qui fait partie du WAP) fournit un contrôle de congestion pour protéger le service AD FS contre un flot de requêtes. Le Proxy d'application Web rejette les demandes d’authentification du client externe si le serveur de fédération est surchargé comme détecté 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, à l’emplacement %WINDIR%\adfs\config.
  3. Remplacez les paramètres de contrôle de congestion de ses valeurs par défaut par <congestionControl latencyThresholdInMSec="8000" minCongestionWindowSize="64" enabled="true" />.
  4. Enregistrez et fermez le fichier.
  5. Redémarrez le service AD FS en exécutant net stop adfssrv , puis net start adfssrv.

Pour obtenir des conseils sur cette fonctionnalité, consultez Configurer l’accès extranet pour 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 auprès d’AD FS via un certificat de courte durée. Dans un scénario de suspicion de compromission de serveurs dmz, AD FS peut « révoquer l’approbation de proxy » afin qu’il n’approuve plus les requêtes entrantes provenant de proxys potentiellement compromis. La révocation de l’approbation de proxy révoque le certificat de chaque proxy afin qu’il ne puisse pas s’authentifier correctement auprès du serveur AD FS.
  • FS-P arrête toutes les connexions et crée une nouvelle connexion HTTP au service AD FS sur le réseau interne. Cela fournit une mémoire tampon 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 une validation de requête HTTP qui filtre spécifiquement les en-têtes HTTP qui ne sont pas requis par le service AD FS.

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

La méthode recommandée pour les clients Azure AD pour surveiller et maintenir à jour leur infrastructure consiste à utiliser Azure AD Connect Health pour AD FS, une fonctionnalité d’Azure AD Premium. Azure AD Connect Health inclut des moniteurs et des alertes qui se déclenchent si une machine AD FS ou WAP manque une des mises à jour importantes spécifiquement pour AD FS et WAP.

Pour en savoir plus sur la surveillance de l’intégrité pour AD FS, consultez Installation de l’agent Azure AD Connect Health.

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

Lorsque vous fédérez votre AD FS avec Azure AD, il est essentiel que la configuration de la fédération (relation d’approbation configurée entre AD FS et Azure AD) 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 savoir comment configurer des alertes, consultez Surveiller les modifications apportées à la configuration de la fédération.

Configurations de sécurité supplémentaires

Les fonctionnalités supplémentaires suivantes peuvent être configurées pour fournir une protection supplémentaire.

Protection de verrouillage « soft » 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 demandes d’authentification ayant échoué (ExtranetLockoutThreshold) et une observation window période (ExtranetObservationWindow). Lorsque ce nombre maximal (ExtranetLockoutThreshold) de demandes d’authentification est atteint, AD FS cesse 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 l’authentification de 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 )

Pour plus d’informations sur cette fonctionnalité, consultez Configuration du verrouillage extranet AD FS .

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

WS-Trust points de terminaison Windows (/adfs/services/trust/2005/windowstransport et /adfs/services/trust/13/windowstransport) sont destinés uniquement à être des points de terminaison intranet qui utilisent la liaison WIA sur HTTPS. Les exposer à un extranet peut permettre aux demandes effectuées sur ces points de terminaison de contourner les protections de verrouillage. Ces points de terminaison doivent être désactivés sur le proxy (c’est-à-dire désactivés à partir de l’extranet) pour protéger le 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 SYNC.

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

AD FS a la possibilité de différencier les stratégies d’accès pour les demandes qui proviennent du réseau local d’entreprise par rapport aux demandes provenant d’Internet via le proxy. Cette différenciation peut être effectuée par application ou globalement. Pour les applications à forte valeur métier ou les applications avec des informations sensibles, envisagez d’exiger une authentification multifacteur. L’authentification multifacteur peut être configurée via le composant logiciel enfichable de gestion AD FS.

Exiger l’authentification multifacteur (MFA)

AD FS peut être configuré pour exiger une authentification forte (telle que l’authentification multifacteur) spécifiquement pour les demandes entrantes via le proxy, pour les applications individuelles et pour l’accès conditionnel à Azure AD/Office 365 et aux ressources locales. Les méthodes d’authentification multifacteur prises en charge incluent à la fois Microsoft Azure MF et les fournisseurs tiers. L’utilisateur est invité à fournir les informations supplémentaires (telles qu’un sms contenant un code unique), et AD FS travaille avec le plug-in spécifique au fournisseur pour autoriser l’accès.

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

Activer la protection pour éviter le by-passing d’Azure AD Multi-Factor Authentication cloud lorsqu’il est fédéré avec Azure AD

Activez la protection pour empêcher le contournement de l’authentification multifacteur Azure AD cloud lorsqu’elle est fédérée avec Azure AD et utilisez Azure AD Multi-Factor Authentication comme authentification multifacteur pour vos utilisateurs fédérés.

L’activation de la protection d’un domaine fédéré dans votre locataire Azure AD garantit qu’Azure AD Multi-Factor Authentication est toujours effectué lorsqu’un utilisateur fédéré accède à une application régie par une stratégie d’accès conditionnel nécessitant l’authentification multifacteur. Cela inclut l’exécution d’Azure AD Multi-Factor Authentication 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 d’Azure AD Multi-Factor Authentication à chaque fois garantit qu’un compte local compromis ne peut pas contourner Azure AD Multi-Factor Authentication en imitant qu’une authentification multifacteur a déjà été effectuée par le fournisseur d’identité, et est fortement recommandé, sauf si vous effectuez l’authentification multifacteur pour vos utilisateurs fédérés à l’aide d’un fournisseur MFA tiers.

La protection peut être activée à l’aide d’un nouveau paramètre de sécurité, federatedIdpMfaBehavior, qui est exposé dans le cadre des applets de commande MS API Graph de fédération interne ou MS Graph PowerShell. Le federatedIdpMfaBehavior paramètre détermine si Azure AD 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 nécessite l’authentification multifacteur.

Les administrateurs peuvent choisir l’une des valeurs suivantes :

Propriété Description
acceptIfMfaDoneByFederatedIdp Azure AD accepte l’authentification multifacteur si elle est effectuée par le fournisseur d’identité. Si ce n’est pas le cas, effectue l’authentification multifacteur Azure AD.
enforceMfaByFederatedIdp Azure AD accepte l’authentification multifacteur si elle est effectuée par le fournisseur d’identité. Si ce n’est pas le cas, il redirige la demande vers le fournisseur d’identité pour effectuer l’authentification multifacteur.
rejectMfaByFederatedIdp Azure AD effectue toujours l’authentification multifacteur Azure AD et rejette l’authentification multifacteur si elle est effectuée par le fournisseur d’identité.

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

MS GRAPH API

 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. Ils ne sont jamais présents dans la zone DMZ ou sur les machines proxy. Si vous le souhaitez, pour plus de protection, nous vous recommandons de protéger ces clés dans un module de sécurité matérielle (HSM) attaché à AD FS. Microsoft ne produit pas de produit HSM, 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 pour la signature et le chiffrement, puis utilisez les commandes 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 est votre certificat SSL
  • SigningCertificateThumbprint est votre certificat de signature (avec clé protégée HSM)
  • DecryptionCertificateThumbprint est votre certificat de chiffrement (avec une clé protégée HSM)