Documentation produit
XenApp and XenDesktop
7.15 LTSR
Voir PDF

Dépannage des problèmes de connexion Windows avec le service d’authentification fédérée

May 20, 2026
Contributeur: 
C C

Cet article décrit les journaux et les messages d’erreur fournis par Windows lorsqu’un utilisateur se connecte à l’aide de certificats et/ou de cartes à puce. Ces journaux fournissent des informations que vous pouvez utiliser pour dépanner les échecs d’authentification.

Certificats et infrastructure à clé publique

Windows Active Directory gère plusieurs magasins de certificats qui gèrent les certificats pour les utilisateurs qui se connectent.

  • Magasin de certificats NTAuth : Pour s’authentifier auprès de Windows, l’autorité de certification émettant directement les certificats utilisateur (c’est-à-dire qu’aucune chaîne n’est prise en charge) doit être placée dans le magasin NTAuth. Pour afficher ces certificats, à partir du programme certutil, entrez : certutil –viewstore –enterprise NTAuth.
  • Magasins de certificats racine et intermédiaires : Généralement, les systèmes de connexion par certificat ne peuvent fournir qu’un seul certificat. Par conséquent, si une chaîne est utilisée, le magasin de certificats intermédiaires sur toutes les machines doit inclure ces certificats. Le certificat racine doit se trouver dans le magasin de racines de confiance, et l’avant-dernier certificat doit se trouver dans le magasin NTAuth.
  • Extensions de certificat de connexion et stratégie de groupe : Windows peut être configuré pour appliquer la vérification des EKU et d’autres stratégies de certificat. Consultez la documentation Microsoft : https://docs.microsoft.com/fr-fr/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/ff404287(v=ws.10)?redirectedfrom=MSDN.
Stratégie de registre Description
AllowCertificatesWithNoEKU Lorsqu’elle est désactivée, les certificats doivent inclure l’utilisation étendue de clé (EKU) de connexion par carte à puce.
AllowSignatureOnlyKeys Par défaut, Windows filtre les clés privées de certificat qui n’autorisent pas le déchiffrement RSA. Cette option annule ce filtre.
AllowTimeInvalidCertificates Par défaut, Windows filtre les certificats expirés. Cette option annule ce filtre.
EnumerateECCCerts Active l’authentification par courbe elliptique.
X509HintsNeeded Si un certificat ne contient pas de nom d’utilisateur principal (UPN) unique, ou s’il peut être ambigu, cette option permet aux utilisateurs de spécifier manuellement leur compte de connexion Windows.
UseCachedCRLOnlyAnd, IgnoreRevocationUnknownErrors Désactive la vérification de la révocation (généralement définie sur le contrôleur de domaine).
  • Certificats de contrôleur de domaine : Pour authentifier les connexions Kerberos, tous les serveurs doivent disposer de certificats « Contrôleur de domaine » appropriés. Ceux-ci peuvent être demandés à l’aide du menu du composant logiciel enfichable MMC « Magasin de certificats personnels de l’ordinateur local ».

Nom UPN et mappage de certificat

Il est recommandé que les certificats utilisateur incluent un nom d’utilisateur principal (UPN) unique dans l’extension Nom alternatif du sujet.

Noms UPN dans Active Directory

Par défaut, chaque utilisateur dans Active Directory possède un UPN implicite basé sur le modèle <samUsername>@<domainNetBios> et <samUsername>@<domainFQDN>. Les domaines et FQDN disponibles sont inclus dans l’entrée RootDSE de la forêt. Notez qu’un seul domaine peut avoir plusieurs adresses FQDN enregistrées dans le RootDSE.

De plus, chaque utilisateur dans Active Directory possède un UPN explicite et des altUserPrincipalNames. Ce sont des entrées LDAP qui spécifient l’UPN pour l’utilisateur.

Lors de la recherche d’utilisateurs par UPN, Windows recherche d’abord dans le domaine actuel (en fonction de l’identité du processus recherchant l’UPN) les UPN explicites, puis les UPN alternatifs. S’il n’y a pas de correspondances, il recherche l’UPN implicite, qui peut se résoudre à différents domaines dans la forêt.

