Résolution des problèmes de connexion Windows

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 résoudre 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 immédiatement 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 des racines de confiance, et le certificat pénultième 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/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/ff404287(v=ws.10).

• 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 est 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 de « contrôleur de domaine » appropriés. Ceux-ci peuvent être demandés à l’aide du menu du composant logiciel enfichable MMC « Magasin personnel de certificats de l’ordinateur local ».

Nom UPN et mappage de certificats

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 pour 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 (basé sur 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-domaines.

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 x509certificate dans 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 exemple de fichier nommé « lmhosts.sam » à cet emplacement. Incluez simplement une ligne :

1.2.3.4 dcnetbiosname #PRE #DOM: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 vérifier, démarrez l’invite de commandes 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é, le contrôleur de domaine produit des informations de journal d’événements supplémentaires dans le fichier journal de sécurité.

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/Journaux opérationnels.

• 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 tous)
  DiagProcessName (MULTI_SZ)	Filtrer par nom de processus (par exemple, LSASS.exe)

Journaux CAPI

Messages d’erreur

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é du Virtual Delivery Agent (VDA)
• Journal CAPI du VDA
• Journal système du 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.

Le message final du journal des é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 ».

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.

Journal de sécurité du VDA

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

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 par lsass.exe, validant le certificat du contrôleur de domaine (dc.citrixtest.net).

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.

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.

Informations connexes

• Configuration d’un domaine pour l’ouverture de session par carte à puce : http://support.citrix.com/article/CTX206156
• Stratégies d’ouverture de session par carte à puce : https://docs.microsoft.com/fr-fr/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/ff404287(v=ws.10)
• Activation de la journalisation CAPI : http://social.technet.microsoft.com/wiki/contents/articles/242.troubleshooting-pki-problems-on-windows.aspx
• Activation de la journalisation Kerberos : https://support.microsoft.com/fr-fr/kb/262177
• Directives pour l’activation de l’ouverture de session par carte à puce avec des autorités de certification tierces : https://support.microsoft.com/fr-fr/kb/281245