Configurer AD FS pour l’authentification par certificat utilisateur

  • Article

Cet article explique comment activer l’authentification par certificat utilisateur dans les services de fédération Active Directory (AD FS). Il fournit également des informations de résolution des problèmes courants liés à ce type d’authentification.

Il existe deux cas d’usage principaux pour l’authentification par certificat utilisateur :

  • Les utilisateurs utilisent des cartes à puce pour se connecter à leur système AD FS.
  • Les utilisateurs utilisent des certificats provisionnés sur des appareils mobiles.

Prérequis

  • Déterminez le mode d’authentification par certificat utilisateur AD FS que vous souhaitez activer à l’aide de l’un des modes décrits dans Prise en charge d’AD FS pour la liaison de nom d’hôte de remplacement pour l’authentification par certificat.
  • Vérifiez que votre chaîne d’approbation de certificat utilisateur est installée et approuvée par tous les serveurs AD FS et Web Proxy d'application (WAP), y compris les autorités de certification intermédiaires. Vous le faites généralement via une stratégie de groupe Object (GPO) sur les serveurs AD FS et WAP.
  • Vérifiez que le certificat racine de la chaîne d’approbation pour vos certificats utilisateur se trouve dans le magasin NTAuth dans Active Directory.
  • Si vous utilisez AD FS dans un autre mode d’authentification par certificat, assurez-vous que vos serveurs AD FS et WAP disposent de certificats SSL (Secure Sockets Layer) qui contiennent le nom d’hôte AD FS préfixé par « certauth ». Par exemple, certauth.fs.contoso.com. Vérifiez également que le trafic vers ce nom d’hôte est autorisé via le pare-feu.
  • Si vous utilisez l’authentification par certificat à partir de l’extranet, assurez-vous qu’au moins un accès aux informations d’autorité (AIA) et au moins un point de distribution de liste de révocation de certificats (CDP) ou un emplacement OCSP (Online Certificate Status Protocol) de la liste spécifiée dans vos certificats sont accessibles à partir d’Internet.
  • Si vous configurez AD FS pour l'authentification par certificat Microsoft Entra, vérifiez que vous avez configuré les paramètres Microsoft Entra et les règles de revendication AD FS requises pour l'éditeur de certificat et le n° de série.
  • Si vous utilisez l'authentification par certificat Microsoft Entra pour les clients Exchange ActiveSync, le certificat client doit avoir l'adresse de messagerie routable de l'utilisateur dans Exchange Online, dans la valeur Nom du principal ou la valeur Nom RFC822 du champ Autre nom de l'objet. Microsoft Entra ID mappe la valeur RFC822 à l'attribut Adresse proxy dans l'annuaire.

Remarque

AD FS ne prend pas en charge les indicateurs de nom d’utilisateur avec l’authentification par carte à puce ou par certificat.

Activer l’authentification par certificat utilisateur

Activez l’authentification par certificat utilisateur en tant que méthode d’authentification intranet ou extranet dans AD FS, à l’aide de la console de gestion AD FS ou de l’applet de commande Set-AdfsGlobalAuthenticationPolicy PowerShell.

Les considérations facultatives sont les suivantes :

  • Si vous souhaitez utiliser des revendications basées sur des champs de certificat et des extensions en plus du type de revendication EKU, https://schemas.microsoft.com/2012/12/certificatecontext/extension/eku, configurez d’autres règles de transfert de revendication sur l’approbation du fournisseur de revendications Active Directory. Consultez la liste complète des revendications de certificat disponibles plus loin dans cet article.

  • Si vous devez restreindre l’accès en fonction du type de certificat, vous pouvez utiliser les propriétés supplémentaires sur le certificat dans les règles d’autorisation d’émission AD FS pour l’application. Les scénarios courants sont d’autoriser uniquement les certificats provisionnés par un fournisseur de gestion des appareils mobiles ou d’autoriser uniquement les certificats de carte à puce.

    Important

    Les clients qui utilisent le flux de code d'appareil pour l'authentification et effectuent l'authentification d'appareil à l'aide d'un fournisseur d'identité autre que Microsoft Entra ID (par exemple, AD FS) ne peuvent pas appliquer l'accès basé sur l'appareil aux ressources Microsoft Entra. Par exemple, ils ne peuvent pas autoriser uniquement les appareils gérés à l’aide d’un service de gestion des appareils mobiles tiers.

    Pour protéger l'accès aux ressources d'entreprise dans Microsoft Entra ID et éviter toute fuite de données, configurez l'accès conditionnel basé sur les appareils Microsoft Entra. Par exemple, utilisez Exiger que l'appareil soit marqué comme plainte pour accorder le contrôle dans l'accès conditionnel Microsoft Entra.

    Configurez les autorités de certification émettrices autorisées pour les certificats clients en suivant les instructions fournies sous « Gestion des émetteurs approuvés pour l’authentification du client » dans la vue d’ensemble technique du SSP Schannel.

  • Envisagez de modifier les pages de connexion en fonction des besoins de vos utilisateurs lorsqu’ils effectuent l’authentification par certificat. Un cas courant consiste à remplacer Connexion avec votre certificat X509 par quelque chose de plus convivial.

