Considérations de sécurité et meilleures pratiques
Remarque :
Votre entreprise peut être tenue de satisfaire à certaines normes de sécurité pour remplir ses obligations réglementaires. Ce document ne traite pas de ce sujet, car ces normes de sécurité évoluent continuellement. Pour obtenir les informations les plus récentes sur les normes de sécurité et les produits Citrix, consultez http://www.citrix.com/security/.
Bonnes pratiques en matière de sécurité
Maintenez à jour toutes les machines de votre environnement avec des correctifs de sécurité. L’un des avantages est de pouvoir utiliser des clients légers comme terminaux, ce qui vous simplifie énormément la tâche.
Protégez toutes les machines de votre environnement avec un logiciel antivirus.
Envisagez d’utiliser un logiciel anti-programme malveillant spécifique à la plate-forme.
Lors de l’installation du logiciel, installez sur les chemins par défaut fournis.
- Si vous installez le logiciel dans un emplacement de fichiers autre que le chemin par défaut fourni, pensez à ajouter des mesures de sécurité supplémentaires, telles que des autorisations restreintes, à votre emplacement de fichiers.
Toutes les communications réseau doivent être correctement sécurisées et cryptées pour répondre à votre stratégie de sécurité. Vous pouvez sécuriser toutes les communications entre vos ordinateurs Microsoft Windows avec IPSec ; reportez-vous à la documentation de votre système d’exploitation pour plus d’informations à ce sujet. De plus, les communications entre les machines utilisateurs et les bureaux sont sécurisées via Citrix SecureICA, configuré par défaut sur un cryptage 128 bits. Vous pouvez configurer SecureICA lorsque vous créez ou mettez à jour un groupe de mise à disposition.
Remarque :
Citrix SecureICA fait partie du protocole ICA/HDX, mais n’est pas un protocole de sécurité réseau conforme aux normes comme TLS (Transport Layer Security). Vous pouvez également sécuriser les communications réseau entre les machines utilisateur et les postes de travail à l’aide de TLS. Pour configurer TLS, reportez-vous à la section TLS (Transport Layer Security).
Appliquez les recommandations Windows pour la gestion de comptes. Ne créez pas de compte sur un modèle ou une image avant sa duplication par Machine Creation Services ou Provisioning Services. Ne planifiez pas de tâches à l’aide de comptes de domaine privilégiés stockés. Ne créez pas manuellement de comptes de machines Active Directory partagés. Ces recommandations permettront d’éviter une attaque de machines par l’obtention des mots de passe de compte persistants locaux et leur utilisation pour se connecter à des images partagées MCS et PVS appartenant à d’autres utilisateurs.
Pare-feux
Protégez toutes les machines de votre environnement avec des pare-feu de périmètre, y compris aux limites des enclaves.
Toutes les machines de votre environnement devraient être protégées par un pare-feu personnel. Lorsque vous installez des composants principaux et des VDA (Virtual Delivery Agents), vous pouvez choisir que les ports requis pour le composant de la fonctionnalité de communication soient ouverts automatiquement si le service Pare-feu Windows est détecté (même si le pare-feu n’est pas activé). Vous pouvez également configurer ces ports de pare-feu manuellement. Si vous utilisez un autre pare-feu, vous devez le configurer manuellement.
Si vous faites migrer un environnement classique vers cette version, il peut être nécessaire de repositionner un pare-feu de périmètre existant ou d’en ajouter de nouveaux. Supposons, par exemple, qu’un pare-feu de périmètre soit positionné entre un client classique et un serveur de base de données dans le centre de données. Avec cette version, ce pare-feu de périmètre doit être positionné de façon telle que le bureau virtuel et la machine utilisateur se trouvent d’un côté du pare-feu, et les serveurs de bases de données et les Delivery Controller du centre de données de l’autre côté. Envisagez par conséquent de créer une enclave dans votre centre de données qui contiendra les serveurs de bases de données et les Controller. Il peut également être recommandé de mettre en place une protection entre la machine utilisateur et le bureau virtuel.
Remarque :
Les ports TCP 1494 et 2598 sont utilisés par les protocoles ICA et CGP. Ils sont donc susceptibles d’être ouverts afin que les utilisateurs se trouvant hors du centre de données puissent y accéder. Citrix vous recommande de ne pas utiliser ces ports à d’autres fins pour éviter tout risque d’attaque des interfaces d’administration. Les ports 1494 et 2598 sont officiellement enregistrés auprès de l’IANA (Internet Assigned Number Authority, voir http://www.iana.org/).
Sécurité des applications
Pour empêcher les actions malveillantes d’utilisateurs non administrateurs, nous vous recommandons de configurer les règles AppLocker Windows pour les programmes d’installation, les applications, les exécutables et les scripts sur l’hôte VDA et sur le client Windows local.
Gérer les privilèges utilisateur
Accordez aux utilisateurs uniquement les droits qui leur sont nécessaires. Les privilèges Microsoft Windows sont toujours appliqués aux bureaux de la manière habituelle : vous configurez les privilèges à l’aide de l’attribution des droits utilisateur et de l’appartenance aux groupes via la stratégie de groupe. L’un des avantages de cette version est qu’il est possible d’octroyer à un utilisateur des droits d’administration sur un bureau sans lui accorder le contrôle physique de l’ordinateur qui héberge ce bureau.
Veuillez noter ce qui suit lors de la planification des privilèges des bureaux :
- Par défaut, lorsque des utilisateurs non privilégiés se connectent à un bureau, ils voient le fuseau horaire du système exécutant le bureau au lieu de celui de leur propre machine utilisateur. Pour savoir comment autoriser les utilisateurs à voir leur heure locale lorsqu’ils utilisent des bureaux, veuillez consulter l’article Gérer les groupes de mise à disposition.
- Un utilisateur qui est administrateur d’un bureau dispose d’un contrôle total sur ce dernier. S’il s’agit d’un bureau regroupé et non d’un bureau dédié, tous les autres utilisateurs de ce bureau, y compris les utilisateurs futurs, doivent lui faire confiance. Tous les utilisateurs doivent être conscients que ce genre de situation peut représenter un risque potentiel permanent pour la sécurité de leurs données. Cette remarque ne s’applique pas aux bureaux dédiés, qui n’ont qu’un seul utilisateur ; celui-ci ne doit être l’administrateur d’aucun autre bureau.
- Un utilisateur qui est administrateur d’un bureau peut généralement installer des logiciels sur ce bureau, y compris des logiciels potentiellement malveillants. Il a aussi la possibilité de surveiller ou de contrôler le trafic sur tout réseau connecté au bureau.
Gérer les droits d’ouverture de session
Des droits d’ouverture de session sont requis pour les comptes d’utilisateur et les comptes d’ordinateur. À l’instar des privilèges Microsoft Windows, les droits d’ouverture de session sont toujours appliqués aux bureaux de la manière habituelle : vous configurez les droits d’ouverture de session à l’aide de l’attribution des droits utilisateur et de l’appartenance aux groupes via la stratégie de groupe.
Les droits d’ouverture de session Windows sont les suivants : ouverture de session locale, ouverture de session via les Services Bureau à distance, ouverture de session sur le réseau (accès à cet ordinateur depuis le réseau), ouverture de session en tant que traitement par lots et ouverture de session en tant que service.
Pour les comptes d’ordinateur, accordez aux ordinateurs uniquement les droits d’ouverture de session dont ils ont besoin. Le droit d’ouverture de session « Accéder à cet ordinateur à partir du réseau » est obligatoire :
- Sur les VDA, pour les comptes d’ordinateur des Delivery Controller.
- Sur les Delivery Controller, pour les comptes d’ordinateur des VDA. Voir Découverte de Controller basée sur unité d’organisation Active Directory.
- Sur les serveurs StoreFront, pour les comptes d’ordinateur des autres serveurs dans le même groupe de serveurs StoreFront.
Pour les comptes d’utilisateur, accordez aux utilisateurs uniquement les droits d’ouverture de session dont ils ont besoin.
Selon Microsoft, le droit d’ouverture de session « Autoriser l’ouverture de session par les services Bureau à distance » est accordé par défaut au groupe Utilisateurs du Bureau à distance (excepté sur les contrôleurs de domaine).
La stratégie de sécurité de votre organisation peut stipuler explicitement que ce groupe soit supprimé de ce droit d’ouverture de session. Considérez l’approche suivante :
- Le Virtual Delivery Agent (VDA) de l’OS multi-session utilise les Services Bureau à distance Microsoft. Vous pouvez configurer le groupe Utilisateurs du Bureau à distance en tant que groupe restreint, et contrôler l’appartenance au groupe via des stratégies de groupe Active Directory. Référez-vous à la documentation Microsoft pour plus d’informations.
- Pour les autres composants de Citrix Virtual Apps and Desktops, y compris le VDA pour OS mono-session, le groupe Utilisateurs du Bureau à distance n’est pas requis. Étant donné que le groupe Utilisateurs du Bureau à distance ne nécessite pas le droit d’ouverture de session « Autoriser l’ouverture de session au travers des services Bureau à distance » pour ces composants, vous pouvez le supprimer. Autres tâches :
- Si vous administrez ces ordinateurs via les Services Bureau à distance, assurez-vous que tous les administrateurs sont déjà membres du groupe Administrateurs.
- Si vous n’administrez pas ces ordinateurs via les Services Bureau à distance, vous pouvez désactiver les Services Bureau à distance sur ces ordinateurs.
Bien qu’il soit possible d’ajouter des utilisateurs et des groupes au droit d’ouverture de session « Interdire l’ouverture de session par les services Bureau à distance », l’interdiction de droits d’ouverture de session n’est généralement pas recommandée. Référez-vous à la documentation Microsoft pour plus d’informations.
Configurer les droits des utilisateurs
L’installation de Delivery Controller crée les services Windows suivants :
- Citrix AD Identity Service (NT SERVICE\CitrixADIdentityService Microsoft) : gère les comptes d’ordinateurs Active Directory pour les machines virtuelles.
- Citrix Analytics (NT SERVICE\CitrixAnalytics) : collecte des informations sur l’utilisation de la configuration du site, si cette collecte a été approuvée par l’administrateur du site. Ces informations sont ensuite envoyées à Citrix pour aider à améliorer le produit.
- Citrix App Library (NT SERVICE\CitrixAppLibrary) : prend en charge la gestion et le provisioning d’AppDisks, l’intégration d’AppDNA et la gestion d’App-V.
- Citrix Broker Service (NT SERVICE\CitrixBrokerService) : sélectionne les applications ou bureaux virtuels qui sont disponibles pour les utilisateurs.
- Citrix Configuration Logging Service (NT SERVICE\CitrixConfigurationLogging) : enregistre toutes les modifications de configuration et d’autres modifications apportées par les administrateurs du site.
- Citrix Configuration Service (NT SERVICE\CitrixConfigurationService) : référentiel à l’échelle du site pour la configuration partagée.
- Citrix Delegated Administration Service (NT SERVICE\CitrixDelegatedAdmin) : gère les autorisations accordées aux administrateurs.
- Citrix Environment Test Service (NT SERVICE\CitrixEnvTest) : gère les auto-tests des autres services Delivery Controller.
- Citrix Host Service (NT SERVICE\CitrixHostService) : stocke des informations sur les infrastructures d’hyperviseur utilisées dans un déploiement Citrix Virtual Apps ou Citrix Virtual Desktops, et offre également des fonctionnalités utilisées par la console pour énumérer les ressources dans un pool d’hyperviseurs.
- Citrix Machine Creation Services (NT SERVICE\CitrixMachineCreationService) : orchestre la création de machines virtuelles de bureau.
- Citrix Monitor Service (NT SERVICE\CitrixMonitor) : collecte des métriques pour Citrix Virtual Apps ou Citrix Virtual Desktops, stocke les données d’historique, et fournit une interface de requête pour la résolution des problèmes et les outils de reporting.
- Citrix Storefront Service (NT SERVICE\CitrixStorefront) : prend en charge la gestion de StoreFront. (Ne fait pas partie du composant StoreFront).
- Citrix Storefront Privileged Administration Service (NT SERVICE\CitrixPrivilegedService) : prend en charge les opérations d’administration privilégiée de StoreFront. (Ne fait pas partie du composant StoreFront).
- Citrix Config Synchronizer Service (NT SERVICE\CitrixConfigSyncService) : propage les données de configuration depuis la base de données du site principal vers le cache d’hôte local.
- Citrix High Availability Service (NT SERVICE\CitrixHighAvailabilityService) : sélectionne les applications ou bureaux virtuels qui sont disponibles pour les utilisateurs, lorsque la base de données du site principal n’est pas disponible.
L’installation de Delivery Controller crée également les services Windows suivants. Ces services sont également créés lorsqu’ils sont installés avec d’autres composants Citrix :
- Citrix Diagnostic Facility COM Server (NT SERVICE\CdfSvc) : prend en charge la collecte d’informations de diagnostic destinées au support technique de Citrix.
- Service de télémétrie Citrix (NT SERVICE\CitrixTelemetryService) : collecte des informations de diagnostic à des fins d’analyse par Citrix, de façon à ce que les résultats de l’analyse et les recommandations puissent être consultés par les administrateurs pour diagnostiquer les problèmes avec le site.
L’installation de Delivery Controller crée également le service Windows suivant. Il n’est pas utilisé pour le moment. S’il est activé, désactivez-le.
- Citrix Remote Broker Provider (NT SERVICE\XaXdCloudProxy)
L’installation de Delivery Controller crée également les services Windows suivants. Ces derniers ne sont pas utilisés actuellement, mais doivent être activés. Ne les désactivez pas.
- Citrix Orchestration Service (NT SERVICE\CitrixOrchestration)
- Citrix Trust Service (NT SERVICE\CitrixTrust)
À l’exception du service Citrix Storefront Privileged Administration Service, le droit d’ouverture de session Ouvrir une session en tant que service et les privilèges Ajuster les quotas de mémoire pour un processus, Générer des audits de sécurité et Remplacer un jeton de niveau processus sont accordés à ces services. Vous n’avez pas besoin de changer ces droits d’utilisateur. Ces privilèges ne sont pas utilisés par le Delivery Controller et sont automatiquement désactivés.
Configurer les paramètres du service
À l’exception du service Citrix StoreFront Privileged Administration Service et du Service de télémétrie Citrix, les services Windows Delivery Controller répertoriés ci-dessus dans la section Configurer les droits des utilisateurs sont configurés pour ouvrir une session sous l’identité NETWORK SERVICE. Ne modifiez pas ces paramètres de service.
Le service Citrix Config Synchronizer a besoin que le compte NETWORK SERVICE appartienne au groupe Administrateur local sur le Delivery Controller. Cela permet au cache d’hôte local de fonctionner correctement.
Le service Citrix StoreFront Privileged Administration Service est configuré pour ouvrir une session sous l’identité Système local (NT AUTHORITY\SYSTEM). Ceci est requis pour les opérations de Delivery Controller et de StoreFront qui ne sont normalement pas disponibles pour les services (y compris la création de sites IIS Microsoft). Ne modifiez pas ses paramètres de service.
Le Service de télémétrie Citrix est configuré pour ouvrir une session sous sa propre identité spécifique au service.
Vous pouvez désactiver le Service de télémétrie Citrix. Outre ce service, et les services qui sont déjà désactivés, ne désactivez aucun des autres services Windows Delivery Controller.
Configurer les paramètres de registre
Il n’est plus nécessaire d’activer la création de noms de fichiers et de dossiers au format 8.3 sur le système de fichiers du VDA. La clé de registre NtfsDisable8dot3NameCreation peut être configurée pour désactiver la création de noms de fichiers et de dossiers au format 8.3. Vous pouvez également configurer ce comportement à l’aide de la commande fsutil.exe behavior set disable8dot3.
Implications en termes de sécurité du scénario de déploiement
Votre environnement utilisateur peut se composer soit de machines utilisateur non gérées par votre entreprise et totalement sous le contrôle de l’utilisateur, soit de machines utilisateur gérées et administrées par votre entreprise. Les considérations de sécurité pour ces deux environnements sont généralement différentes.
Machines utilisateur gérées
Les machines utilisateur gérées font l’objet d’un contrôle administratif ; elles sont soit sous votre propre contrôle, soit sous celui d’une autre organisation à laquelle vous faites confiance. Vous pouvez configurer et fournir directement aux utilisateurs les machines utilisateur ; vous pouvez également fournir des terminaux sur lesquels un seul bureau s’exécute en mode plein écran seulement. Suivez les bonnes pratiques générales en matière de sécurité décrites ci-dessous pour toutes les machines utilisateur gérées. Cette version présente l’avantage de n’exiger qu’un minimum de logiciels sur une machine utilisateur.
Une machine utilisateur gérée peut être configurée pour être utilisée en mode plein écran seulement ou en mode fenêtre.
- Mode plein écran uniquement : les utilisateurs ouvrent une session sur celle-ci à partir de l’écran d’ouverture de session Windows habituel. Les mêmes informations d’identification de l’utilisateur sont alors utilisées pour ouvrir automatiquement une session sur cette version.
- Les utilisateurs voient leur bureau dans une fenêtre : les utilisateurs doivent d’abord ouvrir une session sur la machine utilisateur, puis sur cette version via le site Web fourni avec le produit.
Machines utilisateur non gérées
Les machines utilisateur qui ne sont pas gérées et administrées par une organisation de confiance ne peuvent pas être considérées comme des machines sous contrôle administratif. Vous pouvez, par exemple, autoriser les utilisateurs à se procurer et à configurer leurs propres machines, mais ceux-ci peuvent ne pas respecter les bonnes pratiques générales en matière de sécurité décrites ci-dessus. Cette version présente l’avantage de mettre, en toute sécurité, des bureaux à la disposition des machines utilisateur non gérées. Ces machines doivent tout de même disposer d’une protection antivirus de base capable d’arrêter les enregistreurs de frappes et les attaques similaires axées sur la saisie.
Considérations sur le stockage de données
Lorsque vous utilisez cette version, vous pouvez empêcher les utilisateurs de stocker des données sur les machines utilisateur qui sont sous leur contrôle physique. Toutefois, vous devez encore envisager les conséquences de l’enregistrement, par les utilisateurs, de données sur leurs bureaux. Enregistrer des données sur les bureaux n’est pas une bonne pratique ; celles-ci doivent être stockées sur des serveurs de fichiers, des serveurs de bases de données ou d’autres référentiels où elles feront l’objet d’une protection appropriée.
Votre environnement peut être composé de différents types de bureaux, tels que des bureaux regroupés ou dédiés. Les utilisateurs ne doivent jamais stocker de données sur des bureaux partagés, tels que les bureaux regroupés. S’ils stockent des données sur des bureaux dédiés, celles-ci doivent être supprimées si les bureaux sont ensuite mis à la disposition d’autres utilisateurs.
Environnements à versions mixtes
Les environnements à versions mixtes sont inévitables lors de certaines mises à niveau. Suivez les recommandations et réduisez la durée pendant laquelle les composants Citrix de versions différentes co-existent. Dans les environnements à versions mixtes, la stratégie de sécurité, par exemple, peut ne pas être appliquée de façon uniforme.
Remarque :
Ce comportement est caractéristique d’autres produits logiciels ; l’utilisation d’une version antérieure d’Active Directory n’applique que partiellement la stratégie de groupe avec les versions ultérieures de Windows.
Le scénario suivant décrit un problème de sécurité qui peut se produire dans un environnement Citrix à versions mixtes spécifique. Lorsque Citrix Receiver 1.7 est utilisé pour se connecter à un bureau virtuel exécutant le VDA dans XenApp et XenDesktop 7.6 Feature Pack 2, le paramètre de stratégie Autoriser le transfert de fichiers entre les bureaux et le client est activée dans le site, mais ne peut pas être désactivée par un Delivery Controller exécutant XenApp et XenDesktop 7.1. Il ne reconnaît pas le paramètre de stratégie, qui est disponible dans la version ultérieure du produit. Ce paramètre de stratégie permet aux utilisateurs de télécharger des fichiers sur leur bureau virtuel, ce qui cause le problème de sécurité. Pour contourner ce problème, mettez à niveau le Delivery Controller ou une instance autonome de Studio vers la version 7.6 Feature Pack 2, puis utilisez la stratégie de groupe pour désactiver le paramètre de stratégie. Vous pouvez également utiliser la stratégie locale sur tous les bureaux virtuels concernés.
Considérations de sécurité Remote PC Access
Remote PC Access implémente les fonctionnalités de sécurité suivantes :
- La carte à puce est prise en charge.
- Lorsqu’une session à distance se connecte, le moniteur du PC de bureau affiche un écran noir.
- Remote PC Access redirige toutes les entrées de claviers et de souris vers la session à distance, sauf la combinaison CTRL+ALT+SUPPR et les cartes à puce et les périphériques biométriques USB.
- SmoothRoaming est prise en charge uniquement pour un seul utilisateur.
- Lorsqu’un utilisateur a ouvert une session distante connectée à un PC de bureau, seul cet utilisateur peut reprendre l’accès local sur le PC de bureau. Pour reprendre l’accès local, l’utilisateur appuie sur Ctrl+Alt+Suppr sur le PC local et ouvre une session avec les mêmes informations d’identification utilisées par la session à distance. L’utilisateur peut également reprendre l’accès local en insérant une carte à puce ou en tirant parti de la biométrie, si votre système possède une intégration fournisseur des informations d’identification tierces appropriées. Ce comportement par défaut peut être substitué par l’activation de changement rapide d’utilisateur via des objets de stratégie de groupe (GPO) ou en modifiant le registre.
Remarque :
Citrix recommande de ne pas attribuer de privilèges d’administrateur VDA aux utilisateurs de sessions.
Assignations automatiques
Par défaut, Remote PC Access prend en charge l’assignation automatique de plusieurs utilisateurs à un VDA. Dans XenDesktop 5.6 Feature Pack 1, les administrateurs peuvent modifier ce comportement en utilisant le script PowerShell RemotePCAccess.ps1. Cette version utilise une entrée du Registre pour autoriser ou interdire plusieurs attributions de PC distants automatiques, ce paramètre s’applique à l’intégralité du site.
Attention :
Toute utilisation incorrecte de l’Éditeur du Registre peut générer des problèmes sérieux, pouvant vous obliger à réinstaller le système d’exploitation. Citrix ne peut garantir la possibilité de résoudre les problèmes provenant d’une mauvaise utilisation de Éditeur du Registre. Vous assumez l’ensemble des risques liés à l’utilisation de l’Éditeur du Registre. Veillez à faire une copie de sauvegarde de votre registre avant de le modifier.
Pour restreindre les attributions automatiques pour un utilisateur unique :
Sur chaque Controller du site, définissez la clé de registre suivante :
HKEY\_LOCAL\_MACHINE\Software\Citrix|DesktopServer
Name: AllowMultipleRemotePCAssignments
Type: REG_DWORD
Data: 0 = Disable multiple user assignment, 1 = (Default) Enable multiple user assignment.
S’il existe une ou plusieurs attributions d’utilisateur, supprimez-les à l’aide des commandes du kit de développement afin que le VDA puisse ensuite être admissible pour une seule attribution automatique.
- Supprimez tous les utilisateurs affectés à partir du VDA :
$machine.AssociatedUserNames | %{ Remove-BrokerUser-Name $_ -Machine $machine - Supprimez le VDA du groupe de distribution :
$machine | Remove-BrokerMachine -DesktopGroup $desktopGroup
Redémarrez le PC de bureau physique.
Approbation XML
Le paramètre d’approbation XML s’applique aux déploiements qui utilisent :
- un magasin StoreFront local ;
- une technologie d’authentification d’abonné (utilisateur) qui ne nécessite pas de mots de passe. Ces technologies sont par exemple des solutions de transfert de domaine, de cartes à puce, de SAML et de Veridium.
L’activation du paramètre d’approbation XML permet aux utilisateurs de s’authentifier avec succès, puis de démarrer les applications. Le Delivery Controller approuve les informations d’identification envoyées par StoreFront. Activez ce paramètre uniquement lorsque vous avez sécurisé les communications entre vos composants Delivery Controller et StoreFront à l’aide de clés de sécurité ou d’un autre mécanisme tel que des pare-feux ou IPsec.
Cette option est désactivée par défaut.
Utilisez le kit SDK Citrix Virtual Apps and Desktops PowerShell pour vérifier, activer ou désactiver le paramètre d’approbation XML.
- Pour vérifier la valeur actuelle du paramètre d’approbation XML, exécutez
Get-BrokerSiteet inspectez la valeur deTrustRequestsSentToTheXMLServicePort. - Pour activer l’approbation XML, exécutez
Set-BrokerSite -TrustRequestsSentToTheXmlServicePort $true. - Pour désactiver l’approbation XML, exécutez
Set-BrokerSite -TrustRequestsSentToTheXmlServicePort $false.
Dans cet article
- Bonnes pratiques en matière de sécurité
- Gérer les privilèges utilisateur
- Gérer les droits d’ouverture de session
- Configurer les droits des utilisateurs
- Configurer les paramètres du service
- Configurer les paramètres de registre
- Implications en termes de sécurité du scénario de déploiement
- Considérations de sécurité Remote PC Access
- Approbation XML