Service de mappage de certificats

Si un certificat n’inclut pas d’UPN explicite, Active Directory a la possibilité de stocker un certificat public exact pour chaque utilisation dans un attribut « x509certificate ». Pour résoudre un tel certificat à un utilisateur, un ordinateur peut interroger directement cet attribut (par défaut, dans un seul domaine).

Une option est fournie à l’utilisateur pour spécifier un compte utilisateur qui accélère cette recherche et permet également d’utiliser cette fonctionnalité dans un environnement inter-domaine.

S’il existe plusieurs domaines dans la forêt et que l’utilisateur ne spécifie pas explicitement de domaine, le rootDSE d’Active Directory spécifie l’emplacement du service de mappage de certificats. Celui-ci est généralement situé sur une machine de catalogue global et dispose d’une vue en cache de tous les attributs de certificat x509 de la forêt. Cet ordinateur peut être utilisé pour trouver efficacement un compte utilisateur dans n’importe quel domaine, en se basant uniquement sur le certificat.

Contrôler la sélection du contrôleur de domaine de connexion

Lorsqu’un environnement contient plusieurs contrôleurs de domaine, il est utile de voir et de restreindre le contrôleur de domaine utilisé pour l’authentification, afin que les journaux puissent être activés et récupérés.

Contrôler la sélection du contrôleur de domaine

Pour forcer Windows à utiliser un contrôleur de domaine Windows particulier pour la connexion, vous pouvez définir explicitement la liste des contrôleurs de domaine qu’une machine Windows utilise en configurant le fichier lmhosts : \Windows\System32\drivers\etc\lmhosts.

Il y a généralement un fichier d’exemple nommé « lmhosts.sam » à cet emplacement. Incluez simplement une ligne :

1.2.3.4 dcnetbiosname #PRÉF #DOMAINE:mydomai

Où « 1.2.3.4 » est l’adresse IP du contrôleur de domaine nommé « dcnetbiosname » dans le domaine « mydomain ».

Après un redémarrage, la machine Windows utilise ces informations pour se connecter à mydomain. Notez que cette configuration doit être annulée une fois le débogage terminé.

Identifier le contrôleur de domaine utilisé

Lors de la connexion, Windows définit une variable d’environnement MSDOS avec le contrôleur de domaine qui a connecté l’utilisateur. Pour le voir, démarrez l’invite de commande avec la commande : echo %LOGONSERVER%.

Les journaux relatifs à l’authentification sont stockés sur l’ordinateur renvoyé par cette commande.

Activer les événements d’audit de compte

Par défaut, les contrôleurs de domaine Windows n’activent pas les journaux d’audit de compte complets. Cela peut être contrôlé via les stratégies d’audit dans les paramètres de sécurité de l’éditeur de stratégie de groupe. Une fois activés, le contrôleur de domaine produit des informations supplémentaires de journal d’événements dans le fichier journal de sécurité.

image localisée

Journaux de validation de certificat

Vérifier la validité du certificat

Si un certificat de carte à puce est exporté en tant que certificat DER (aucune clé privée requise), vous pouvez le valider avec la commande : certutil –verify user.cer

Activer la journalisation CAPI

Sur le contrôleur de domaine et la machine des utilisateurs, ouvrez l’observateur d’événements et activez la journalisation pour Microsoft/Windows/CAPI2/Operational Logs.

Vous pouvez contrôler la journalisation CAPI avec les clés de registre à l’emplacement : CurrentControlSet\Services\crypt32.

Valeur Description
DiagLevel (DWORD) Niveau de verbosité (0 à 5)
DiagMatchAnyMask (QUADWORD) Filtre d’événements (utiliser 0xffffff pour tout)
DiagProcessName (MULTI_SZ) Filtrer par nom de processus (par exemple, LSASS.exe)

Journaux CAPI

Message Description
Chaîne de construction LSA a appelé CertGetCertificateChain (inclut le résultat)
Vérifier la révocation LSA a appelé CertVerifyRevocation (inclut le résultat)
Objets X509 En mode détaillé, les certificats et les listes de révocation de certificats (CRL) sont vidés dans AppData\LocalLow\Microsoft\X509Objects
Vérifier la politique de chaîne LSA a appelé CertVerifyChainPolicy (inclut les paramètres)

