Problèmes connus
Les problèmes suivants ont été identifiés dans cette version :
-
Le service de cartes à puce divulgue des descripteurs de fichiers lors de l’authentification par carte à puce, bloquant ainsi l’accès aux nouvelles cartes à puce. Ce problème se produit, car la plupart des distributions Linux limitent par défaut le nombre maximum de fichiers ouverts à 1 024 pour chaque processus. Lorsque le service de carte à puce dépasse cette limite, il ne peut plus établir de nouvelles connexions, bloquant ainsi les accès ultérieurs par carte à puce.
Ce problème concerne les VDA dont l’ouverture de session par carte à puce est activée. Les symptômes incluent de nombreux échecs d’acceptation de la nouvelle connexion : trop d’erreurs d’ouverture de fichiers dans /var/log/xdl/hdx.log et une accumulation de descripteurs de fichiers dans /proc/${pid}/fd/, où ${pid} représente l’ID de processus de ctxscardsd. Pour déterminer le PID, utilisez la commande systemctl status ctxscardsd|grep PID.
Pour remédier à ce problème, vous pouvez soit augmenter la limite maximale de fichiers ouverts pour le service de carte à puce, soit redémarrer le service de carte à puce. Assurez-vous qu’aucune session n’est active avant de tenter de redémarrer le service. Utilisez les commandes suivantes pour augmenter la limite ou redémarrer le service :
-
Pour redémarrer le service de carte à puce :
systemctl restart ctxscardsd <!--NeedCopy--> -
Pour interroger le nombre maximum de fichiers ouverts par le service actuel :
cat /proc/${PID}/limits <!--NeedCopy--> -
Pour définir le nombre maximum de fichiers ouverts pour le service de carte à puce :
-
Ouvrez le fichier ctxscardsd.service en mode lecture seule pour vérifier les paramètres actuels :
vim -R /lib/systemd/system/ctxscardsd.service <!--NeedCopy--> -
Ajoutez la ligne suivante à la section Service de ctxscardsd.service pour augmenter la limite :
LimitNOFILE=65536 <!--NeedCopy--> -
Rechargez le démon systemd et redémarrez le service ctxscardsd :
systemctl daemon-reload systemctl restart ctxscardsd <!--NeedCopy--> -
Vérifiez la nouvelle limite :
cat /proc/${PID}/limits <!--NeedCopy-->
-
Remarque :
L’augmentation du nombre maximum de fichiers ouverts peut prolonger le délai avant d’épuiser les descripteurs de fichiers, mais un redémarrage de ctxscardsd peut s’avérer nécessaire à terme.
[LNXVDA-17784]
-
-
Si vous ne spécifiez pas la variable CTX_XDL_DESKTOP _ENVIRONMENT, il n’est pas possible de savoir quel bureau sera utilisé lors du processus suivant. Par conséquent, les variables d’environnement liées au bureau ne sont pas configurées et les applications ou plug-ins qui dépendent de ces variables peuvent ne pas fonctionner comme prévu. [LNXVDA-16212]
-
En raison d’un problème lié à GNOME, le Linux VDA ne fonctionne pas comme prévu après la mise à niveau de samba-winbind vers la version 4.18.6 sur RHEL 8.X, Rocky Linux 8.x, RHEL 9.x et Rocky Linux 9.x. Pour plus d’informations, consultez https://issues.redhat.com/browse/RHEL-17122.
-
Les échecs de lancement de session se produisent lorsque le nombre maximum de connexions défini dans PostgreSQL est insuffisant pour gérer des sessions simultanées. Pour résoudre ce problème, augmentez le nombre maximum de connexions en modifiant le paramètre max_connections dans le fichier postgresql.conf.
-
L’enregistrement du VDA peut échouer en raison de l’exception LDAP suivante générée dans le fichier /var/log/xdl/jproxy.log :
javax.naming.NamingException: LDAP response read timed out, timeout used: 10000 ms. <!--NeedCopy-->Pour contourner le problème, procédez comme suit :
-
Modifiez la valeur du délai d’expiration LDAP. Par exemple, modifiez la valeur du délai d’expiration LDAP à 60s à l’aide de la commande suivante :
ctxreg create -k "HKLM\Software\Citrix\GroupPolicy\Defaults" -t "REG_DWORD" -v "LDAPTimeout" -d "0x000EA60" --force <!--NeedCopy--> -
Accélérez les requêtes LDAP en définissant une base de recherche. Vous pouvez définir une base de recherche à l’aide de la variable CTX_XDL_SEARCH_BASE dans le fichier ctxsetup.sh ou à l’aide de la commande suivante :
ctxreg create -k "HKLM\Software\Citrix\VirtualDesktopAgent" -t "REG_SZ" -v "LDAPComputerSearchBase" -d "<specify a search base instead of the root of the domain to improve search performance>" --force <!--NeedCopy-->
[CVADHELP-20895]
-
-
Microsoft a publié les mises à jour cumulatives KB5019966 et KB5019964 pour Windows 10 en novembre 2022. Les mises à jour introduisent des échecs lors de la jonction et de l’enregistrement de domaines. Pour contourner ce problème, consultez l’article CTX474888du centre de connaissances.
-
Le type de cryptage RC4_HMAC_MD5 étant autorisé pour Kerberos, le Linux VDA peut ne pas s’enregistrer auprès du Controller et le message d’erreur suivant s’affiche :
Error: Failure unspecified at GSS-API level (Mechanism level: Encryption type RC4 with HMAC is not supported/enabled)
Pour contourner ce problème, désactivez RC4_HMAC_MD5 de manière globale dans votre domaine Active Directory (ou de façon plus spécifique sur une unité d’organisation) ou autorisez les types de chiffrement faibles sur le Linux VDA. Ensuite, effacez les tickets Kerberos mis en cache sur le Controller et le Citrix Cloud Connector à l’aide de la commande klist -li 0x3e4 purge et redémarrez le Linux VDA.
Pour désactiver RC4_HMAC_MD5 de manière globale dans votre domaine Active Directory, procédez comme suit :
- Ouvrez la Console de gestion des stratégies de groupe.
- Localisez le domaine cible, puis sélectionnez la stratégie de domaine par défaut.
- Cliquez avec le bouton droit sur Stratégie de domaine par défaut et sélectionnez Modifier. L’éditeur de gestion des stratégies de groupe s’ouvre.
- Sélectionnez Configuration ordinateur > Stratégies > Paramètres Windows > Paramètres de sécurité > Stratégies locales > Options de sécurité.
- Double-cliquez sur Sécurité réseau : Configurer les types de chiffrement autorisés pour Kerberos.
- Décochez les cases DES_CBC_CRC, DES_CBC_MD5 et RC4_HMAC_MD5 et sélectionnez AES128_HMAC_SHA1, AES256_HMAC_SHA1 et Futurs types de chiffrement.
Pour autoriser les types de chiffrement faibles sur le Linux VDA, procédez comme suit :
Remarque :
Les types de chiffrement faibles rendent votre déploiement vulnérable aux attaques.
- Ouvrez le fichier /etc/krb5.conf sur le Linux VDA.
-
Ajoutez l’entrée suivante dans la section [libdefaults] :
allow_weak_crypto= TRUE
-
Le Linux VDA ne prend pas en charge SecureICA pour le chiffrement. L’activation de SecureICA sur le Linux VDA provoque l’échec du lancement de la session.
-
Dans une session de bureau GNOME, les tentatives de modification de la disposition du clavier peuvent échouer. [CVADHELP-15639]
-
Graphiques Ubuntu : dans HDX 3D Pro, un cadre noir peut apparaître autour des applications après le redimensionnement de Desktop Viewer, ou dans certains cas, l’arrière-plan peut s’afficher en noir.
-
Il est possible que les imprimantes créées par la redirection d’impression de Linux VDA ne puissent pas être supprimées après la fermeture d’une session.
-
Les fichiers CDM sont absents lorsqu’un répertoire contient de nombreux fichiers et sous-répertoires. Ce problème peut se produire si le client a trop de fichiers ou de répertoires.
-
Dans cette version, seul le codage UTF-8 est pris en charge pour les langues autres que l’anglais.
-
L’état du verrouillage des majuscules de l’application Citrix Workspace pour Android peut être inversé lors de l’itinérance de session. L’état de CAPS VERR peut être perdu lors de l’itinérance d’une connexion existante à l’application Citrix Workspace pour Android. Pour résoudre le problème, utilisez la touche MAJ sur le clavier étendu pour basculer entre les majuscules et les minuscules.
-
Les raccourcis ALT ne fonctionnent pas toujours lors d’une connexion à un Linux VDA à l’aide de l’application Citrix Workspace pour Mac. L’application Citrix Workspace pour Mac envoie AltGr pour les touches Options/Alt droite et gauche par défaut. Vous pouvez modifier ce comportement dans les paramètres de l’application Citrix Workspace, mais les résultats varient selon les applications .
-
L’enregistrement échoue lorsque le Linux VDA est à nouveau associé au domaine. Cette nouvelle association génère un nouvel ensemble de clés Kerberos. Le broker peut utiliser un ticket de service VDA mis en cache obsolète basé sur le jeu de clés Kerberos précédent. Lorsque le VDA tente de se connecter au broker, le broker peut ne pas être en mesure d’établir un contexte de sécurité pour le VDA. Le symptôme courant est l’échec de l’enregistrement du VDA.
Ce problème se résout de lui-même lorsque le ticket de service VDA expire, puis est renouvelé. Cependant, les tickets de service ayant en général une durée de vie assez longue, ce processus peut prendre beaucoup de temps.
Pour résoudre le problème, effacez le cache de ticket du Broker. Redémarrez le broker ou exécutez la commande suivante en tant qu’administrateur sur le broker à partir d’une invite de commande :
klist -li 0x3e4 purge <!--NeedCopy-->Cette commande supprime tous les tickets de service du cache LSA détenu par le service réseau principal sous lequel le service de broker Citrix s’exécute. Elle supprime également les tickets de service pour d’autres VDA et, potentiellement, d’autres services. Cela ne pose pas de problème : ces tickets de service peuvent être de nouveau acquis depuis le serveur KDC le cas échéant.
-
Audio Plug-n-Play n’est pas pris en charge. Vous pouvez connecter un périphérique de capture audio à la machine cliente avant de commencer à enregistrer l’audio dans la session ICA. Si un périphérique de capture est connecté après que l’application d’enregistrement audio a démarré, l’application peut cesser de répondre et vous devez la redémarrer. Un problème similaire peut se produire si un périphérique de capture est déconnecté pendant l’enregistrement.
-
L’application Citrix Workspace pour Windows peut rencontrer une distorsion audio lors de l’enregistrement audio.