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

Ce document présente les meilleures pratiques pour la planification et le déploiement sécurisés de services de fédération Active Directory (AD FS) (AD FS) et du proxy d’application Web. Il contient des informations sur les comportements par défaut de ces composants et des recommandations pour les configurations de sécurité supplémentaires pour une organisation avec des cas d’utilisation et des exigences de sécurité spécifiques.

ce document s’applique à AD FS et WAP dans Windows Server 2012 R2, 2016 et 2019. Ces recommandations peuvent être utilisées si l’infrastructure est déployée sur 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 vous recommandons une topologie de déploiement standard composée d’un ou de plusieurs serveurs AD FS sur le réseau d’entreprise interne, avec un ou plusieurs serveurs de proxy d’application Web (WAP) dans un réseau DMZ ou extranet. À 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 comme requis devant l’adresse IP externe de l’équilibreur de charge devant chaque batterie (FS et proxy).

Diagramme illustrant une topologie D F S standard.

Notes

AD FS nécessite un contrôleur de domaine entièrement accessible en écriture pour fonctionner au lieu d’un contrôleur de domaine Read-Only. Si une topologie planifiée comprend 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 la sécurité de vos serveurs AD FS

La liste suivante répertorie les meilleures pratiques et les recommandations relatives au renforcement et à la sécurisation de votre déploiement AD FS.

  • Assurez-vous que Active Directory administrateurs et les administrateurs de 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 de AD FS.
  • Exiger que tous les administrateurs du Cloud utilisent l’Multi-Factor Authentication (MFA).
  • Fonctionnalité d’administration minimale via les agents.
  • Limitez l’accès sur le réseau via le pare-feu hôte.
  • Assurez-vous AD FS administrateurs utilisent les stations de travail d’administration pour protéger leurs informations d’identification.
  • Placez AD FS objets ordinateur serveur dans une UO 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 de privilèges potentiels par le biais de la modification des objets de stratégie de groupe.
  • Assurez-vous 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 arrivé à expiration interrompt l’authentification de Fédération). En outre, nous vous recommandons de protéger les clés de signature/certificats 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 de AD FS ( & sécurité) à une Siem pour corréler avec l’authentification Active Directory, ainsi que AzureAD (ou similaire).
  • supprimer les protocoles inutiles & Windows les fonctionnalités
  • Utilisez un mot de > passe long (25 caractères) et un mot de passe complexe pour le compte de service AD FS. Nous vous recommandons d’utiliser un compte de service administré de groupe (gMSA) en tant que 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.
  • Mettez à jour vers la dernière version de AD FS pour les améliorations de la sécurité et de la journalisation (comme toujours, testez tout d’abord).

Ports requis

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

notez que le port 49443 est uniquement requis 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 de F S.

Notes

le port 808 (Windows Server 2012 r2) ou le port 1501 (Windows Server 2016 +) est le port Net. TCP que AD FS utilise pour le point de terminaison WCF local pour transférer des données de configuration vers le processus de service et PowerShell. Ce port peut être consulté 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 d’une batterie de AD FS communiquent avec d’autres serveurs de la batterie de serveurs et les serveurs proxy d’application Web (WAP) via le port HTTP 80 pour la synchronisation de la configuration. S’assurer que seuls ces serveurs peuvent communiquer entre eux et qu’aucun autre n’est une mesure de défense en profondeur.

Pour ce faire, les organisations peuvent configurer des règles de pare-feu sur chaque serveur autorisant les communications entrantes à partir des adresses IP à partir d’autres serveurs de la batterie et des serveurs WAP. Notez que certains équilibreurs de charge réseau (NLB) utilisent le port HTTP 80 pour la détection de l’intégrité sur des serveurs de Fédération individuels. Veillez à inclure les adresses IP de l’équilibrage de la charge réseau dans les règles de pare-feu configurées.

Azure AD Connecter et serveurs 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

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

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 requis et les protocoles requis pour les déploiements hybrides, consultez le document ici.

pour plus d’informations sur les ports et les protocoles requis pour un déploiement de Azure AD et d’Office 365, consultez le document ici.

Points de terminaison activés

Lorsque AD FS et WAP sont installés, un ensemble de points de terminaison de AD FS par défaut sont activés 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 utilisés et utilisés, et il n’est pas nécessaire de les modifier.

Facultatif ensemble minimal de points de terminaison activés pour Azure AD/Office 365

les organisations qui déploient AD FS et WAP uniquement pour les scénarios de Azure AD et de Office 365 peuvent limiter encore davantage le nombre de points de terminaison de AD FS activés sur le proxy pour atteindre une surface d’attaque plus minimale. Voici la liste des points de terminaison qui doivent être activés sur le proxy dans les scénarios suivants :

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 les Exchange Online avec des clients Office antérieurs à Office 2013 2015 mai update. Les clients ultérieurs utilisent le point de terminaison \adfs\ls passif.
/adfs/services/trust/13/usernamemixed utilisé pour les Exchange Online avec des clients Office antérieurs à Office 2013 2015 mai update. Les clients ultérieurs utilisent le point de terminaison \adfs\ls passif.
/adfs/oauth2 Celui-ci est utilisé pour toutes les applications modernes (local ou dans le Cloud) que vous avez configurées pour s’authentifier directement sur AD FS (par exemple, AAD)
/adfs/services/trust/mex utilisé pour les Exchange Online avec des clients Office antérieurs à Office 2013 2015 mai update. Les clients ultérieurs utilisent le point de terminaison \adfs\ls passif.
/ADFS/LS/FederationMetadata/2007-06/federationmetadata.xml Exigence pour les flux passifs ; et utilisés par Office 365/Azure AD pour vérifier AD FS certificats.

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

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

