net-usenetwork-shareuser-permissionswindowswindows-command-prompt
The command:
NET USE
Will display open connections by any process of current user. But, if command prompt (cmd.exe, or any shell) is non-elevated, it would display only connections opened by non-elevated processes. To see shares open by elevated processes, we need to use Command Prompt elevated.
How to view all shares/connections opened by same user (i.e. current user) – irrespective of elevation of processes which opened the remote share (for example, from (non-elevated) Windows Explorer) ?
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.
Best Answer
There isn't built-in functionality to do what you're looking for. The elevated context's "mappings" are separate from the limited-user context, as you're seeing. You could write a script to perform the
NET USEas both the limited and elevated contexts and concatenate the results, but there's no single API or command-line tool that I'm aware of that does what you're looking for.