What does registry setting EnableLinkedConnections do on a technical level?

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.

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.

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.

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