Questions fréquentes (FAQ) sur AD FS

Vous pouvez mettre à niveau/migrer AD FS en effectuant les étapes décrites dans un des articles liés suivants :

• Windows Server 2012 R2 AD FS vers Windows Server 2016 AD FS ou ultérieur. (Le processus est le même si vous effectuez une mise à niveau de Windows Server 2016 AD FS vers Windows Server 2019 AD FS.)
  • Mise à niveau vers AD FS dans Windows Server 2016 en utilisant une base de données WID
  • Mise à niveau vers AD FS dans Windows Server 2016 en utilisant une base de données SQL
• Windows Server 2012 AD FS vers Windows Server 2012 R2 AD FS :
  • Migrer vers AD FS sur Windows Server 2012 R2
• AD FS 2.0 vers Windows Server 2012 AD FS :
  • Migrer vers AD FS sur Windows Server 2012
• AD FS 1.x vers AD FS 2.0 :
  • Mettre à niveau AD FS 1.x vers AD FS 2.0

Si vous devez effectuer une mise à niveau à partir d’AD FS 2.0 ou 2.1 (Windows Server 2008 R2 ou Windows Server 2012), utilisez les scripts intégrés qui se trouvent dans C:\Windows\ADFS.

La prise en charge de HTTP/2 a été ajoutée dans Windows Server 2016, mais HTTP/2 ne peut pas être utilisé pour l’authentification par certificat client. De nombreux scénarios AD FS utilisent l’authentification par certificat client. De nombreux clients ne prennent pas en charge les nouvelles tentatives de requêtes avec HTTP/1.1. La configuration de la batterie de serveurs AD FS reconfigure donc les paramètres HTTP du serveur local en HTTP/1.1. Cette reconfiguration nécessite un redémarrage du serveur.

Cette configuration est prise en charge, mais aucune nouvelle fonctionnalité d’AD FS 2016 n’y sera prise en charge. Cette configuration est censée être temporaire pendant la phase de migration d’AD FS 2012 R2 vers AD FS 2016. Elle ne doit pas être utilisée sur de longues périodes de temps.

Oui, mais il y a un effet secondaire :

• Vous allez devoir gérer manuellement la mise à jour des certificats de signature de jetons, car Azure AD ne pourra pas accéder aux métadonnées de fédération. Pour plus d’informations sur la mise à jour manuelle des certificats de signature de jetons, consultez Renouveler des certificats de fédération pour Office 365 et Azure Active Directory.
• Vous ne pouvez pas utiliser les flux d’authentification hérités (par exemple le flux d’authentification de proxy ExO).

AD FS est un système sans état : l’équilibrage de charge est donc relativement simple pour les connexions. Voici quelques recommandations importantes pour les systèmes d’équilibrage de charge :

• Les équilibreurs de charge ne doivent pas être configurés avec l’affinité IP. L’affinité IP peut imposer une charge excessive sur un sous-ensemble de vos serveurs dans certains scénarios Exchange Online.
• Les équilibreurs de charge ne doivent pas mettre fin aux connexions HTTPS et lancer une nouvelle connexion au serveur AD FS.
• Les équilibreurs de charge doivent vérifier que l’adresse IP de connexion soit traduite en tant qu’adresse IP source dans le paquet HTTP lors de son envoi à AD FS. Si un équilibreur de charge ne peut pas envoyer l’adresse IP source dans le paquet HTTP, il doit ajouter l’adresse IP à l’en-tête X-Forwarded-For. Cette étape est nécessaire pour la gestion correcte de certaines fonctionnalités IP (comme que les adresse IP bannies et le verrouillage intelligent d’extranet). Si cette configuration n’est pas correctement implémentée, la sécurité peut s’en trouver diminuée.
• Les équilibreurs de charge doivent prendre en charge SNI. Si ce n’est pas le cas, vérifiez qu’AD FS est configuré pour créer des liaisons HTTPS afin de gérer les clients qui ne prennent pas en charge SNI.
• Les équilibrages de charge doivent utiliser le point de terminaison de sonde d’intégrité HTTP d’AD FS pour détecter si les serveurs AD FS ou les serveurs Proxy d’application web sont en cours d’exécution. Il doit les exclure si « 200 OK » n’est pas retourné.

