Does enabling EnableLinkedConnections invite any kind of security risk?
As shown Microsoft's TechNet, network shares that are mapped by logon scripts are shared with the standard user access token instead of with the full administrator access token. Here's the gist of it:
Symptom
After you turn on User Account Control (UAC) in Windows Vista or Windows 7, programs may not be able to access some network locations. This problem may also occur when you use the command prompt to access a network location.
Cause
This problem occurs because UAC treats members of the Administrators group as standard users. Therefore, network shares that are mapped by logon scripts are shared with the standard user access token instead of with the full administrator access token. [...]When network shares are mapped, they are linked to the current logon session for the current process access token. This means that if a user uses the command prompt (cmd.exe) together with the filtered access token to map a network share, the network share is not mapped for processes that run with the full administrator access token
Resolution
Creating/setting the DWORD value of EnableLinkedConnections at the location HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystem to 1 and restarting the computer enables Windows Vista and Windows 7 to share network connections between the filtered access token and the full administrator access token.
I've already established that the workaround mentioned above works perfectly fine, fixing my problem. Now I'm wondering if enabling enablelinkedconnections so poses a security risk and, if so, what it is? I can live without this workaround but having it in place definitely makes my life easier.
I found an answer from Jon Schwartz, UAC Architect, which provided the following details on enablelinkedconnections:
Mapped drives get interesting in combination with the "split-token" account, because of a weird dichotomy in the system (in large part historical) -- the drive letters are per-user, but the underlying drive mappings are per-LUID (i.e., distinct for each individual logon, even for the same user). This is why the mappings disappear when you elevate, and the setting you found tells the OS that you want the mappings you make non-elevated to be mirrored into your elevated context as well -- under the covers, the NTLanman network provider maps the drive and then asks the LSA to find the associated elevated token and use it to mirror the mapping.
As for any vulnerabilities, Jon had this to say: 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. This is from 2007 and mostly applies to Windows Vista, though. I don't think much has changed since then. Since we are still using Windows 7, I should be fine, I guess.
What does enablelinkedconnections do? 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.