Configurer l’authentification transparente par certificat pour le navigateur Chrome sur les ordinateurs de bureau Windows

Lorsqu’un ordinateur dispose de plusieurs certificats utilisateur (tels que des certificats Wi-Fi) qui répondent aux besoins de l’authentification client, le navigateur Chrome sur les ordinateurs de bureau Windows invite les utilisateurs à sélectionner le certificat approprié. Cette invite peut prêter à confusion pour les utilisateurs. Pour optimiser cette expérience, vous pouvez définir une stratégie pour Chrome afin de sélectionner automatiquement le certificat approprié.

Vous pouvez définir cette stratégie manuellement en apportant une modification au registre, ou vous pouvez la configurer automatiquement via un objet de stratégie de groupe (pour définir les clés de Registre). Cela nécessite que vos certificats clients utilisateur pour l’authentification auprès d’AD FS aient des émetteurs distincts des autres cas d’usage.

Pour plus d’informations sur la configuration de l’authentification par certificat pour Chrome, consultez la liste des stratégies Chrome Enterprise.

Résoudre les problèmes d’authentification par certificat

Utilisez les informations suivantes pour résoudre les problèmes courants lorsque vous avez configuré AD FS pour l’authentification par certificat pour les utilisateurs.

Vérifier si les émetteurs de certificats approuvés sont correctement configurés dans tous les serveurs AD FS et WAP

Si les émetteurs de certificat approuvés ne sont pas configurés correctement, un symptôme courant est une erreur HTTP 204 : « Aucun contenu de https://certauth.adfs.contoso.com." ;

AD FS utilise le système d’exploitation Windows sous-jacent pour prouver la possession du certificat utilisateur et s’assurer qu’il correspond à un émetteur approuvé en validant la chaîne d’approbation de certificat. Pour faire correspondre l’émetteur approuvé, vous devez vous assurer que toutes les autorités racines et intermédiaires sont configurées en tant qu’émetteurs approuvés dans le magasin local pour les autorités de certification de l’ordinateur.

Pour valider cela automatiquement, utilisez l’outil Analyseur de diagnostics AD FS. L’outil interroge tous les serveurs et garantit que les certificats appropriés sont correctement provisionnés.

  1. Téléchargez et exécutez l’outil.
  2. Chargez les résultats et examinez les éventuels échecs.

Vérifier si l’authentification par certificat est activée dans la stratégie d’authentification AD FS

AD FS effectue l’authentification par certificat utilisateur par défaut sur le port 49443 avec le même nom d’hôte qu’AD FS (exemple : adfs.contoso.com). Vous pouvez également configurer AD FS pour utiliser le port 443 (le port HTTPS par défaut) à l’aide de la liaison SSL de remplacement. Toutefois, l’URL utilisée dans cette configuration est certauth.<adfs-farm-name> (exemple : certauth.contoso.com). Pour plus d’informations, consultez Prise en charge AD FS de la liaison de l’autre nom d’hôte pour l’authentification par certificat.

Notes

Dans AD FS sur Windows Server 2016, deux modes sont désormais pris en charge. Le premier mode utilise l’hôte adfs.contoso.com avec les ports 443 et 49443. Le deuxième mode utilise des hôtes adfs.contoso.com et certauth.adfs.contoso.com avec le port 443. Vous avez besoin d’un certificat SSL à prendre en charge certauth.\<adfs-service-name> comme autre nom d’objet. Vous pouvez le faire au moment de la création de la batterie de serveurs ou ultérieurement via PowerShell.