AD FS prend en charge plusieurs configurations multiforêts. Il s’appuie sur le réseau de confiance AD DS sous-jacent pour authentifier les utilisateurs sur plusieurs domaines approuvés. Nous recommandons fortement des approbations de forêt bidirectionnelles, car elles sont plus faciles à configurer, ce qui permet de garantir le bon fonctionnement du système d’approbation.

De plus :

• Si vous avez une approbation de forêt unidirectionnelle, comme une forêt de réseau de périmètre (également appelée DMZ) qui contient des identités de partenaires, nous vous recommandons de déployer AD FS dans la forêt d’entreprise. Traitez la forêt du réseau de périmètre comme une autre approbation de fournisseur de revendications locale connectée via LDAP. Dans ce cas, l’authentification Windows intégrée ne fonctionnera pas pour les utilisateurs de la forêt du réseau de périmètre. Ils devront utiliser l’authentification par mot de passe, car il s’agit du seul mécanisme pris en charge pour LDAP.

  Si vous ne pouvez pas utiliser cette option, vous devez configurer un autre serveur AD FS dans la forêt du réseau de périmètre. Ajoutez-le en tant qu’approbation de fournisseur de revendications dans le serveur AD FS de la forêt d’entreprise. Les utilisateurs devront effectuer une découverte de domaine d’accueil, mais l’authentification Windows intégrée et l’authentification par mot de passe vont fonctionner. Apportez les modifications appropriées aux règles d’émission d’AD FS dans la forêt du réseau de périmètre, car AD FS dans la forêt d’entreprise ne sera pas en mesure d’obtenir plus d’informations sur les utilisateurs auprès de la forêt du réseau de périmètre.

• Les approbations au niveau du domaine sont prises en charge et peuvent fonctionner. Cependant, nous vous recommandons fortement de passer à un modèle d’approbation au niveau de la forêt. Vous devez aussi vérifier que le routage UPN et la résolution de noms NetBIOS fonctionnent correctement.

Oui, les adresses IPv6 sont prises en compte pour les emplacements connus et inconnus.

AD FS fournit un mécanisme extensible pour l’intégration des fournisseurs d’authentification multifacteur tiers. Il n’existe pas de programme de certification défini pour cela. Il est supposé que le fournisseur a effectué les validations nécessaires avant la publication.

La liste des fournisseurs qui ont notifié Microsoft est disponible ici : Fournisseurs d’authentification multifacteur pour AD FS. Il peut y avoir des fournisseurs disponibles qui ne sont pas connus. Nous mettrons à jour la liste au fur et à mesure de la découverte de nouveaux fournisseurs.

Oui, des proxys tiers peuvent être placés devant AD FS. Toutefois, tout proxy tiers doit prendre en charge le protocole MS-ADFSPIP qui doit être utilisé à la place du proxy d’application web.

Nous connaissons actuellement les fournisseurs tiers suivants. Il peut y avoir des fournisseurs disponibles qui ne sont pas connus. Nous mettrons à jour cette liste au fur et à mesure de la découverte de nouveaux fournisseurs.

• Gestionnaire de stratégie d’accès F5
• Citrix Application Delivery Controller (ADC)

Vous pouvez télécharger la version AD FS 2016 de la feuille de calcul. Vous pouvez aussi utiliser cette feuille de calcul pour AD FS dans Windows Server 2012 R2.

Apple a publié un ensemble de spécifications appelées App Transport Security (ATS), qui peuvent affecter les appels des applications iOS qui s’authentifient auprès d’AD FS. Vous pouvez garantir que vos serveurs AD FS et Proxy d’application web sont conformes en faisant en sorte qu’ils prennent en charge les spécifications pour la connexion avec ATS. En particulier, vous devez vérifier que :

