Note: the base problem for me is to be able to access a network share that I (Win 7 admin user) have set up when I run an elevated program. Normally the elevated program will not have access to my non-elevated network shares.

According to Microsoft the registry setting EnableLinkedConnections will allow elevated processes to access the network share of the currently logged in (non-elevated) explorer process.

This explanation makes some sense:

[...] When you’re a member of the Administrators group and you log in, your account is busted down to a non-privileged user by UAC. This running context is completely separate from the context you get when you right-click Command Prompt and launch as an administrator. As you’ll probably have noticed, network drives connected in one context are not visible in the other. [...]

This forum thread asks about the vulnerabilities opened by this setting. The answer given links to an article about disabling UAC prompts (or so I understand).

The question now is, what does the registry setting EnableLinkedConnections do or allow on a Windows 7 system, given that we are not running in a domain environment.

Edit: One thing that I'm specifically interested in is whether this setting only affects the (visibility of) network drives or whether it has any other implications.


3 Answers 3


Not having source access to Windows it's difficult to say anything that isn't speculation. That disclaimer aside, here's what I've been able to glean by reading up on this:

UAC creates two security tokens on logon: the elevated token containing the user's full group memberships, and the restricted token which has membership of the "Administrators" group stripped out. Each token contains a distinct locally unique ID (LUID) that identifies the logon session. They are two separate and distinct logon sessions.

Starting in Windows 2000 Server SP2, mapped drives (which are represented as symlinks in the object manager namespace) are tagged with the LUID of the token that created them (you can find some Microsoft references to this behavior in this KBase article, and you can learn more about the mechanics of the feature in this blog posting). The gist of the feature is that mapped drives created by one logon session are not accessible to another logon session.

Setting the EnableLinkedConnections value triggers a behaviour in the LanmanWorkstation service and the LSA security subsystem (LSASS.EXE) to cause LSA to copy drives mapped from by either one of the users' tokens into the context of the other token. This allows drives mapped with the elevated token to be visible to the restricted token and the converse. There isn't any peculiarity of the behavior of this feature w/ respect to a domain versus non-domain environment. If your users are running with "Administrator" accounts in a non-domain environment their restricted tokens and elevated tokens, by default, will have independent drive mappings.

In terms of vulnerabilty, official documentation from Microsoft seems to be lacking. I did find a comment and a response from a Microsoft employee asking about the potential vulnerabilities in a conversation about UAC from 2007. Given that the answer comes from Jon Schwartz, who, at the time, was titled "UAC Architect", I'd tend to consider his answer having credibility. Here's the gist of his answer to the following inquiry: "...I have not found any information to describe what is actually happening technically or if this opens any kind of UAC loopholes. Can you comment?"

Technically, it opens a small loophole since non-elevated malware can now "pre-seed" a drive letter + mapping into the elevated context -- that should be low-risk unless you end up with something that's specifically tailored to your environment.

Personally, I can't think of a way to "exploit" this loophole, insofar as "seeding" the elevated token with a drive mapping would still require the user to actually elevate and execute something malicious from that "seeded" drive mapping. I'm not a security researcher, though, and I may not be approaching this with a good mind-set to come up with potential exploits.

