Résoudre les 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 ou de cartes à puce, ou des deux. 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 des 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) .

• 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 (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 d’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. Un seul domaine peut avoir plusieurs adresses FQDN enregistrées dans le RootDSE.

De plus, chaque utilisateur d’Active Directory possède un UPN explicite et des altUserPrincipalNames. Ce sont des entrées LDAP qui spécifient l’UPN de 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 correspondance, 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 situé sur une machine de catalogue global et dispose d’une vue mise 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 quel contrôleur de domaine est 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 existe 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. 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 ce faire, 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. Pour ouvrir l’éditeur de stratégie de groupe, exécutez gpedit.msc sur le contrôleur de domaine. Une fois les stratégies d’audit activées, le contrôleur de domaine produit des informations de journal d’événements supplémentaires dans le 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.

• Sur le contrôleur de domaine et la machine VDA, ouvrez l’Observateur d’événements et accédez à Journaux des applications et des services > Microsoft > Windows > CAPI2 > Opérationnel. Cliquez avec le bouton droit sur Opérationnel et sélectionnez Activer le journal.

• De plus, affinez la journalisation CAPI avec les valeurs de registre à l’emplacement suivant : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\crypt32. Les valeurs suivantes n’existent pas par défaut. Vous devez les créer. Supprimez les valeurs si vous souhaitez rétablir les paramètres de journalisation CAPI2 par défaut.

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 :

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

• Les messages tels que certificat non approuvé doivent ê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

Journaux du contrôleur de domaine et du poste de travail

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 connexion, 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 indique que lsass.exe sur le contrôleur de domaine construit une chaîne basée sur le certificat fourni par le VDA et la vérifie 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 tickets 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

Les journaux d’audit de sécurité du VDA correspondant à l’événement d’ouverture de session sont 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 l’ouverture de session Windows indiquant que l’ouverture de session Kerberos a réussi.

Surveillance de FAS à l’aide du journal des événements Windows

Tous les événements FAS sont écrits dans le journal des événements d’application de Windows. Vous pouvez utiliser des produits tels que System Center Operations Manager (SCOM) pour surveiller l’état de votre service FAS à l’aide des processus et des événements décrits ici.

Le service FAS est-il en cours d’exécution ?

Pour déterminer si le service FAS est en cours d’exécution, surveillez le processus Citrix.Authentication.FederatedAuthenticationService.exe.

Cette section décrit uniquement les événements les plus importants pour la surveillance du service FAS. Pour la liste complète des codes d’événement FAS, consultez Journaux d’événements FAS.

Événements d’intégrité FAS

Les événements suivants indiquent si votre service FAS est sain.

La source de l’événement est Citrix.Authentication.FederatedAuthenticationService.

Événements FAS connectés au cloud

Si vous utilisez FAS avec Citrix Cloud™, les événements suivants indiquent si votre service FAS est sain.

La source de l’événement est Citrix.Fas.Cloud.

Événements de sécurité

Les événements suivants indiquent qu’une entité non autorisée a tenté d’utiliser FAS.

La source de l’événement est Citrix.Authentication.FederatedAuthenticationService.

Journaux d’événements FAS

Les tableaux suivants répertorient les entrées du journal des événements générées par FAS.

Événements d’administration [Federated Authentication Service]

[Source de l’événement : Citrix.Authentication.FederatedAuthenticationService]

Ces événements sont enregistrés en réponse à une modification de configuration sur le serveur FAS.

Création d’assertions d’identité [Service d’authentification fédérée]

[Source de l’événement : Citrix.Authentication.FederatedAuthenticationService]

Ces événements sont enregistrés lors de l’exécution sur le serveur FAS lorsqu’un serveur approuvé affirme une connexion utilisateur.

Agir en tant que partie de confiance [Service d’authentification fédérée]

[Source de l’événement : Citrix.Authentication.FederatedAuthenticationService]

Ces événements sont enregistrés lors de l’exécution sur le serveur FAS lorsqu’un VDA connecte un utilisateur.

Serveur de certificats de session [Federated Authentication Service]

[Source de l’événement : Citrix.Authentication.FederatedAuthenticationService]

Ces événements sont enregistrés sur le serveur FAS lorsqu’un utilisateur utilise un certificat de session.

• Codes de journal

• [S301] Accès refusé : L’utilisateur [{0}] n’a pas accès à une carte à puce virtuelle.

  [S302] L’utilisateur [{0}] a demandé une carte à puce virtuelle inconnue [empreinte : {1}].

  [S303] Accès refusé : L’utilisateur [{0}] ne correspond pas à la carte à puce virtuelle [upn : {1}].

  [S304] L’utilisateur [{0}] exécute le programme [{1}] sur l’ordinateur [{2}] à l’aide de la carte à puce virtuelle [upn : {3} rôle : {4} empreinte : {5}] pour l’opération de clé privée [{6}].

  [S305] L’opération de clé privée a échoué [Opération : {0}] [upn : {1} rôle : {2} containerName {3} Erreur {4} {5}].

Plug-in d’assertion FAS [Federated Authentication Service]

• [Source de l’événement : Citrix.Authentication.FederatedAuthenticationService]

• Ces événements sont enregistrés par le plug-in d’assertion FAS.

• Codes de journalisation
  [S500] Aucun plug-in d’assertion FAS n’est configuré
  [S501] Le plug-in d’assertion FAS configuré n’a pas pu être chargé [exception:{0}]
  [S502] Plug-in d’assertion FAS chargé [pluginId={0}] [assembly={1}] [location={2}]
  [S503] Le serveur [{0}] n’a pas pu affirmer l’UPN [{1}] (des preuves d’ouverture de session ont été fournies, mais le plug-in [{2}] ne les prend pas en charge)
  [S504] Le serveur [{0}] n’a pas pu affirmer l’UPN [{1}] (des preuves d’ouverture de session ont été fournies, mais aucun plug-in FAS n’est configuré)
  [S505] Le serveur [{0}] n’a pas pu affirmer l’UPN [{1}] (le plug-in [{2}] a rejeté les preuves d’ouverture de session avec le statut [{3}] et le message [{4}])
  [S506] Le plug-in [{0}] a accepté les preuves d’ouverture de session du serveur [{1}] pour l’UPN [{2}] avec le message [{3}]
  [S507] Le serveur [{0}] n’a pas pu affirmer l’UPN [{1}] (le plug-in [{2}] a levé l’exception [{3}] pendant la méthode [{4}])
  [S507] Le serveur [{0}] n’a pas pu affirmer l’UPN [{1}] (le plug-in [{2}] a levé l’exception [{3}])
  [S508] Le serveur [{0}] n’a pas pu affirmer l’UPN [{1}] (une disposition d’accès a été fournie, mais le plug-in [{2}] ne la prend pas en charge)
  [S509] Le serveur [{0}] n’a pas pu affirmer l’UPN [{1}] (une disposition d’accès a été fournie, mais aucun plug-in FAS n’est configuré)
  [S510] Le serveur [{0}] n’a pas pu affirmer l’UPN [{1}] (la disposition d’accès a été considérée comme invalide par le plug-in [{2}])

FAS [Federated Authentication Service] activé pour Workspace

[Source d’événement : Citrix.Fas.Cloud]

Ces événements sont enregistrés lorsque FAS est utilisé avec Workspace.

Ouverture de session [VDA]

[Source d’événement : Citrix.Authentication.IdentityAssertion]

Ces événements sont enregistrés sur le VDA pendant la phase d’ouverture de session.

Certificats en session [VDA]

[Source d’événement : Citrix.Authentication.IdentityAssertion]

Ces événements sont enregistrés sur le VDA lorsqu’un utilisateur tente d’utiliser un certificat en session.

Demande de certificat et génération de paires de clés [Federated Authentication Service]

[Source d’événement : Citrix.Fas.PkiCore]

Ces événements sont enregistrés lorsque le serveur FAS effectue des opérations cryptographiques de bas niveau.

Messages d’erreur de l’utilisateur final

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

Traçage permanent FAS

Avec le traçage permanent, FAS enregistre son activité dans le système de fichiers. Cela peut aider au dépannage, éliminant potentiellement la nécessité de reproduire un incident qui s’est produit.

Le traçage permanent est activé lorsque vous installez ou mettez à niveau FAS à l’aide de l’une de ces méthodes :

• L’installeur Citrix Virtual Apps and Desktops™ : à partir du bouton Federated Authentication Service sur l’écran de démarrage automatique lorsque l’ISO est insérée
• XenDesktopFasSetup.exe : Situé sur l’ISO Citrix Virtual Apps and Desktops à x64\XenDesktop Setup\XenDesktopFasSetup.exe
• FasSetup_xxxx.exe : le fichier d’installation autonome de FAS, disponible sur Téléchargements Citrix.

Remarque :

Le traçage permanent n’est pas disponible si vous installez ou mettez à niveau à l’aide du fichier MSI d’installation de FAS, FederatedAuthenticationService_x64.msi.

Collecte du traçage permanent

Utilisez Citrix Scout pour collecter le traçage permanent et d’autres données de diagnostic de votre serveur FAS. Citrix Scout est installé lorsque vous installez FAS à l’aide de l’une des méthodes précédentes.

Désactivation du traçage permanent

Si, pour une raison quelconque, vous souhaitez désactiver le traçage permanent, arrêtez et désactivez le service de télémétrie Citrix sur votre serveur FAS.

Informations connexes

• Configuration d’un domaine pour la connexion par carte à puce
• Stratégies de connexion par carte à puce
• Activation de la journalisation CAPI
• Activation de la journalisation Kerberos
• Directives pour l’activation de la connexion par carte à puce avec des autorités de certification tierces