Documentation produit
XenApp and XenDesktop
7.15 LTSR
Voir PDF

Service d’authentification fédérée - Résoudre les problèmes d’ouverture de session Windows

August 23, 2021
Contributeur: 
C C

Cet article décrit les journaux et les messages d’erreur Windows lorsqu’un utilisateur ouvre une session à l’aide de certificats et/ou de cartes à puce. Ces journaux fournissent des informations que vous pouvez utiliser pour résoudre les échecs d’authentification.

Certificats et infrastructure de clé publique

Windows Active Directory propose plusieurs magasins de certificats qui gèrent les certificats pour les utilisateurs qui ouvrent une session.

  • Magasin de certificats NTAuth : pour s’authentifier auprès de Windows, l’autorité de certification émettant les certificats utilisateur (aucune chaîne n’est prise en charge) doit être placée dans le magasin NTAuth. Pour afficher ces certificats, depuis le programme certutil, entrez : certutil –viewstore –enterprise NTAuth.
  • Magasins de certificats racine et intermédiaires : en règle générale, les systèmes d’ouverture de session par certificat peuvent fournir un seul certificat. Donc, 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 être dans le magasin racine de confiance et l’avant-dernier certificat doit être dans le magasin NTAuth.
  • Extensions de certificat d’ouverture de session 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/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/ff404287(v=ws.10)?redirectedfrom=MSDN.