Le cas le plus courant de problèmes de connectivité réseau concerne le fait qu’un pare-feu a été mal configuré et bloque le trafic pour l’authentification par certificat utilisateur. En règle générale, vous voyez un écran vide ou une erreur de serveur 500 lorsque ce problème se produit. Pour corriger :

  1. Notez le nom d’hôte et le port que vous avez configurés dans AD FS.
  2. Vérifiez que tout pare-feu devant AD FS ou WAP est configuré pour autoriser la combinaison hostname:port pour votre batterie de serveurs AD FS. Votre ingénieur réseau doit effectuer cette étape.

Vérifier la connectivité de la liste de révocation de certificats

Les listes de révocation de certificats sont des points de terminaison qui sont encodés dans le certificat utilisateur pour effectuer des vérifications de révocation du runtime. Par exemple, si un appareil contenant un certificat est volé, un administrateur peut ajouter le certificat à la liste des certificats révoqués. Tout point de terminaison qui a accepté ce certificat précédemment échoue désormais à l’authentification.

Chaque serveur AD FS et WAP doit atteindre le point de terminaison de liste de révocation de certificats pour vérifier si le certificat qui lui a été présenté est toujours valide et n’a pas été révoqué. La validation de la liste de révocation de certificats peut se produire via HTTPS, HTTP, LDAP ou OCSP. Si les serveurs AD FS et WAP ne peuvent pas atteindre le point de terminaison, l’authentification échoue. Appliquer la procédure suivante pour résoudre le problème :

  1. Consultez votre ingénieur d’infrastructure à clé publique (PKI) pour déterminer quels points de terminaison de liste de révocation de certificats sont utilisés pour révoquer les certificats utilisateur de votre système PKI.
  2. Sur chaque serveur AD FS et WAP, assurez-vous que les points de terminaison de liste de révocation de certificats sont accessibles via le protocole utilisé (généralement HTTPS ou HTTP).
  3. Pour une validation avancée, activez la journalisation des événements CAPI2 sur chaque serveur AD FS et WAP.
  4. Recherchez l’ID d’événement 41 (Vérifier la révocation) dans les journaux des opérations CAPI2.
  5. Vérifiez <Result value="80092013">The revocation function was unable to check revocation because the revocation server was offline.</Result>.

Conseil

Vous pouvez cibler un seul serveur AD FS ou WAP pour faciliter la résolution des problèmes en configurant la résolution DNS (fichier hosts sur Windows) pour qu’elle pointe vers un serveur spécifique. Cette technique vous permet d’activer le suivi en ciblant un serveur.

Rechercher les problèmes avec l’indication du nom du serveur

AD FS nécessite des appareils clients (ou des navigateurs) et les équilibreurs de charge pour prendre en charge l’indication de nom de serveur. Certains appareils clients (par exemple, les versions antérieures d’Android) peuvent ne pas prendre en charge l’indication de nom de serveur. En outre, les équilibreurs de charge peuvent ne pas prendre en charge l’indication de nom de serveur ou ne pas être configurés pour l’indication de nom de serveur. Dans ces cas, vous êtes susceptible d’obtenir des échecs de certification des utilisateurs.

Pour résoudre ce problème, collaborez avec votre ingénieur réseau pour vous assurer que l’équilibreur de charge pour AD FS et WAP prend en charge l’indication de nom de serveur. Si l’indication de nom de serveur ne peut pas être pris en charge, utilisez la solution de contournement suivante dans AD FS :

  1. Ouvrez une fenêtre d’invite de commandes avec élévation de privilèges sur le serveur AD FS principal.
  2. Entrez Netsh http show sslcert.
  3. Copiez le GUID d’application et le hachage du certificat du service de fédération.
  4. Entrez netsh http add sslcert ipport=0.0.0.0:{your_certauth_port} certhash={your_certhash} appid={your_applicaitonGUID}.

Vérifier si l’appareil client a été correctement approvisionné avec le certificat

Vous remarquerez peut-être que certains appareils fonctionnent correctement, mais que d’autres ne le sont pas. Dans la plupart des cas, cela signifie que le certificat utilisateur n’a pas été correctement provisionné sur certains appareils clients. Procédez comme suit :

  1. Si le problème est spécifique à un appareil Android, la cause la plus courante est que la chaîne de certificats n’est pas entièrement approuvée sur l’appareil. Reportez-vous à votre fournisseur MDM pour vous assurer que le certificat a été correctement approvisionné et que l’ensemble de la chaîne est entièrement fiable sur l’appareil Android.

    Si le problème est spécifique à un appareil Windows, vérifiez si le certificat est correctement approvisionné en vérifiant le magasin de certificats Windows pour l’utilisateur connecté (et non système ou ordinateur).

  2. Exportez le certificat utilisateur client dans un fichier .cer et exécutez la commande certutil -f -urlfetch -verify certificatefilename.cer.