Messages d’erreur

Code d’erreur Description
Certificat non approuvé Le certificat de carte à puce n’a pas pu être généré à l’aide des certificats des magasins de certificats intermédiaires et racines de confiance de l’ordinateur.
Erreur de vérification de la révocation du certificat La liste de révocation de certificats (CRL) pour la carte à puce n’a pas pu être téléchargée à partir de l’adresse spécifiée par le point de distribution de la CRL du certificat. Si la vérification de la révocation est obligatoire, cela empêche la connexion de réussir. Consultez la section Certificats et infrastructure à clé publique.
Erreurs d’utilisation du certificat Le certificat n’est pas adapté à la connexion. Par exemple, il peut s’agir d’un certificat de serveur ou d’un certificat de signature.

Journaux Kerberos

Pour activer la journalisation Kerberos, sur le contrôleur de domaine et la machine de l’utilisateur final, créez les valeurs de registre suivantes :

Ruche Nom de la valeur Valeur [DWORD]
CurrentControlSet\Control\Lsa\Kerberos\Parameters LogLevel 0x1
CurrentControlSet\Control\Lsa\Kerberos\Parameters KerbDebuglevel 0xffffffff
CurrentControlSet\Services\Kdc KdcDebugLevel 0x1
CurrentControlSet\Services\Kdc KdcExtraLogLevel 0x1f

La journalisation Kerberos est générée dans le journal d’événements système.

  • Les messages tels que « certificat non approuvé » devraient être faciles à diagnostiquer.
  • Deux codes d’erreur sont informatifs et peuvent être ignorés en toute sécurité :
    • KDC_ERR_PREAUTH_REQUIRED (utilisé pour la compatibilité descendante avec les contrôleurs de domaine plus anciens)
    • Erreur inconnue 0x4b

Messages du journal d’événements

Cette section décrit les entrées de journal attendues sur le contrôleur de domaine et le poste de travail lorsque l’utilisateur se connecte avec un certificat.

  • Journal CAPI2 du contrôleur de domaine
  • Journaux de sécurité du contrôleur de domaine
  • Journal de sécurité VDA
  • Journal CAPI VDA
  • Journal système VDA

Journal CAPI2 du contrôleur de domaine

Lors d’une ouverture de session, le contrôleur de domaine valide le certificat de l’appelant, produisant une séquence d’entrées de journal sous la forme suivante.

image localisée

Le message final du journal d’événements montre lsass.exe sur le contrôleur de domaine construisant une chaîne basée sur le certificat fourni par le VDA, et la vérifiant pour sa validité (y compris la révocation). Le résultat est renvoyé comme « ERROR_SUCCESS ».

image localisée

Journal de sécurité du contrôleur de domaine

Le contrôleur de domaine affiche une séquence d’événements d’ouverture de session, l’événement clé étant 4768, où le certificat est utilisé pour émettre le Ticket d’octroi de ticket Kerberos (krbtgt).

Les messages précédents montrent le compte machine du serveur s’authentifiant auprès du contrôleur de domaine. Les messages suivants montrent le compte utilisateur appartenant au nouveau krbtgt étant utilisé pour s’authentifier auprès du contrôleur de domaine.

image localisée

Journal de sécurité VDA

Le journal d’audit de sécurité VDA correspondant à l’événement d’ouverture de session est l’entrée avec l’ID d’événement 4648, provenant de winlogon.exe.

image localisée

Journal CAPI du VDA

Cet exemple de journal CAPI du VDA montre une séquence unique de construction et de vérification de chaîne depuis lsass.exe, validant le certificat du contrôleur de domaine (dc.citrixtest.net).

image localisée

image localisée

Journal système du VDA

Lorsque la journalisation Kerberos est activée, le journal système affiche l’erreur KDC_ERR_PREAUTH_REQUIRED (qui peut être ignorée), et une entrée de Winlogon indiquant que l’ouverture de session Kerberos a réussi.

