Take the 2-minute tour ×

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:


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.

share|improve this question
add comment

2 Answers

up vote 10 down vote accepted

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.

share|improve this answer
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].) –  BrainSlugs83 May 16 '13 at 22:36
@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. –  Evan Anderson May 17 '13 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. –  BrainSlugs83 Jun 4 '13 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). –  BrainSlugs83 Jun 4 '13 at 21:24
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. –  Evan Anderson Jun 5 '13 at 1:28
show 1 more comment

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.

share|improve this answer
Could you clarify if this setting in fact only affects network drives? Or has it any other effect? (see q edit) –  Martin Sep 20 '10 at 9:01
add comment

Your Answer