I've dodged using the EnableLinkedConnections value in my Customer sites by continuing the trend that we began when Customers started deploying Windows NT 4.0-- having users logon with limited user accounts. That's worked well for us for years and continues to work well in Windows 7.

  • RE: "I've dodged using the EnableLinkedConnections value ... [by] having users logon with limited user accounts." -- can limited user accounts run applications as administrator? I thought they couldn't. (If they can't then I don't see how this dodges the issue -- I mean, if I complained to a mechanic that my car's engine squeals when I'm driving 80 mph, I wouldn't accept the fix of him flattening my tires [while it would make it impossible to drive 80 mph, it would not fix the actual problem].) May 16, 2013 at 22:36
  • 1
    @BrainSlugs83 - You're fixating on a comment in a tiny paragraph of a long answer. The answer gave the OP what they wanted (I assume, since they accepted): a description of what the registry value does. I made that offhand comment to tell the OP that there is a way to avoid needing to use EnableLinkedConnections-- just don't give users Administrator accounts and the need is alleviated. It's 2013-- limited user accounts have been the advice of Microsoft for almost 10 years. Your car/mechanic analogy is strained, IMO. This isn't an "issue" with the operating system-- it's a security feature. May 17, 2013 at 0:42
  • Oh, I am absolutely fixating; also in case there was any confusion: I'm not arguing your answer is incorrect. It was very good, I even upvoted it! -- But I am fixating on a very real problem that I'm having -- hence, the question I posed to you to determine if this alternate solution will work for me or not: "can limited user accounts run applications as administrator?"; I take it from your reply that my initial assumption was correct. Jun 4, 2013 at 21:17
  • Also, I strongly disagree that the analogy is a stretch. Taking away the ability to run apps as an administrator would be completely akin to giving my computer a flat tire. I have a Microsoft Visual Studio project that fails to compile during the code signing phase if Visual Studio is not launched with "Run as Administrator". I've attempted to troubleshoot this, but have found no solution, either on google, blogs, or stack overflow (this is not an isolated incident). The ability to run apps as an admin is a must for some users (even when only using Microsoft software). Jun 4, 2013 at 21:24
  • 3
    If you need to run apps as Administrator I'd recommend having a second user account and using it to run the application elevated w/ "Run As Administrator". That's the only choice I see. If the application won't work properly with "Run As" then the application is defective. (I'd also argue that any application that requires Administrator rights and isn't a network or computer administration application is also defective-- MSFT software or not.) I find defective software one of the most frustrating aspects of my job, so I can understand your frustration, too. I wish there was a good solution. Jun 5, 2013 at 1:28

Simply put, it links your super-user credentials with your normal credentials. It is of course more complex, but basically, even your "administrator" account on windows 7 is not an admin, but needs to do the equivalent of SUDO on linux to perform a multitude of operations. When you map a network drive, you need to do this, but the network drive only becomes mapped for the super-user, not the normal user. This registry setting links the super-user credentials with your standard ones for the purpose of mapped drives. This way, both can access the mapped drive instead of just the super-user.

  • Could you clarify if this setting in fact only affects network drives? Or has it any other effect? (see q edit)
    – Martin
    Sep 20, 2010 at 9:01

Declare: I know this is a question from 2010 but I still try to add more details. I'm still new to Stack Exchange community. This answer adds details to Evan Anderson's answer.

Personally, I can't think of a way to "exploit" this loophole, insofar as "seeding" the elevated token with a drive mapping would still require the user to actually elevate and execute something malicious from that "seeded" drive mapping.

For example, a program on network drive was to run as admin, in order to achieve this, you must schedule two things: mount the network directory as drive in admin session, assuming it was Z:; run the program from network drive, assuming it was Z:\daemon.exe.

By enabling EnableLinkedConnections a very specifically made malware could unmount Z:\ and replace it with another network drive with a dangerous daemon.exe file, and Windows will continue executing it since it's stored within local area and aren't enforced by internet security zone settings (MOTW). Were it remaining disabled, the replaced Z: drive won't have been affecting the admin session therefore ensuring security.

It's a very targeted security risk uncommonly seen nowadays because:

  1. You use a network drive for priority tasks which is extremely uncommon, priority tasks usually use UNC path to avoid problem across sessions, it means that the program isn't well designed to utilize UNC path (usually seen on very ancient software and Microsoft's very ancient CMD).
  2. Attacker has to know which program you're running on network drive with UAC priority, which means attacker already mastered how your computer system works, but who has the chance of knowledge that? A stranger won't be that bored to spy on your computer 24 * 7, perhaps someone with physical access to your computer.
  3. Attacker has to create a fake one that doesn't trigger security software. Despite bypassing MOTW flag, modern Windows usually run security software, most people don't care it so it's default to Windows Defender.
  4. And finally, in case the device is in managed environment, unless attacker exploited a vulnerability to run that mount program, it also means the security policy is likely to be poorly made because untrusted code shouldn't have run on managed devices by users.

The same attack surface applies to symbolic link too, which is why creation of symbolic link requires UAC priority by default until Windows 10 Creators Update. The removal of UAC priority requirement gives the signal that it's no longer a dangerous security breach everyone should avoid, although system administrators may still configure this in group policy if needed.

Edit: word changes

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .