Utilisateur interactif
L’utilisateur interactif est l’utilisateur actuellement connecté à l’ordinateur sur lequel le serveur COM s’exécute. Si l’identité est définie pour être l’utilisateur interactif, tous les clients utilisent la même instance du serveur si le serveur inscrit sa fabrique de classes en tant que multi-usage. Si aucun utilisateur n’est connecté, le serveur ne s’exécutera pas. Si le serveur dispose d’une interface utilisateur graphique (GUI) que le client doit voir, vous devez utiliser l’utilisateur interactif pour l’identité du serveur. Toutefois, le choix de cette identité comporte certains risques de sécurité, car le serveur s’exécute sous l’identité de l’utilisateur connecté sans le consentement de l’utilisateur connecté. En outre, une application de service ne peut pas afficher d’interface utilisateur. Pour plus d’informations, consultez Services interactifs.
Si un serveur COM est configuré pour s’exécuter en tant qu’utilisateur interactif, dans un environnement de services terminal, le serveur est lancé dans la session interactive qui correspond à l’identité utilisateur du client. Toutefois, l’application cliente peut utiliser le moniker de session pour référencer un objet fourni par le serveur dans une session qui ne correspond pas à l’identité du client. Lorsqu’elle est utilisée, l’application cliente peut spécifier n’importe quelle session, auquel cas le serveur s’exécutera en tant qu’utilisateur propriétaire de la session, et non en tant qu’utilisateur de lancement. Les autorisations d’accès par défaut dans ce scénario ne permettent pas à l’utilisateur qui lance d’appeler des méthodes sur le serveur. Toutefois, les risques de sécurité suivants demeurent :
- Si le serveur COM expose des interfaces qui ne sont pas contrôlées par COM, telles que les ports TCP, les canaux nommés, les ports LPC, les sections de mémoire partagée, etc., elles peuvent être utilisées par l’utilisateur de lancement pour influencer le serveur. Les objets COM configurés pour s’exécuter en tant qu’utilisateur interactif doivent réduire autant que possible cette surface d’attaque.
- Les objets COM sont libres de définir leurs propres autorisations d’accès. Si l’objet définit des autorisations d’accès, soit dans son inscription AppID, soit en appelant CoInitializeSecurity, pour autoriser l’accès utilisateur de lancement, l’utilisateur peut lancer le serveur pour qu’il s’exécute en tant qu’autre utilisateur, puis accéder à l’objet.
Rubriques connexes