• Vos serveurs AD FS et Proxy d’application web prennent en charge TLS 1.2.
• La suite de chiffrement négocié de la connexion TLS va prendre en charge PFS (Perfect Forward Secrecy).

Pour plus d’informations sur l’activation et la désactivation de SSL 2.0 et 3.0, et de TLS 1.0, 1.1 et 1.2, consultez Gérer les protocoles SSL dans AD FS.

Pour garantir que vos serveurs AD FS et Proxy d’application web négocient seulement les suites de chiffrement TLS qui prennent en charge ATP, vous pouvez désactiver toutes les suites de chiffrement qui ne figurent pas dans la liste des suites de chiffrement compatibles avec ATP. Pour les désactiver, utilisez les applets de commande PowerShell TLS Windows.

La valeur de la revendication « sub » est le hachage de la valeur de l’ID client et de la revendication d’ancrage.

La durée de vie du jeton d’actualisation correspond à la durée de vie du jeton qu’AD FS a obtenu auprès de l’approbation du fournisseur de revendications distante. La durée de vie du jeton d’accès correspond à la durée de vie du jeton de la partie de confiance pour laquelle le jeton d’accès est émis.

Vous pouvez utiliser un id_token personnalisé pour ajouter des informations pertinentes dans l’id_token lui-même. Pour plus d’informations, consultez Personnaliser les revendications à émettre dans id_token.