Vérifier si la version TLS est compatible entre les serveurs AD FS/WAP et l’appareil client

Dans de rares cas, un appareil client est mis à jour pour prendre en charge uniquement une version supérieure de TLS (par exemple, 1.3). Ou vous pouvez avoir le problème inverse, où les serveurs AD FS et WAP ont été mis à jour pour utiliser uniquement une version TLS supérieure que l’appareil client ne prend pas en charge.

Vous pouvez utiliser les outils SSL en ligne pour vérifier vos serveurs AD FS et WAP et voir s’ils sont compatibles avec l’appareil. Pour plus d’informations sur le contrôle des versions TLS, consultez Gestion des protocoles SSL/TLS et des suites de chiffrement pour AD FS.

Vérifiez si Microsoft Entra PromptLoginBehavior est correctement configuré sur vos paramètres de domaine fédéré

De nombreuses applications Office 365 envoient prompt=login à Microsoft Entra ID. Microsoft Entra ID, par défaut, le convertit en un nouveau mot de passe de connexion à AD FS. Par conséquent, même si vous avez configuré l’authentification par certificat dans AD FS, vos utilisateurs voient uniquement une connexion par mot de passe. Pour corriger ce problème :

  1. Obtenez les paramètres de domaine fédéré à l’aide de l’applet Get-MgDomainFederationConfiguration.
  2. Vérifiez que le paramètre PromptLoginBehavior est défini sur Disabled ou NativeSupport.

Pour plus d’informations, consultez Prise en charge des paramètres AD FS prompt=login.

Résolution de problèmes supplémentaires

Dans un cas rare, si vos listes de listes de révocation de certificats sont très longues, elles peuvent atteindre un délai d’attente lors de la tentative de téléchargement. Dans ce cas, vous devez mettre à jour MaxFieldLength et MaxRequestByte, comme décrit dans Http.sys paramètres du Registre pour Windows.

Référence : liste complète des types de revendications de certificat utilisateur et des exemples de valeurs

Type de revendication Valeur d'exemple
http://schemas.microsoft.com/2012/12/certificatecontext/field/x509version 3
http://schemas.microsoft.com/2012/12/certificatecontext/field/signaturealgorithm sha256RSA
http://schemas.microsoft.com/2012/12/certificatecontext/field/issuer CN=entca, DC=domain, DC=contoso, DC=com
http://schemas.microsoft.com/2012/12/certificatecontext/field/issuername CN=entca, DC=domain, DC=contoso, DC=com
http://schemas.microsoft.com/2012/12/certificatecontext/field/notbefore 12/05/2016 20:50:18
http://schemas.microsoft.com/2012/12/certificatecontext/field/notafter 12/05/2017 20:50:18
http://schemas.microsoft.com/2012/12/certificatecontext/field/subject E=user@contoso.com, CN=user, CN=Users, DC=domain, DC=contoso, DC=com
http://schemas.microsoft.com/2012/12/certificatecontext/field/subjectname E=user@contoso.com, CN=user, CN=Users, DC=domain, DC=contoso, DC=com
http://schemas.microsoft.com/2012/12/certificatecontext/field/rawdata {Base64 encoded digital certificate data}
http://schemas.microsoft.com/2012/12/certificatecontext/extension/keyusage DigitalSignature
http://schemas.microsoft.com/2012/12/certificatecontext/extension/keyusage KeyEncipherment
http://schemas.microsoft.com/2012/12/certificatecontext/extension/subjectkeyidentifier 9D11941EC06FACCCCB1B116B56AA97F3987D620A
http://schemas.microsoft.com/2012/12/certificatecontext/extension/authoritykeyidentifier KeyID=d6 13 e3 6b bc e5 d8 15 52 0a fd 36 6a d5 0b 51 f3 0b 25 7f
http://schemas.microsoft.com/2012/12/certificatecontext/extension/certificatetemplatename User
http://schemas.microsoft.com/2012/12/certificatecontext/extension/san Other Name:Principal Name=user@contoso.com, RFC822 Name=user@contoso.com
http://schemas.microsoft.com/2012/12/certificatecontext/extension/eku 1.3.6.1.4.1.311.10.3.4