image localisée

Messages d’erreur de l’utilisateur final

Cette section répertorie les messages d’erreur courants affichés à un utilisateur sur la page d’ouverture de session Windows.

Message d’erreur affiché Description et référence
Nom d’utilisateur ou mot de passe invalide L’ordinateur estime que vous disposez d’un certificat et d’une clé privée valides, mais le contrôleur de domaine Kerberos a rejeté la connexion. Consultez la section Journaux Kerberos de cet article.
Le système n’a pas pu vous connecter. Vos informations d’identification n’ont pas pu être vérifiées. Le contrôleur de domaine ne peut pas être contacté, ou le contrôleur de domaine ne dispose pas des certificats appropriés installés.
La demande n’est pas prise en charge Réinscrivez les certificats « Domain Controller » et « Domain Controller Authentication » sur le contrôleur de domaine, comme décrit dans CTX206156. Cela vaut généralement la peine d’être essayé, même lorsque les certificats existants semblent valides.
Le système n’a pas pu vous connecter. Le certificat de carte à puce utilisé pour l’authentification n’était pas approuvé. Les certificats intermédiaires et racine ne sont pas installés sur l’ordinateur local. Consultez CTX206156 pour obtenir des instructions sur l’installation des certificats de carte à puce sur les ordinateurs non joints à un domaine. Consultez également la section Certificats et infrastructure à clé publique de cet article.
Vous ne pouvez pas vous connecter car la connexion par carte à puce n’est pas prise en charge pour votre compte. Un compte d’utilisateur de groupe de travail n’a pas été entièrement configuré pour la connexion par carte à puce.
La clé demandée n’existe pas Un certificat fait référence à une clé privée qui n’est pas accessible. Cela peut se produire lorsqu’une carte PIV n’est pas entièrement configurée et qu’il manque le fichier CHUID ou CCC.
Une erreur s’est produite lors de la tentative d’utilisation de la carte à puce Le middleware de la carte à puce n’a pas été installé correctement. Consultez CTX206156 pour les instructions d’installation de la carte à puce.
Insérez une carte à puce La carte à puce ou le lecteur n’a pas été détecté. Si la carte à puce est insérée, ce message indique un problème matériel ou de middleware. Consultez CTX206156 pour les instructions d’installation de la carte à puce.
Le code PIN est incorrect La carte à puce a rejeté un code PIN saisi par l’utilisateur.
Aucun certificat de carte à puce valide n’a pu être trouvé. Les extensions du certificat peuvent ne pas être configurées correctement, ou la clé RSA est trop courte (<2048 bits). Consultez CTX206901 pour plus d’informations sur la génération de certificats de carte à puce valides.
La carte à puce est bloquée Une carte à puce a été verrouillée (par exemple, l’utilisateur a saisi un code PIN incorrect plusieurs fois). Un administrateur peut avoir accès au code de déverrouillage du code PIN (PUK) de la carte et peut réinitialiser le code PIN de l’utilisateur à l’aide d’un outil fourni par le fournisseur de la carte à puce. Si le code PUK n’est pas disponible ou est bloqué, la carte doit être réinitialisée aux paramètres d’usine.
Requête incorrecte Une clé privée de carte à puce ne prend pas en charge la cryptographie requise par le contrôleur de domaine. Par exemple, le contrôleur de domaine peut avoir demandé un « déchiffrement de clé privée », mais la carte à puce ne prend en charge que la signature. Cela indique généralement que les extensions du certificat ne sont pas configurées correctement, ou que la clé RSA est trop courte (<2048 bits). Consultez CTX206901 pour plus d’informations sur la génération de certificats de carte à puce valides.

Informations connexes

Dépannage des problèmes de connexion Windows avec le service d’authentification fédérée
May 20, 2026
Contributeur: 
C C
May 20, 2026
Contributeur: 
C C

Dans cet article

Commentaires sur le site | Your privacy choices footer linkVos préférences de confidentialité | Confidentialité et conditions légales | Préférences de cookies | Paramètres de consentement | docs.cloud.com
© 1999- Cloud Software Group, Inc. All rights reserved.