Stratégie du Registre Description
AllowCertificatesWithNoEKU Lorsqu’elle est désactivée, les certificats doivent inclure l’Utilisation améliorée de la clé (EKU) pour l’ouverture de session avec carte à puce.
AllowSignatureOnlyKeys Par défaut, Windows filtre les clés privées de certificats qui ne permettent pas le décryptage RSA. Cette option remplace ce filtre.
AllowTimeInvalidCertificates Par défaut, Windows filtre les certificats expirés. Cette option remplace ce filtre.
EnumerateECCCerts Active l’authentification à 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 d’ouverture de session Windows.
UseCachedCRLOnlyAnd, IgnoreRevocationUnknownErrors Désactive la vérification de la révocation des certificats (généralement définie sur le contrôleur de domaine).
  • Certificats du contrôleur de domaine : pour authentifier les connexions Kerberos, tous les serveurs doivent avoir des certificats « Contrôleur de domaine » appropriés. Ils peuvent être demandés depuis le menu du composant logiciel enfichable MMC « Local Computer Certificate Personal Store » (magasin personnel de certificats 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 de sujet alternatif.

Noms UPN dans Active Directory

Par défaut, chaque utilisateur d’Active Directory est associé à un UPN implicite, basé sur le modèle <NomUtilisateur_sam>@<NetBios_domaine> et <NomUtilisateur_sam>@<FQDN_domaine>. Les domaines disponibles et les noms de domaine complets sont inclus dans l’entrée RootDSE de la forêt. Veuillez noter qu’un seul domaine peut disposer de plusieurs noms de domaine complets enregistrés dans RootDSE.

En outre, chaque utilisateur d’Active Directory a un nom UPN explicite et des altUserPrincipalNames. Ce sont des entrées LDAP qui spécifient le nom d’utilisateur principal (UPN) pour l’utilisateur.

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

Service de mappage de certificat

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

L’utilisateur peut spécifier un compte d’utilisateur qui accélère la recherche et permet également à cette fonctionnalité d’être utilisée dans un environnement inter-domaines.

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

Sélection du contrôleur de domaine d’ouverture de session

Lorsqu’un environnement contient plusieurs contrôleurs de domaine, il est utile de voir et de restreindre le contrôleur de domaine qui est utilisé pour l’authentification, de façon à ce 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 spécifique pour l’ouverture de session, vous pouvez explicitement définir la liste des contrôleurs de domaine qu’une machine Windows utilise en configurant le fichier lmhosts : \Windows\System32\drivers\etc\lmhosts.

Il existe généralement un exemple de fichier nommé « lmhosts.sam » dans cet emplacement. Il vous suffit d’inclure une ligne :

1.2.3.4 dcnetbiosname #PRE #DOM:mondomaine

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

Après un redémarrage, la machine Windows utilise ces informations pour ouvrir une session sur mondomaine. Notez que cette configuration doit être rétablie lors d’un débogage.

Identifier le contrôleur de domaine utilisé

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

Les journaux liés à 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. Ce réglage peut être contrôlé par le biais des stratégies d’audit dans les paramètres de sécurité dans l’éditeur de stratégie de groupe. Une fois qu’ils sont activés, le contrôleur de domaine génère des informations supplémentaires dans le journal d’événements 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 (sans clé privée), vous pouvez le valider avec la commande : certutil –verify user.cer

Activer la journalisation CAPI

Sur le contrôleur de domaine et les machines utilisateur, 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 dans : CurrentControlSet\Services\crypt32.

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

Journaux CAPI

Message Description
Build Chain CertGetCertificateChain appelé par LSA (comprend résultat)
Verify Revocation CertVerifyRevocation appelé par LSA (comprend résultat)
X509 Objects En mode détaillé, les certificats et les listes de révocation de certificats (CRL) sont placés dans AppData\LocalLow\Microsoft\X509Objects
Verify Chain Policy CertVerifyChainPolicy appelé par LSA (comprend paramètres)

Messages d’erreur

Code d’erreur Description
Certificat non approuvé Le certificat de carte à puce n’a pas pu être créé à l’aide de certificats contenus dans les magasins de certificats racine approuvés et intermédiaires de l’ordinateur.
Erreur de vérification de la révocation de certificats La liste de révocation de certificats 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 liste de révocation de certificat. Si la vérification de la révocation des certificats est obligatoire, l’ouverture de session échoue. Consultez la section Certificats et infrastructure de clé publique.
Erreurs d’utilisation de certificat Le certificat n’est pas approprié pour l’ouverture de session. 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 utilisateur, 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 écrite dans le journal d’événements système.

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

Messages des journaux d’événements

Cette section décrit les entrées de journal attendues sur le contrôleur de domaine et la station de travail lorsque l’utilisateur ouvre une session 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 comme illustré ci-dessous.

image localisée

Le dernier message du journal d’événements indique que lsass.exe sur le contrôleur de domaine construit une chaîne en fonction du certificat fourni par le VDA et vérifie sa validité (y compris la révocation). Le résultat est « ERROR_SUCCESS ».

image localisée

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

Le contrôleur de domaine présente une séquence des événements d’ouverture de session, l’événement clé étant 4768, dans lequel le certificat est utilisé pour émettre le ticket Kerberos Ticket Granting (krbtgt).

Les messages précédents indiquent que le compte de machine du serveur s’authentifie auprès du contrôleur de domaine. Les messages suivants indiquent le compte d’utilisateur appartenant au nouveau krbtgt 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 4648, provenant de winlogon.exe.

image localisée

Journal CAPI VDA

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

image localisée

image localisée

Journal système VDA

Lorsque l’ouverture de session 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 dresse la liste des messages d’erreur courants s’affichant sur la page d’ouverture de session Windows.

Message d’erreur affiché Description et référence
Nom d’utilisateur ou mot de passe non valide L’ordinateur détecte 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. Impossible de vérifier les informations d’identification. Le contrôleur de domaine ne peut pas être contacté, ou les certificats appropriés ne sont pas installés sur le contrôleur de domaine.
La requête n’est pas prise en charge. Réinscrivez les certificats « Contrôleur de domaine » et « Authentification du contrôleur de domaine » sur le contrôleur de domaine, comme décrit dans la section CTX206156. Cette réinscription est recommandée, 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’est pas approuvé. Les certificats racine et intermédiaire ne sont pas installés sur l’ordinateur local. Consultez l’article CTX206156 pour obtenir des instructions sur l’installation de certificats de carte à puce sur des ordinateurs n’appartenant pas à un domaine. Voir également Certificats et infrastructure de clé publique dans cet article.
Vous ne pouvez pas ouvrir de session car l’ouverture de session par carte à puce n’est pas prise en charge par votre compte. Un compte utilisateur de groupe de travail n’a pas été complètement configuré pour l’ouverture de session par carte à puce.
La clé requise 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 correctement configurée et que le fichier CCC ou CHUID est manquant.
Une erreur s’est produite lors de la tentative d’utilisation de la carte à puce Le middleware de carte à puce n’a pas été correctement installé. Voir CTX206156 pour des instructions d’installation de carte à puce.
Insérez une carte à puce. Le lecteur ou la carte à puce n’a pas été détecté. Si la carte à puce est insérée, ce message indique un problème de matériel ou de middleware. Voir CTX206156 pour des instructions d’installation de carte à puce.
Le code PIN est incorrect La carte à puce a rejeté un code PIN entré par l’utilisateur.
Aucun certificat de carte à puce valide n’a été trouvé. Les extensions du certificat peuvent ne pas être correctement configurées, ou la clé RSA est trop courte (<2 048 bits). Consultez la section CTX206901 pour de plus amples 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, la saisie d’un code PIN incorrect plusieurs fois). Un administrateur peut avoir accès au code de déverrouillage du code PIN (puk) pour la carte et peut réinitialiser le code PIN de l’utilisateur à l’aide d’un outil du fournisseur de carte à puce. Si le code puk n’est pas disponible ou verrouillé, la carte doit être réinitialisée sur ses paramètres d’usine.
Demande 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écryptage de clé privée », mais la carte à puce ne prend en charge que la signature. Ceci indique habituellement que les extensions sur le certificat ne sont pas définies correctement, ou que la clé RSA est trop courte (<2 048 bits). Consultez la section CTX206901 pour de plus amples informations sur la génération de certificats de carte à puce valides.

Informations connexes

Service d’authentification fédérée - Résoudre les problèmes d’ouverture de session Windows
August 23, 2021
Contributeur: 
C C
August 23, 2021
Contributeur: 
C C

Dans cet article

Commentaires sur le site | 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.