Par exemple :

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 (intercepteur) et qui est activée par défaut avec AD FS.

Pour vérifier les paramètres, vous pouvez effectuer les opérations suivantes :

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 de sécurité puissent être atteints sans les 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 du service de Fédération (qui fait partie du WAP) fournit un contrôle de congestion pour protéger le service de AD FS des flux 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’adresse%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 le service AD FS en exécutant net stop adfssrv , puis net start adfssrv . Pour référence, vous trouverez des conseils sur cette fonctionnalité ici.

Vérifications des demandes HTTP standard au niveau du proxy

Le proxy effectue également les vérifications standard suivantes par rapport à l’ensemble du trafic :

  • Le FS-P lui-même s’authentifie auprès de AD FS via un certificat éphémère. Dans un scénario de compromission présumée des serveurs DMZ, AD FS pouvez révoquer l’approbation de proxy afin qu’il n’approuve plus les demandes entrantes provenant de proxys potentiellement compromis. La révocation de l’approbation de proxy révoque le propre certificat de chaque proxy afin qu’il ne puisse pas s’authentifier correctement à l’usage du serveur de AD FS
  • FS-P met fin à 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 périphériques externes et le service AD FS. L’appareil externe ne se connecte jamais directement au service AD FS.
  • 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.

Assurez-vous 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 de AD FS consiste à vous assurer que vous disposez d’un moyen de conserver vos serveurs AD FS et WAP à jour avec toutes les mises à jour de sécurité, ainsi que de ces mises à jour facultatives spécifiées comme importantes pour AD FS sur cette page.

la méthode recommandée pour Azure AD aux clients de surveiller et de maintenir leur infrastructure à jour consiste à utiliser Azure AD Connecter Health pour AD FS, une fonctionnalité de Azure AD Premium. Azure AD l’intégrité des Connecter comprend des analyses et des alertes qui déclenchent l’absence d’une des mises à jour importantes pour AD FS et wap dans un AD FS ou un ordinateur wap.

vous trouverez des informations sur l’installation de Azure AD Connecter Health pour AD FS ici.

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 Superviser les modifications apportées à la configuration de la fédération.

Configurations de sécurité supplémentaires

Les fonctionnalités supplémentaires suivantes peuvent éventuellement être configurées pour fournir des protections supplémentaires à celles proposées dans le déploiement par défaut.

Protection du 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 de temps (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 par rapport AD FS pour la période définie (ExtranetObservationWindow). Cette action protège ce compte du verrouillage d’un compte Active Directory, en d’autres termes, il empêche ce compte de perdre l’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 de l’extranet AD FS (exemple) :

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

Pour référence, la documentation publique de cette fonctionnalité est disponible ici.

désactiver les points de terminaison de Windows WS-Trust sur le proxy, c’est-à-dire à partir de l’extranet

WS-Trust points de terminaison de Windows (/adfs/services/trust/2005/windowstransport et /adfs/services/trust/13/windowstransport) sont uniquement destinés à être des points de terminaison intranet qui utilisent la liaison WIA sur https. Les exposer à l’extranet pourraient permettre à 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 de l’extranet) pour protéger le verrouillage de compte Active Directory à l’aide des commandes PowerShell suivantes. Il n’y a aucun impact d’utilisateur final connu en désactivant ces points de terminaison sur le proxy.

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 AD FS s’exécute sur Windows bases de données internes (WID) et a un serveur de AD FS secondaire, après la désactivation des 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. Utilisez la commande PowerShell 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

AD FS a la possibilité de différencier les stratégies d’accès pour les requêtes qui proviennent des demandes de réseau local, d’entreprise par rapport à partir d’Internet via le proxy. Cela peut être effectué par application ou globalement. Pour les applications à valeur métier ou les applications avec des informations sensibles ou personnellement identifiables, envisagez d’exiger une authentification multifacteur. Pour ce faire, vous pouvez utiliser le composant logiciel enfichable Gestion des 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 des applications individuelles et pour l’accès conditionnel aux ressources Azure AD/Office 365 et locales. les méthodes d’authentification mfa prises en charge incluent à la fois Microsoft Azure mfa et des fournisseurs tiers. L’utilisateur est invité à fournir des informations supplémentaires (par exemple, un texte SMS contenant un code unique) et AD FS utilise le plug-in spécifique au fournisseur pour autoriser l’accès.

Les fournisseurs MFA externes pris en charge incluent ceux qui sont listés dans cette page, ainsi que HDI global.

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

Dans sa configuration par défaut, les clés AD FS utilisées pour signer les jetons ne laissent jamais les serveurs de Fédération sur l’intranet. Ils ne sont jamais présents dans la zone DMZ ou sur les ordinateurs proxy. Si vous souhaitez fournir une protection supplémentaire, 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 produit HSM, mais plusieurs sur le marché prennent en charge AD FS. Pour mettre en œuvre cette recommandation, suivez les instructions du fournisseur pour créer les certificats X509 pour la signature et le chiffrement, puis utilisez le AD FS d’installation PowerShell applets, 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 une clé protégée par HSM)
  • DecryptionCertificateThumbprint est votre certificat de chiffrement (avec une clé protégée par HSM)