Vista UAC - 网络驱动器故障映射

发布于 2024-07-30 18:38:11 字数 554 浏览 7 评论 0原文

我们有一个以编程方式映射网络驱动器的应用程序。 在启用 UAC 的 Vista 上,我们遇到一些奇怪的问题。

我们的应用程序将驱动器映射为非提升驱动器,因此如果用户浏览资源管理器并双击运行 exe,它会提示输入 UAC。 因此,当他们批准它时,它会提示输入共享的用户名/密码......很奇怪,因为保存了凭据。

事实证明,提升的进程无法访问从非提升的进程映射的映射驱动器。

要查看此问题的实际情况,请执行以下步骤:

  • 在没有 UAC 的情况下运行 cmd.exe 运行
  • “net use w: \yourHostname\yourShare /user:yourUser yourPassword /persistent:yes”
  • 以管理员身份运行 cmd.exe
  • 键入“w:” ,并查看错误消息

此时,您可以运行普通的“net use”并看到提升的cmd上的连接不可用,但其他非提升的cmd将其视为正常。

有谁知道解决此问题的解决方法? 或者也许是一种将网络驱动器映射到“所有用户”的方法?

We have an application that programmatically maps network drives. On Vista with UAC on, we get some strange issues.

Our application maps the drive non-elevated, so if the user browses explorer and double clicks to run an exe, it prompts for UAC. So when they approve it, it prompts for a username/password for the share... Strange since the credentials are saved.

It turns out, an elevated process cannot access a mapped drive that was mapped from a non-elevated process.

To see this issue in action, do the following steps:

  • Run cmd.exe with no UAC
  • Run "net use w: \yourHostname\yourShare /user:yourUser yourPassword /persistent:yes"
  • Run cmd.exe as Administrator
  • Type "w:", and see the error message

At this point you can run plain "net use" and see the connection on the elevated cmd is Unavailable but the other non-elevated cmd sees it as OK.

Does anyone know a workaround to fix this issue? or maybe a way to map a network drive to "All Users"?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

迷爱 2024-08-06 18:38:11

这是设计使然。

即使用户帐户相同,但提升版本具有具有管理员组成员身份和附加权限的令牌,这些令牌是独立创建的,因此具有不同的 LUID,并且在内核看来来自不同的用户登录。 由于它们来自不同的登录,因此它们之间不共享映射驱动器。

http://blogs.msdn.com/cjacks/archive/2007/02/19/mapped-network-drives-with-uac-on-windows-vista.aspx对此进行了更详细的讨论。

This is by design.

Even though the user account is the same, with the elevated version having a token with membership in the administrator group and addition privileges, the tokens are created independently and thus have different LUID's and appear to the kernel to be from different user logons. Since they are from different logons, mapped drives are not shared between them.

http://blogs.msdn.com/cjacks/archive/2007/02/19/mapped-network-drives-with-uac-on-windows-vista.aspx discusses this in additional detail.

一身软味 2024-08-06 18:38:11

查看此链接:Regedit 链接

它们描述了一个注册表项,允许提升用户访问映射驱动器的权限,反之亦然。 这解决了我所有的问题,并且正是我所寻找的。

编辑:

原始链接已失效,但以下是从 2009 年 1 月 24 日快照复制的文本 www.archive.org


如果您发现无法通过管理令牌访问映射驱动器,请尝试以下操作。 当作为受保护的管理员运行时,您有两个令牌,并且此密钥将维护两个令牌的连接(无论如何,这是我的理解)。 它还可以帮助解决登录脚本的问题。

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
EnableLinkedConnections =(dword)1

本文档的“组策略脚本可能因用户帐户控制而失败”部分也很有用。

http://technet2. microsoft.com/WindowsVista/en/library/5ae8da2a-878e-48db-a3c1-4be6ac7cf7631033.mspx?mfr=true

我将很快发布更多相关信息。

Check out this link: Regedit Link

They describe a registry key that allows elevated users to access mapped drives and vice versa. This solves all my issues and was exactly what I was looking for.

EDIT:

The original link is dead, but here's the text as copied from the Jan 24, 2009 snapshot at www.archive.org:


If you are finding that you don't have access to mapped drives from your admin token try the following. When running as a protected admin you have two tokens and this key will maintain the connection for both tokes (that is my understanding anyway). It can also help to clear up issues with Login scripts.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
EnableLinkedConnections =(dword)1

Also of use is the "'Group Policy Scripts can fail due to User Account Control" section of this doc.

http://technet2.microsoft.com/WindowsVista/en/library/5ae8da2a-878e-48db-a3c1-4be6ac7cf7631033.mspx?mfr=true

I will be posting more information on this soon.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文