用户有一个PowerShell脚本,在启用UAC的情况下,该脚本可以执行一些需要在Windows 2012上进行管理访问的操作。
当他们以本地管理员的身份运行脚本时,如果拒绝访问,脚本就会失败。但是,如果他们提高了权限并以管理员的身份运行脚本,它就能工作。到现在为止还好。
现在,他们有一个运行PowerShell脚本的自定义Windows。Windows服务配置为在相同的本地管理员帐户(即,不是本地系统/网络服务/等等)下运行。如果拒绝访问,脚本就会失败,好像帐户不是管理员一样。在旧版本的Windows上,脚本工作正常。
UAC如何在Windows服务世界中应用?我认为在自定义本地管理员帐户下运行的Windows服务总是“提升”的,但在这种情况下似乎并非如此。
发布于 2013-02-28 18:57:46
当他们以本地管理员的身份运行脚本时,如果拒绝访问,脚本就会失败。
这意味着作为“本地管理员”不足以运行脚本。这证明“本地管理员”并不涵盖计算机上的全部权限。在UAC上下文中,“本地管理员”不具有“管理员”的全部权限(如OS所示),但当它请求执行需要管理权限的操作时,UAC会拦截调用,而不是只是不客气地用错误代码拒绝请求,它会提示用户。如果用户说“是的,继续”,那么该过程将被授予更高的权限。从流程的角度来看,所有事情的运作都好像它一直是一个“真正的管理员”。
服务不是在会话中运行,而是“作为服务运行”。这意味着没有用户要提示。因此,在默认情况下配置的UAC不能根据需要授予“真正的管理员”权限。
显然,您可以将UAC配置为永不提示,而是授予权限(这基本上取消了UAC的安全好处,如果有的话);例如,请参见这篇博客文章)。一个更好的解决方案是将服务作为一个已经是真正的管理员的帐户来运行,而不是以“本地管理员”()这个浮夸的名称进行廉价的模仿。
发布于 2018-07-16 21:31:49
UAC不应影响系统服务。除了这个问题之外,我找不到任何证据证明这一点,而且我在Windows 7、Windows 10v1607和Windows 10v1803上进行了测试,但没有能够重现问题。
我的结论是,您的特定机器有一些不寻常的地方导致了这种情况,或者您的问题是由其他原因引起的,例如,服务SID类型被设置为受限,或者您遇到的ACL只允许访问交互。
任何未来的读者谁正在经历这个问题,欢迎给我电子邮件,如果他们想要帮助解决这个问题。我的电子邮件地址在我的个人资料里。
发布于 2019-08-08 08:26:55
UAC不应影响系统服务。
对此,哈利非常感激,他给出了一个清晰的答案:我在很长一段时间里一直在怀疑:-)。
今天在Windows2012R2上下文和#Requires -RunAsAdministrator标记的PowerShell脚本中进行了测试:
.\script.ps1 : The script 'script.ps1' cannot be run because it contains a "#requires" statement
for running as Administrator. The current Windows PowerShell session is not running as Administrator. Start Windows
PowerShell by using the Run as Administrator option, and then try running the script again.PowerShell -NonInteractive -File d:\pathto\script.ps1的自定义Windows运行时:一切正常。关于技术细节,Windows是用Go语言编写的(使用golang.org/x/sys/windows/svc):没有特定的清单。它是通过WiX (https://wixtoolset.org)安装的,具有默认的ServiceInstall选项(ownProcess +类型auto),并配置为具有本地管理员用户帐户的LogOn。
所以,也许最初的问题与Windows服务登录的用户帐户的权限设置有关?
https://security.stackexchange.com/questions/31693
复制相似问题