Federated Authentication Service

Résoudre les problèmes d’ouverture de session Windows

April 3, 2023

Contributeur:

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).

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

Journaux du contrôleur de domaine et de la station de travail

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é Virtual Delivery Agent (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

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

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

Tous les événements de FAS sont consignés dans le journal des événements de l’application Windows. Vous pouvez utiliser des produits tels que System Center Operations Manager (SCOM) pour surveiller l’intégrité 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.

Seuls les événements les plus importants liés à la surveillance du service FAS sont décrits dans cette section. Pour obtenir la liste complète des codes d’événement de FAS, reportez-vous à la section Journaux des événements de FAS.

Événements d’intégrité de FAS

Les événements suivants indiquent si votre service FAS fonctionne correctement.

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

Événement	Texte de l’événement	Explication	Remarques
[S003]	Administrator [{0}] setting Maintenance Mode to [{1}]	Le service FAS a été placé en mode de maintenance ou retiré de celui-ci.	En mode de maintenance, le serveur FAS n’est pas utilisable pour l’authentification unique.
[S022]	Administrator [{0}] setting Maintenance Mode to Off	Le service FAS a été retiré du mode de maintenance.	Disponible à partir de FAS 10.7/CVAD 2109.
[S023]	Administrator [{0}] setting Maintenance Mode to On	Le service FAS a été placé en mode de maintenance.	Disponible à partir de FAS 10.7/CVAD 2109.
[S123]	Failed to issue a certificate for [upn: {0} role: {1}] [exception: {2}]	Cet événement se produit après [S124] si aucune des autorités de certification de FAS n’est configurée avec un certificat utilisateur émis avec succès. L’authentification unique échouera pour cet utilisateur.	Cet événement peut indiquer qu’aucune des autorités de certification configurées ne fonctionne. Si FAS est configuré pour utiliser un HSM, cela peut également indiquer que le HSM ne fonctionne pas.
[S124]	Failed to issue a certificate for [upn: {0} role: {1}] at [certifcate authority: {2}] [exception: {3}]	Un échec s’est produit lorsque FAS a tenté de demander un certificat utilisateur auprès de l’autorité de certification donnée. Si FAS est configuré avec plus d’une autorité de certification, FAS effectuera une nouvelle demande auprès d’une autre autorité de certification.	Cet événement peut indiquer que l’autorité de certification ne fonctionne pas ou n’est pas joignable. Si FAS est configuré pour utiliser un HSM, cela peut également indiquer que le HSM ne fonctionne pas. L’exception peut être utilisée pour identifier la cause du problème.
[S413]	Authorization certificate expiring soon ({0} days left). Certificate details: {1}	Cet événement est généré périodiquement lorsque le certificat d’autorisation de FAS est sur le point d’expirer. Par défaut, l’événement est généré tous les jours si le certificat d’autorisation entre dans les 30 jours suivant l’expiration.	Les paramètres par défaut peuvent être ajustés à l’aide de l’applet de commande Set-FasRaCertificateMonitor ; voir Applets de commande PowerShell.
[S414]	Authorization certificate has expired. Certificate details: {0}	Cet événement est généré périodiquement lorsque le certificat d’autorisation de FAS a expiré. Par défaut, l’événement est généré tous les jours.	Une fois expiré, FAS ne peut pas générer de nouveaux certificats utilisateur et l’authentification unique commence à échouer.

Événements FAS connectés au cloud

Si vous utilisez FAS en conjonction avec Citrix Cloud, les événements suivants indiquent si votre service FAS fonctionne correctement.

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

Événement	Texte de l’événement	Explication	Remarques
[S012]	The FAS service is available for single sign-on from Citrix Cloud	Cet événement indique que l’authentification unique devrait fonctionner depuis Workspace (c’est-à-dire Citrix Cloud).	Avant d’émettre cet événement, FAS vérifie (1) qu’il est configuré, (2) qu’il n’est pas en mode de maintenance et (3) qu’il est connecté à Citrix Cloud.
[S013]	The FAS service is not available for single sign-on from Citrix Cloud. [{0}] Further details can be found in the admin console.	Cet événement indique que FAS n’est pas en mesure de fournir l’authentification unique à partir de Workspace (c’est-à-dire Citrix Cloud). Le message indique la raison pour laquelle l’authentification unique ne fonctionne pas.	FAS maintient une connexion permanente à Citrix Cloud. De temps en temps, cette connexion peut prendre fin pour diverses raisons (par exemple, un problème réseau ou une stratégie de durée de vie de connexion sur un serveur proxy). Lorsque cela se produit, le texte de l’événement contient « Service is not connected to the cloud ». Ce comportement est normal et FAS tente immédiatement de rétablir une connexion à Citrix Cloud.

Événements de sécurité

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

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

Événement	Texte de l’événement	Explication
[S001]	ACCESS DENIED: User [{0}] is not a member of Administrators group	Une tentative d’affichage ou de modification de la configuration de FAS a été effectuée, mais l’appelant n’était pas un administrateur FAS.
[S002]	ACCESS DENIED: User [{0}] is not an Administrator of Role [{1}]	Une tentative d’affichage ou de modification de la configuration d’une règle de FAS a été effectuée, mais l’appelant n’était pas un administrateur FAS.
[S101]	Server [{0}] is not authorized to assert identities in role [{1}]	Une tentative a été faite pour affirmer l’identité des utilisateurs, mais l’appelant n’est pas autorisé à effectuer une telle opération. Seuls les serveurs StoreFront qui y ont été autorisés dans la configuration de la règle FAS (et Workspace le cas échéant) peuvent affirmer des identités utilisateur.
[S104]	Server [{0}] failed to assert UPN [{1}] (UPN not allowed by role [{2}])	Une tentative a été faite pour affirmer l’identité d’un utilisateur, mais le compte de l’utilisateur n’y est pas autorisé conformément à la configuration de la règle FAS.
[S205]	Relying party access denied - the calling account [{0}] is not a permitted relying party of the rule [{1}]	Un VDA a tenté d’effectuer une authentification unique avec FAS, mais le VDA n’y est pas autorisé conformément à la configuration de la règle FAS.