N'ayant pas accès à Windows à la source, il est difficile de dire quoi que ce soit qui ne soit pas de la spéculation. Mis à part cet avertissement, voici ce que j'ai pu glaner en lisant ceci:
UAC crée deux jetons de sécurité à l'ouverture de session: le jeton élevé contenant les appartenances de groupe complet de l'utilisateur et le jeton restreint dont l'appartenance au groupe "Administrateurs" est supprimée. Chaque jeton contient un ID local unique (LUID) distinct qui identifie la session d'ouverture de session. Il s'agit de deux sessions de connexion distinctes et distinctes.
À partir de Windows 2000 Server SP2, les lecteurs mappés (qui sont représentés sous forme de liens symboliques dans l'espace de noms du gestionnaire d'objets) sont marqués avec le LUID du jeton qui les a créés (vous pouvez trouver des références Microsoft à ce comportement dans cet article KBase , et vous pouvez en savoir plus sur les mécanismes de la fonctionnalité dans cet article de blog ). L'essentiel de la fonctionnalité est que les lecteurs mappés créés par une session de connexion ne sont pas accessibles à une autre session de connexion.
La définition de la valeur EnableLinkedConnections déclenche un comportement dans le service LanmanWorkstation et le sous-système de sécurité LSA (LSASS.EXE) pour obliger LSA à copier les lecteurs mappés par l'un des jetons des utilisateurs dans le contexte de l'autre jeton. Cela permet aux lecteurs mappés avec le jeton élevé d'être visibles par le jeton restreint et l'inverse. Il n'y a aucune particularité du comportement de cette fonctionnalité avec le respect d'un environnement de domaine par rapport à un environnement non-domaine. Si vos utilisateurs s'exécutent avec des comptes "Administrateur" dans un environnement hors domaine, leurs jetons restreints et leurs jetons élevés, par défaut, auront des mappages de lecteurs indépendants.
En termes de vulnérabilité, la documentation officielle de Microsoft semble faire défaut. J'ai trouvé un commentaire et une réponse d'un employé de Microsoft posant des questions sur les vulnérabilités potentielles dans une conversation sur l'UAC de 2007. Étant donné que la réponse vient de Jon Schwartz, qui, à l'époque, était intitulé "UAC Architect", je ont tendance à considérer sa réponse comme crédible. Voici l'essentiel de sa réponse à l'enquête suivante: "... Je n'ai trouvé aucune information pour décrire ce qui se passe réellement techniquement ou si cela ouvre une sorte de failles UAC. Pouvez-vous commenter?"
Techniquement, cela ouvre une petite faille, car les logiciels malveillants non élevés peuvent désormais "pré-amorcer" une lettre de lecteur + un mappage dans le contexte élevé - cela devrait être à faible risque, sauf si vous vous retrouvez avec quelque chose qui est spécifiquement adapté à votre environnement.
Personnellement, je ne peux pas penser à un moyen "d'exploiter" cette échappatoire, dans la mesure où "amorcer" le jeton élevé avec un mappage de lecteur nécessiterait toujours que l'utilisateur élève et exécute quelque chose de malveillant à partir de ce mappage de lecteur "prédéfini". Je ne suis pas un chercheur en sécurité, cependant, et je ne m'approche peut-être pas de cela avec un bon état d'esprit pour trouver des exploits potentiels.
J'ai esquivé à l'aide de la valeur EnableLinkedConnections dans mes sites clients en poursuivant la tendance que nous avons commencée lorsque les clients ont commencé à déployer Windows NT 4.0 - les utilisateurs se connectant avec des comptes d'utilisateurs limités. Cela a bien fonctionné pour nous pendant des années et continue de bien fonctionner dans Windows 7.