Un ValueType spécial (http://www.w3.org/2001/XMLSchema#json) et un caractère d’échappement (\x22) ont été ajoutés pour ce scénario dans AD FS 2016. Utilisez les exemples suivants pour la règle d’émission et la sortie finale du jeton d’accès.

Exemple de règle d’émission :

=> issue(Type = "array_in_json", ValueType = "http://www.w3.org/2001/XMLSchema#json", Value = "{\x22Items\x22:[{\x22Name\x22:\x22Apple\x22,\x22Price\x22:12.3},{\x22Name\x22:\x22Grape\x22,\x22Price\x22:3.21}],\x22Date\x22:\x2221/11/2010\x22}");

Revendication émise dans le jeton d’accès :

"array_in_json":{"Items":[{"Name":"Apple","Price":12.3},{"Name":"Grape","Price":3.21}],"Date":"21/11/2010"}

Avec AD FS sur Windows Server 2019, vous pouvez désormais passer la valeur de la ressource incorporée dans le paramètre d’étendue. Le paramètre d’étendue peut être organisé sous forme de liste séparée par des espaces, où chaque entrée est structurée en tant que ressource/étendue.

AD FS dans Windows Server 2019 prend en charge PKCE (Proof Key for Code Exchange) pour le flux d’octroi de codes d’autorisation OAuth.

Prises en charge :

• aza. Si vous utilisez les extensions du protocole OAuth 2.0 pour les clients du Service Broker et que le paramètre d’étendue contient l’étendue « aza », le serveur émet un nouveau jeton d’actualisation principal et le définit dans le champ refresh_token de la réponse. Il définit également le champ refresh_token_expires_in sur la durée de vie du nouveau jeton d’actualisation principal, si un tel jeton est imposé.
• openid. Autorise l’application à demander l’utilisation du protocole d’autorisation OpenID Connect.
• logon_cert. Autorise une application à demander des certificats d’ouverture de session, qui peuvent être utilisés par des utilisateurs authentifiés pour se connecter de façon interactive. Le serveur AD FS omet le paramètre access_token de la réponse, et fournit à la place une chaîne de certificats CMS encodée en base64 ou une réponse PKI complète CMC. Pour plus d’informations, consultez Détails du traitement.
• user_impersonation. Obligatoire si vous voulez demander un jeton d’accès OBO (On-Behalf-Of) auprès d’AD FS. Pour plus d’informations sur l’utilisation de cette étendue, consultez Créer une application multiniveau en utilisant OBO (On-Behalf-Of) avec OAuth et AD FS 2016.

Non pris en charge :

• vpn_cert. Permet à une application de demander des certificats VPN, qui peuvent être utilisés pour établir des connexions VPN en utilisant l’authentification EAP-TLS. Cette étendue n’est plus prise en charge.
• email. Permet à une application de demander une revendication d’e-mail pour l’utilisateur connecté. Cette étendue n’est plus prise en charge.
• profile. Permet à une application de demander des revendications relatives au profil pour l’utilisateur connecté. Cette étendue n’est plus prise en charge.

Le certificat SSL d’AD FS n’est pas identique au certificat de communications du service AD FS du composant logiciel enfichable Gestion AD FS. Pour changer le certificat SSL d’AD FS, vous devez utiliser PowerShell. Suivez les conseils de Gestion des certificats SSL dans AD FS et WAP 2016.

Pour plus d’informations sur la désactivation et l’activation de protocoles SSL et de suites de chiffrement, consultez Gérer les protocoles SSL dans AD FS.

• Si le proxy est utilisé pour les requêtes AD FS qui utilisent l’authentification Windows intégrée, le certificat SSL du proxy doit être utiliser la même clé que le certificat SSL du serveur de fédération.
• Si la propriété ExtendedProtectionTokenCheck d’AD FS est activée (la valeur par défaut dans AD FS), le certificat SSL du proxy doit utiliser la même clé que le certificat SSL du serveur de fédération.
• Si ce n’est pas le cas, le certificat SSL du proxy peut avoir une clé différente de celle du certificat SSL d’AD FS. Il doit répondre aux mêmes spécifications.

AD FS ne montre qu’une seule méthode d’authentification sur l’écran de connexion quand une application exige explicitement un URI d’authentification spécifique qui correspond à une méthode d’authentification configurée et activée. La méthode est indiquée dans le paramètre wauth dans les requêtes WS-Federation. Elle est indiquée dans le paramètre RequestedAuthnCtxRef dans les requêtes du protocole SAML. Seule la méthode d’authentification demandée est affichée. (Par exemple, connexion par mot de passe.)

Quand vous utilisez AD FS avec Azure AD, il est courant que les applications envoient le paramètre prompt=login à Azure AD. Par défaut, Azure AD traduit ce paramètre en une demande de nouvelle connexion basée sur un mot de passe à AD FS. Ce scénario est la raison la plus courante pour laquelle vous pouvez voir une connexion par mot de passe dans AD FS sur votre réseau ou ne pas voir une option pour se connecter avec votre certificat. Vous pouvez facilement résoudre ce problème en modifiant les paramètres du domaine fédéré dans Azure AD.

Pour plus d’informations, consultez Prise en charge du paramètre prompt=login dans les services de fédération Active Directory (AD FS).

Pour changer le compte de service AD FS, utilisez le module PowerShell de compte de service de la boîte à outils d’AD FS. Pour obtenir des instructions, consultez Modifier le compte de service d’AD FS.

Consultez Configurer les navigateurs pour utiliser l’authentification Windows intégrée avec AD FS.

Si vous n’avez pas de stratégies de contrôle d’accès basées sur l’appareil dans AD FS ou d’inscription de certificats Windows Hello Entreprise via AD FS, vous pouvez désactiver BrowserSsoEnabled. BrowserSsoEnabled permet à AD FS de collecter un jeton d’actualisation principal (PRT, Primary Refresh Token) auprès du client, qui contient des informations sur l’appareil. Sans ce jeton, l’authentification d’appareil AD FS ne fonctionnera pas sur les appareils Windows 10.

Les administrateurs se demandent souvent pour combien de temps les utilisateurs obtiennent l’authentification unique (SSO) sans devoir réentrer de nouvelles informations d’identification et comment les administrateurs peuvent contrôler ce comportement. Ce comportement ainsi que les paramètres de configuration qui le contrôlent sont décrits dans Paramètres d’authentification unique d’AD FS.

Les durées de vie par défaut des différents cookies et jetons sont listées ci-dessous (ainsi que les paramètres qui régissent les durées de vie) :

Appareils inscrits

• Cookies PRT et SSO : 90 jours maximum, durée régie par PSSOLifeTimeMins. (À condition que l’appareil soit utilisé au moins tous les 14 jours. Cette fenêtre de temps est contrôlée par DeviceUsageWindow.)

• Jeton d’actualisation : durée calculée en fonction des paramètres précédents pour fournir un comportement cohérent.

• access_token : une heure par défaut, en fonction de la partie de confiance.

• id_token : identique à access_token.

Appareils non inscrits

• Cookies SSO : huit heures par défaut, durée régie par SSOLifetimeMins. Quand l’option Maintenir la connexion (KMSI, Keep me signed in) est activée, la valeur par défaut est de 24 heures. Cette valeur par défaut est configurable via KMSILifetimeMins.

• Jeton d’actualisation : huit heures par défaut. 24 heures si KMSI est activé.

• access_token : une heure par défaut, en fonction de la partie de confiance.

• id_token : identique à access_token.

AD FS ne prend pas en charge les flux implicites pour un client confidentiel. L’authentification du client est activée seulement pour le point de terminaison des jetons, et AD FS n’émet pas de jeton d’accès sans authentification du client. Si le client confidentiel a besoin d’un jeton d’accès et requiert également l’authentification de l’utilisateur, il doit utiliser le flux de code d’autorisation.

HSTS est un mécanisme de stratégie de sécurité web. Il aide à atténuer les attaques par rétrogradation de protocole et le piratage de cookies pour les services qui ont à la fois des points de terminaison HTTP et HTTPS. Il permet aux serveurs web de déclarer que les navigateurs web (ou d’autres agents utilisateur conformes) doivent interagir avec eux seulement en utilisant HTTPS et jamais via le protocole HTTP.

Tous les points de terminaison AD FS pour le trafic d’authentification web sont ouverts exclusivement sur HTTPS. AD FS atténue donc les menaces créées par le mécanisme de la stratégie HSTS. (Par conception, il n’y a pas de rétrogradation à HTTP, car il n’y a pas d’écouteurs dans HTTP.) AD FS empêche également les cookies d’être envoyés à un autre serveur qui a des points de terminaison de protocole HTTP en marquant tous les cookies avec l’indicateur sécurisé.

Vous n’avez donc pas besoin de HSTS sur un serveur AD FS, car HSTS ne peut pas être rétrogradé. Les serveurs AD FS répondent aux exigences de conformité, car ils ne peuvent pas utiliser le protocole HTTP et que tous les cookies sont marqués comme sécurisés.

Enfin, AD FS 2016 (avec les correctifs les plus récents) et AD FS 2019 prennent en charge l’émission de l’en-tête HSTS. Pour configurer ce comportement, consultez Personnaliser des en-têtes de réponse de sécurité HTTP avec AD FS.

Nous vous déconseillons d’effectuer un arrêt de SSL avant le serveur Proxy d’application web. S’il est effectué devant le serveur Proxy d’application web, X-MS-Forwarded-Client-IP va contenir l’adresse IP de l’appareil réseau devant le serveur Proxy d’application web. Voici une brève description des différentes revendications IP prises en charge par AD FS :

• X-MS-Client-IP. Adresse IP réseau de l’appareil connecté au STS. Pour les requêtes extranet, cette revendication contient toujours l’adresse IP du serveur Proxy d’application web.
• X-MS-Forwarded-Client-IP. Revendication à valeurs multiples qui contient toutes les valeurs transférées à AD FS par Exchange Online. Elle contient aussi l’adresse IP de l’appareil connecté au serveur Proxy d’application web.
• Userip. Pour les requêtes extranet, cette revendication contient la valeur de X-MS-Forwarded-Client-IP. Pour les requêtes intranet, cette revendication contient la même valeur que X-MS-Client-IP.

AD FS 2016 (avec les correctifs les plus récents) et les versions ultérieures prennent également en charge la capture de l’en-tête X-Forwarded-For. Tout équilibreur de charge ou appareil réseau qui ne transfère pas au niveau de la couche 3 (l’adresse IP est conservée) doit ajouter l’adresse IP du client entrant à l’en-tête standard du secteur X-Forwarded-For.

Le point de terminaison UserInfo d’AD FS retourne toujours la revendication de sujet comme spécifié dans les standards OpenID. AD FS ne prend pas en charge les revendications supplémentaires demandées via le point de terminaison UserInfo. Si vous avez besoin de revendications supplémentaires dans un jeton d’ID, consultez Jetons d’ID personnalisés dans AD FS.

Ce groupe est créé seulement quand il existe un contrôleur de domaine Windows Server 2016 détenant le rôle de contrôleur de domaine principal FSMO dans le domaine. Pour résoudre l’erreur, vous pouvez créer le groupe manuellement. Effectuez les étapes suivantes pour ajouter les autorisations nécessaires après avoir ajouté le compte de service en tant que membre du groupe :

1. Ouvrez Utilisateurs et ordinateurs Active Directory.
2. Dans le volet gauche, cliquez avec le bouton droit sur votre nom de domaine, puis sélectionnez Propriétés.
3. Sélectionnez Sécurité. (Si l’onglet Sécurité est manquant, activez Fonctionnalités avancées dans le menu Affichage.)
4. Sélectionnez Avancé, Ajouter, puis Sélectionner un principal.
5. La boîte de dialogue Sélectionner un utilisateur, un ordinateur, un compte de service ou un groupe apparaît. Dans la zone Entrez le nom de l’objet à sélectionner, entrez Key Admin Group (Groupe des administrateurs de clés). Sélectionnez OK.
6. Dans la zone S’applique à, sélectionnez Objets utilisateur descendants.
7. Faites défiler jusqu’en bas de la page, puis sélectionnez Effacer tout.
8. Dans la section Propriétés, sélectionnez Read msDS-KeyCredentialLink et Write msDS-KeyCredentialLink.

Pour les applications qui utilisent la bibliothèque ADAL Android, l’authentification auprès d’Azure AD peut échouer pour les utilisateurs fédérés. L’application va recevoir une exception AuthenticationException quand elle tente d’afficher la page de connexion. Dans le navigateur Chrome, la page de connexion AD FS peut être décrite comme non sécurisée.

Pour toutes les versions et tous les appareils, Android ne prend pas en charge le téléchargement de certificats supplémentaires à partir du champ authorityInformationAccess du certificat. Cette limitation s’applique également au navigateur Chrome. Tout certificat d’authentification serveur qui ne contient pas de certificats intermédiaires va provoquer cette erreur si la chaîne de certificats entière n’est pas passée depuis AD FS.

Vous pouvez résoudre ce problème en configurant les serveurs AD FS et Proxy d’application web pour envoyer les certificats intermédiaires nécessaires avec le certificat SSL.

Quand vous exportez le certificat SSL depuis un ordinateur pour l’importer dans le magasin personnel de l’ordinateur des serveurs AD FS et Proxy d’application web, veillez à exporter la clé privée et à sélectionner Échange d’informations personnelles - PKCS #12.

Veillez aussi à sélectionner Inclure tous les certificats dans le chemin du certificat si possible et Exporter toutes les propriétés étendues.

Exécutez certlm.msc sur les serveurs Windows et importez *.pfx dans le magasin de certificats personnel de l’ordinateur. Ainsi, le serveur va passer la chaîne de certificats entière à la bibliothèque ADAL.

AD FS ne prend pas en charge les requêtes HEAD. Les applications ne doivent pas utiliser des requêtes HEAD sur des points de terminaison AD FS. L’utilisation de ces requêtes peut entraîner des réponses d’erreur HTTP inattendues ou retardées. Vous pourriez aussi voir des événements d’erreur inattendus dans le journal des événements AD FS.

Il n’est pas émis de jeton d’actualisation si le jeton émis par le fournisseur d’identité a une validité inférieure à une heure. Pour garantir l’émission d’un jeton d’actualisation, augmentez la validité du jeton émis par le fournisseur d’identité à plus d’une heure.

Le chiffrement du jeton RP est défini sur AES256. Vous ne pouvez pas le changer pour une autre valeur.

Les batteries de serveurs AD FS en mode mixte sont destinées à être temporaires. Lors de votre planification, nous vous recommandons de remplacer le certificat SSL avant le processus de mise à niveau, ou bien d’effectuer le processus et d’augmenter le niveau du comportement de la batterie de serveurs avant de mettre à jour le certificat SSL. Si cette recommandation n’a pas été suivie, utilisez les instructions suivantes pour mettre à jour le certificat SSL.

Sur les serveurs Proxy d’application web, vous pouvez néanmoins toujours utiliser Set-WebApplicationProxySslCertificate. Sur les serveurs AD FS, vous devez utiliser netsh. Procédez comme suit :

1. Sélectionnez un sous-ensemble de serveurs AD FS 2016 pour la maintenance.

2. Sur les serveurs sélectionnés à l’étape précédente, importez le nouveau certificat via la console MMC.

3. Supprimez les certificats existants :

   a. netsh http delete sslcert hostnameport=fs.contoso.com:443

   b. netsh http delete sslcert hostnameport=localhost:443

   c. netsh http delete sslcert hostnameport=fs.contoso.com:49443

4. Ajoutez les nouveaux certificats :

   a. netsh http add sslcert hostnameport=fs.contoso.com:443 certhash=THUMBPRINT appid="{5d89a20c-beab-4389-9447-324788eb944a}" certstorename=My verifyclientcertrevocation=Enable sslctlstorename=AdfsTrustedDevices

   b. netsh http add sslcert hostnameport=localhost:443 certhash=THUMBPRINT appid="{5d89a20c-beab-4389-9447-324788eb944a}" certstorename=My verifyclientcertrevocation=Enable

   c. netsh http add sslcert hostnameport=fs.contoso.com:49443 certhash=THUMBPRINT appid="{5d89a20c-beab-4389-9447-324788eb944a}" certstorename=My verifyclientcertrevocation=Enable clientcertnegotiation=Enable

5. Redémarrez le service AD FS sur le serveur sélectionné.

6. Supprimez un sous-ensemble de serveurs Proxy d’application web pour la maintenance.

7. Sur les serveurs Proxy d’application web sélectionnés, importez le nouveau certificat via la console MMC.

8. Définissez le nouveau certificat sur le serveur Proxy d’application web en utilisant cette applet de commande :

   • Set-WebApplicationProxySslCertificate -Thumbprint " CERTTHUMBPRINT"

9. Redémarrez le service sur les serveurs Proxy d’application web sélectionnés.

10. Replacez les serveurs AD FS et Proxy d’application web sélectionnés dans l’environnement de production.

Mettez à jour le reste des serveurs AD FS et Proxy d’application web de la même façon.

Les serveurs AD FS et Proxy d’application web prennent en charge tous les pare-feux qui n’effectuent pas d’arrêt SSL sur le point de terminaison. De plus, les serveurs AD FS / Proxy d’application web ont des mécanismes intégrés pour :

• Empêcher les attaques web courantes comme les scripts de site à site.
• Effectuer la fonction de proxy d’AD FS.
• Répondre à toutes les exigences définies par le protocole MS-ADFSPIP.

Dans AD FS 2016, la liaison de jeton est automatiquement activée et provoque plusieurs problèmes connus avec les scénarios de proxy et de fédération. Ces problèmes provoquent cet événement. Pour résoudre cet événement, exécutez la commande PowerShell suivante pour supprimer la prise en charge de la liaison de jeton :

Set-AdfsProperties -IgnoreTokenBinding $true

Après une mise à niveau vers Windows Server 2019, la version de configuration du proxy d’application Web affichée continuera à être Windows Server 2016. Le proxy d’application web n’a pas de nouvelles fonctionnalités spécifiques à la version pour Windows Server 2019. Si le niveau de comportement de la batterie de serveurs a été élevé sur AD FS, le proxy d’application web va continuer de s’afficher comme étant Windows Server 2016. Ce comportement est normal.

Quand ESL activé, AD FS effectue le suivi de l’activité des comptes et des emplacements connus pour les utilisateurs dans la base de données ADFSArtifactStore. Cette base de données est mise à l’échelle en fonction du nombre d’utilisateurs et d’emplacements connus suivis. Quand vous prévoyez d’activer ESL, vous pouvez partir du principe que la taille de la base de données ADFSArtifactStore va augmenter de jusqu’à 1 Go par 100 000 utilisateurs.

Si la batterie AD FS utilise la base de données interne Windows, l’emplacement par défaut des fichiers de la base de données est C:\Windows\WID\Data. Pour éviter de saturer ce lecteur, veillez à disposer d’au moins 5 Go de stockage libre avant d’activer ESL. En plus du stockage sur disque, prévoyez une augmentation de la mémoire totale de traitement après l’activation d’ESL de jusqu’à 1 Go de RAM pour des populations d’utilisateurs de 500 000 ou moins.

Voici le texte de l’événement :

Active Directory trust enumeration was unable to enumerate one of more domains due to the following error. Enumeration will continue but the Active Directory identifier list may not be correct. Validate that all expected Active Directory identifiers are present by running Get-ADFSDirectoryProperties.

Cet événement se produit quand des forêts ne sont pas approuvées, et qu’AD FS tente d’énumérer toutes les forêts d’une chaîne de forêts approuvées et de se connecter à toutes les forêts. Par exemple, supposons que la Forêt A et la Forêt B d’AD FS sont approuvées, et que la Forêt B et la Forêt C sont approuvées. AD FS va énumérer les trois forêts et tente de trouver une relation d’approbation entre la Forêt A et la Forêt C. Si les utilisateurs de la forêt défaillante doivent être authentifiés par AD FS, configurez une relation d’approbation entre la forêt AD FS et la forêt défaillante. Si les utilisateurs de la forêt défaillante ne doivent pas être authentifiés par AD FS, ignorez cet événement.

Voici le texte de l’événement :

Microsoft.IdentityServer.AuthenticationFailedException: MSIS5015: Authentication of the presented token failed. Token Binding claim in token must match the binding provided by the channel.

Dans AD FS 2016, la liaison de jeton est automatiquement activée et provoque plusieurs problèmes connus avec les scénarios de proxy et de fédération. Ces problèmes provoquent cet événement. Pour résoudre l’événement, exécutez la commande PowerShell suivante pour supprimer la prise en charge de la liaison de jeton :

Set-AdfsProperties -IgnoreTokenBinding $true

Voici le texte de l’événement :

System.ServiceModel.FaultException: The formatter threw an error while trying to deserialize the message: There was an error while trying to deserialize parameter schemas.microsoft.com/ws/2009/12/identityserver/protocols/policystore:maxBehaviorLevel". The InnerException message was "Invalid enum value 'Win2019' cannot be deserialized into type 'Microsoft.IdentityServer.FarmBehavior'. Ensure that the necessary enum values are present and are marked with EnumMemberAttribute attribute if the type has DataContractAttribute attribute.

Cet événement est attendu quand ces deux conditions sont vraies :

• Vous avez une batterie de serveurs en mode mixte.
• AD FS 2019 fournit les informations de niveau de comportement maximal de la batterie de serveurs au serveur de fédération principal et n’est pas reconnu par le serveur de fédération version 2016.

AD FS 2019 continue d’essayer de partager la valeur Win2019 de MaxBehaviorLevel dans la batterie de serveurs jusqu’à ce qu’elle devienne obsolète après 2 mois et soit automatiquement supprimée de la batterie. Pour éviter de recevoir cet événement, migrez le rôle de fédération principal vers le serveur de fédération avec la dernière version. Suivez les instructions de Pour mettre à niveau votre batterie de serveurs AD FS vers le niveau de comportement de batterie de serveurs Windows Server 2019.