Configuration AD FS requise
Voici la configuration requise pour le déploiement de Services ADFS :
Configuration requise des certificats
Certificats TLS/SSL
Chaque serveur AD FS et Proxy d’application web dispose d’un certificat TLS/SSL pour traiter les requêtes HTTPS destinées au service de fédération. Le proxy d’application web peut avoir des certificats supplémentaires pour traiter les requêtes destinées aux applications publiées.
Recommandations pour les certificats TLS/SSL
Utilisez le même certificat TLS/SSL pour tous les serveurs AD FS de fédération et proxys d’application web.
Exigences pour les certificats TLS/SSL
Les certificats TLS/SSL sur les serveurs de fédération doivent remplir les conditions suivantes :
- Le certificat est approuvé publiquement (pour les déploiements de production).
- Le certificat contient la valeur d’utilisation améliorée de la clé (EKU) d’authentification du serveur.
- Le certificat contient le nom du service de fédération, par exemple
fs.contoso.com
, dans l’objet ou l’autre nom de l’objet. - Pour l'authentification par certificat d'utilisateur sur le port 443, le certificat contient
certauth.\<federation service name\>
, tel quecertauth.fs.contoso.com
dans le SAN. - Pour l’inscription de l’appareil ou pour l’authentification moderne auprès de ressources locales à l’aide de clients antérieurs à Windows 10, l’autre nom de l’objet doit contenir
enterpriseregistration.\<upn suffix\>
pour chaque suffixe de Nom d’utilisateur principal (UPN) utilisé dans votre organisation.
Les certificats TLS/SSL sur le proxy d’application web doivent remplir les conditions suivantes :
- Si le proxy est utilisé pour les requêtes AD FS qui utilisent l’authentification Windows intégrée, le certificat TLS/SSL proxy doit être identique (il doit utiliser la même clé) au certificat TLS/SSL du serveur de fédération.
- Si la propriété AD FS, ExtendedProtectionTokenCheck, est activée (paramètre par défaut dans AD FS), le certificat TLS/SSL proxy doit être identique (il doit utiliser la même clé) au certificat TLS/SSL du serveur de fédération.
- Dans le cas contraire, les conditions requises pour le certificat TLS/SSL proxy sont les mêmes conditions que pour le certificat TLS/SSL du serveur de fédération.
Certificat de communication du service
Ce certificat n'est pas demandé dans la plupart des scénarios AD FS, notamment Microsoft Entra ID et Office 365. Par défaut, AD FS configure le certificat TLS/SSL fourni lors de la configuration initiale en tant que certificat de communication du service.
Recommandation pour le certificat de communication de service
- Utilisez le même certificat que celui utilisé pour TLS/SSL.
Certificat de signature de jetons
Ce certificat est utilisé pour signer les jetons délivrés aux parties de confiance. Par conséquent, les applications de partie de confiance doivent reconnaître le certificat et sa clé associée comme connus et approuvés. Quand le certificat de signature de jetons change, par exemple quand il expire et que vous configurez un nouveau certificat, toutes les parties de confiance doivent être mises à jour.
Recommandation pour le certificat de signature de jetons
Utilisez les certificats de signature de jetons auto-signés par défaut générés en interne par AD FS.
Exigences pour le Certificat de signature de jetons
- Si votre organisation demande d’utiliser les certificats de l’infrastructure à clé publique de l’entreprise (PKI) pour la signature des jetons, vous pouvez répondre à cette exigence avec le paramètre SigningCertificateThumbprint de l’applet de commande Install-AdfsFarm.
- Que vous utilisiez les certificats par défaut générés en interne ou les certificats inscrits en externe, quand le certificat de signature de jetons est changé, vous devez vous assurer que toutes les parties de confiance sont mises à jour avec les nouvelles informations de certificat. Sinon, ces parties de confiance ne peuvent pas se connecter.
Certificat de chiffrement/déchiffrement de jetons
Ce certificat est utilisé par les fournisseurs de revendications qui chiffrent les jetons délivrés à AD FS.
Recommandation relative au certificat de chiffrement/déchiffrement des jetons
Utilisez les certificats de déchiffrement de jetons auto-signés par défaut générés en interne par AD FS.
Exigences pour le Certificat de chiffrement/déchiffrement des jetons
- Si votre organisation demande d’utiliser les certificats de l’infrastructure à clé publique de l’entreprise pour la signature des jetons, vous pouvez répondre à cette exigence avec le paramètre DecryptingCertificateThumbprint de l’applet de commande Install-AdfsFarm.
- Que vous utilisiez les certificats par défaut générés en interne ou les certificats inscrits en externe, quand le certificat de déchiffrement de jetons est changé, vous devez vous assurer que tous les fournisseurs de revendications sont mis à jour avec les nouvelles informations de certificat. Dans le cas contraire, les connexions utilisant des fournisseurs de revendications non mis à jour échouent.
Attention
Les certificats utilisés pour la signature de jeton et pour le déchiffrement/chiffrement de jeton sont essentiels pour la stabilité du service de fédération. Les clients qui gèrent leurs propres certificats de chiffrement et déchiffrement de jeton et certificats de signature de jeton doivent s’assurer que ces certificats sont sauvegardés et disponibles indépendamment pendant un événement de récupération.
Certificats utilisateur
- Lorsque vous utilisez l’authentification par certificat utilisateur x509 avec AD FS, tous les certificats utilisateur doivent être chaînés à une autorité de certification racine que les serveurs Proxy d’application web et AD FS approuvent.
Configuration matérielle requise
La configuration matérielle (physique ou virtuelle) requise pour AD FS et le proxy d’application web est dictée par le processeur. Vous devez donc dimensionner votre batterie de serveurs en fonction de la capacité de traitement.
- Utilisez la feuille de calcul de planification de capacité AD FS 2016 pour déterminer le nombre de serveurs AD FS et Proxy d’application web dont vous avez besoin.
Les besoins en mémoire et en disques pour AD FS sont relativement statiques. Les conditions requises sont indiquées dans le tableau suivant :
Configuration matérielle requise | Configuration minimale requise | Configuration recommandée |
---|---|---|
Mémoire vive (RAM) | 2 Go | 4 Go |
Espace disque | 32 Go | 100 Go |
Configuration matérielle requise pour SQL Server
Si vous utilisez Azure SQL pour votre base de données de configuration AD FS, dimensionnez le serveur SQL Server en fonction des recommandations SQL Server de base. La base de données AD FS est petite et AD FS n’entraîne pas une charge de traitement importante sur l’instance de base de données. En revanche, AD FS se connecte à la base de données plusieurs fois pendant une authentification ; la connexion réseau doit donc être robuste. Malheureusement, SQL Azure n’est pas pris en charge pour la base de données de configuration AD FS.
Configuration requise du proxy
Pour l’accès extranet, vous devez déployer le service de rôle Proxy d’application web, qui fait partie du rôle serveur Accès à distance.
Les proxys tiers doivent prendre en charge le protocole MS-ADFSPIP pour être pris en charge en tant que proxy AD FS. Pour obtenir la liste des fournisseurs tiers, consultez les Questions fréquentes (FAQ) sur AD FS.
AD FS 2016 exige des serveurs proxy d’application web sur Windows Server 2016. Vous ne pouvez pas configurer un proxy de niveau inférieur pour une batterie de serveurs AD FS 2016 s’exécutant au niveau du comportement de batterie de serveurs 2016.
Un serveur de fédération et le service de rôle Proxy d’application Web ne peuvent pas être installés sur le même ordinateur.
Configuration requise par les services de domaine Active Directory
Configuration requise du contrôleur de domaine
AD FS exige des contrôleurs de domaine exécutant Windows Server 2008 ou ultérieur.
Au moins un contrôleur de domaine Windows Server 2016 est nécessaire pour Windows Hello Entreprise.
Notes
Toute prise en charge des environnements avec des contrôleurs de domaine Windows Server 2003 est terminée. Pour plus d’informations, consultez Informations sur le cycle de vie Microsoft.
Configuration requise pour le niveau fonctionnel du domaine
Tous les domaines de comptes d’utilisateur et le domaine auquel les serveurs AD FS sont joints doivent opérer au niveau fonctionnel du domaine Windows Server 2003 ou version ultérieure.
Un niveau fonctionnel du domaine Windows Server 2008 ou ultérieur est nécessaire pour l’authentification de certificat client si le certificat est mappé explicitement au compte d’un utilisateur dans AD DS.
Configuration requise pour le schéma
Les nouvelles installations d’AD FS 2016 nécessitent le schéma Active Directory 2016 (version minimale 85).
L’élévation du niveau de comportement de batterie de serveurs AD FS au niveau 2016 nécessite le schéma Active Directory 2016 (version minimale 85).
Configuration requise pour les comptes de service
N’importe quel compte de domaine standard peut être utilisé comme compte de service pour AD FS. Les comptes de service administrés de groupe sont également pris en charge. Les autorisations requises au moment de l’exécution sont rajoutées automatiquement quand vous configurez AD FS.
L’attribution des droits utilisateur requise pour le compte de service Active Directory est « Ouvrir une session en tant que service ».
Les attributions de droits utilisateur requises pour les
NT Service\adfssrv
et sontNT Service\drs
Générer des audits de sécurité et Se connecter en tant que service.Les comptes de service administrés de groupe nécessitent au moins un contrôleur de domaine exécutant Windows Server 2012 ou version ultérieure. Le compte de service géré de groupe gMSA doit résider sous le conteneur
CN=Managed Service Accounts
par défaut.Pour l’authentification Kerberos, le nom de principal du service «
HOST/<adfs\_service\_name>
» doit être inscrit sur le compte de service AD FS. Par défaut, AD FS configure cette exigence lors de la création d'une nouvelle batterie de serveurs AD FS. En cas d’échec de ce processus, comme dans le cas d’une collision ou d’autorisations insuffisantes, un avertissement s’affiche et vous devez l’ajouter manuellement.
Exigences relatives au domaine
Tous les serveurs AD FS doivent être joints à un domaine AD DS.
Tous les serveurs AD FS au sein d’une batterie de serveurs doivent être déployés dans le même domaine.
L’installation du premier nœud de la batterie de serveurs AD FS dépend si le contrôleur de domaine principal est disponible ou pas.
Exigences relatives aux forêts multiples
Le domaine auquel les serveurs AD FS sont joints doit approuver chaque domaine ou forêt qui contient des utilisateurs s’authentifiant auprès du service AD FS.
La forêt dont le compte de service AD FS est membre doit approuver toutes les forêts de connexion utilisateur.
Le compte de service AD FS doit avoir les autorisations nécessaires pour lire les attributs utilisateur dans chaque domaine qui contient des utilisateurs s’authentifiant auprès du service AD FS.
Conditions requises pour la base de données de configuration
Cette section décrit les conditions requises et les restrictions pour les batteries de serveurs AD FS qui utilisent respectivement la base de données interne Windows (WID, Windows Internal Database) ou SQL Server comme base de données :
WID
Le profil de résolution d’artefact de SAML 2.0 n’est pas pris en charge dans une batterie de serveurs WID.
La détection de relecture de jetons n’est pas prise en charge dans une batterie de serveurs WID. Cette fonctionnalité n’est utilisée que dans les scénarios où AD FS agit en tant que fournisseur de fédération et consomme des jetons de sécurité provenant de fournisseurs de revendications externes.
Le tableau suivant fournit un récapitulatif du nombre de serveurs AD FS pris en charge dans une batterie de serveurs WID ou SQL Server.
Approbations de partie de confiance 1-100 | Plus de 100 approbations de partie de confiance |
---|---|
Nœuds AD FS 1-30 : WID pris en charge | Nœuds AD FS 1-30 : Non pris en charge avec WID - SQL Server requis |
Plus de 30 nœuds AD FS : Non pris en charge avec WID - SQL Server requis | Plus de 30 nœuds AD FS : Non pris en charge avec WID - SQL Server requis |
SQL Server
Pour AD FS dans Windows Server 2016, SQL Server 2008 et versions ultérieures sont prises en charge.
La résolution d’artefacts SAML et la détection de relecture de jetons sont prises en charge dans une batterie SQL Server.
Configuration requise des navigateurs
Quand l’authentification AD FS est effectuée par le biais d’un navigateur ou d’un contrôle de navigateur, votre navigateur doit satisfaire aux exigences suivantes :
JavaScript doit être activé.
Pour l’authentification unique, le navigateur client doit être configuré pour autoriser les cookies.
L’indication du nom du serveur (SNI) doit être prise en charge.
Pour le certificat utilisateur et l’authentification par certificat d’appareil, le navigateur doit prendre en charge l’authentification par certificat client TLS/SSL.
Pour bénéficier d’une connexion fluide à l’aide de l’authentification intégrée de Windows, le nom du service de fédération (par exemple,
https:\/\/fs.contoso.com
) doit être configuré dans la zone Intranet locale ou dans la zone Sites de confiance.
Configuration requise pour le réseau
Configuration requise du pare-feu
Tant les pare-feux situés entre le proxy d’application web et la batterie de serveurs de fédération qu’entre les clients et le proxy d’application web doivent avoir le port TCP 443 activé pour le trafic entrant.
En outre, si vous avez besoin d’une authentification par certificat d’utilisateur client (authentification clientTLS à l’aide de certificats utilisateur X509) et que le port 443 sur le point de terminaison certauth n’est pas activé. AD FS 2016 nécessite l’activation du port TCP 49443 entrant sur le pare-feu entre les clients et le Proxy d'application Web. Cette exigence ne s’applique pas au pare-feu entre le Proxy d’application Web et les serveurs de fédération.
Pour plus d’informations sur les exigences relatives aux ports hybrides, consultez Ports et protocoles nécessaires à l’identité hybride.
Pour plus d’informations, consultez Meilleures pratiques pour la sécurisation des services de fédération Active Directory
Configuration requise du DNS
Pour l’accès intranet, tous les clients qui accèdent au service AD FS au sein du réseau d’entreprise interne (intranet) doivent être en mesure de résoudre le nom du service AD FS en équilibreur de charge pour les serveurs AD FS.
Pour l’accès extranet, tous les clients qui accèdent au service AD FS depuis l’extérieur du réseau d’entreprise (extranet/internet) doivent être en mesure de résoudre le nom du service AD FS en équilibreur de charge pour les serveurs proxy d’application web.
Chaque serveur Proxy d’application web de la zone démilitarisée (DMZ) doit être capable de résoudre le nom du service AD FS en équilibreur de charge pour le ou les serveurs AD FS. Vous pouvez créer cette configuration à l’aide d’un autre serveur DNS (Domain Name System) dans le réseau DMZ ou en modifiant la résolution du serveur local à l’aide du fichier HOSTS.
Pour l’authentification intégrée de Windows, vous devez utiliser un enregistrement DNS A (pas un enregistrement CNAME) pour le nom du service de fédération.
Pour l’authentification par certificat utilisateur sur le port 443, « certauth.<nom_service_fédération> » doit être configuré dans le système DNS pour correspondre au serveur de fédération ou au Proxy d’application web.
Pour l’inscription des appareils ou pour l’authentification moderne auprès de ressources locales utilisant des clients antérieurs à Windows 10,
enterpriseregistration.\<upn suffix\>
, vous devez configurer chaque suffixe UPN utilisé dans votre organisation pour qu’il corresponde au serveur de fédération ou au Proxy d’application web.
Exigences relatives à l’équilibreur de charge
- L’équilibreur de charge ne doit pas mettre fin au protocole TLS/SSL. AD FS prend en charge plusieurs cas d’usage avec authentification par certificat qui s’interrompt lors de l’arrêt du protocole TLS/SSL. L’arrêt du protocole TLS/SSL sur l’équilibreur de charge n’est pris en charge pour aucun cas d’usage.
- Utilisez un équilibreur de charge qui prend en charge SNI. Dans le cas contraire, l’utilisation de la liaison de secours 0.0.0.0 sur votre serveur Proxy d’application web ou AD FS doit fournir une solution de contournement.
- Utilisez les points de terminaison de sonde d’intégrité HTTP (et non HTTPS) afin d’effectuer des vérifications de l’intégrité de l’équilibreur de charge pour le routage du trafic. Cette exigence permet d'éviter tout problème lié à la SNI. La réponse à ces points de terminaison de sonde est HTTP 200 OK. Elle est traitée localement sans dépendance envers les services back-end. La sonde HTTP est accessible par le biais du protocole HTTP à l’aide du chemin « /adfs/probe ».
http://<Web Application Proxy name>/adfs/probe
http://<AD FS server name>/adfs/probe
http://<Web Application Proxy IP address>/adfs/probe
http://<AD FS IP address>/adfs/probe
- Il n’est pas recommandé d’utiliser le tourniquet (Round Robin) DNS pour équilibrer la charge. L’utilisation de ce type d’équilibrage de charge ne fournit pas de méthode automatisée pour supprimer un nœud de l’équilibreur de charge à l’aide de sondes d’intégrité.
- Il n’est pas recommandé d’utiliser l’affinité de session basée sur IP ou des sessions rémanentes pour le trafic d’authentification vers AD FS au sein de l’équilibreur de charge. Vous pourriez provoquer une surcharge de certains nœuds lors de l’utilisation du protocole d’authentification hérité pour que les clients d’e-mail se connectent aux services de messagerie Office 365 (Exchange Online).
Conditions requises pour les autorisations
L’administrateur qui effectue l’installation et la configuration initiale d’AD FS doit disposer d’autorisations d’administrateur local sur le serveur AD FS. Si l’administrateur local ne dispose pas des autorisations nécessaires pour créer des objets dans Active Directory, il doit d’abord demander à un administrateur de domaine de créer les objets AD nécessaires, puis configurer la batterie de serveurs AD FS à l’aide du paramètre AdminConfiguration.