错误代码1312(no_such_logon_session)在写信给凭据管理器时。在交互式模式下计划的任务

发布于 2025-01-21 23:40:42 字数 1287 浏览 0 评论 0原文

我有一个通过任务调度程序在VM上运行的应用程序。该应用程序试图写信给凭据管理器,但使用错误代码1312失败。我从主机机器上启动vm的应用程序是通过代码:

 $password= "password" | ConvertTo-SecureString -asPlainText -Force; 
 $username = "name";
 $credential = New-Object System.Management.Automation.PSCredential($username,$password);
 Invoke-Command -VMName INSTANCE_ID -Credential $credential -ScriptBlock 
      {
        $gettime = (Get-Date).AddMinutes(2);
        $run = $gettime.ToString('HH:mm');
        $action = New-ScheduledTaskAction -Execute 'C:\logging.bat';
        $trigger = New-ScheduledTaskTrigger -Once -At $run;
        $setting = New-ScheduledTaskSettingsSet -Priority 4
        $principal = New-ScheduledTaskPrincipal -GroupID "BUILTIN\Administrators" -RunLevel Highest;
        Register-ScheduledTask -Action $action -Trigger $trigger -Setting $setting -Principal $principal -TaskName "ID_Logging_Task" -Description "my description"
       }

根据理解,我正在以最高的特权运行,而且我已经登录了VM通过Sysinternal Autlogon工具。我不明白这里出了什么问题。需要更改哪些设置,以便可以在会话上找到适当的登录。

更新:

$principal = New-ScheduledTaskPrincipal -UserID "DOMAIN\USERNAME" -LogonType Interactive -RunLevel Highest 

登记>寄存器中添加了相同的用户名没有密码的情况背景过程。我需要在以交互式模式和最高特权运行我的应用程序时修复1312错误。

I have an app which run on a VM via a task scheduler. And the app tries to write to the credential manager but fails with error code 1312. The way I start my app on VM from host machine is via code:

 $password= "password" | ConvertTo-SecureString -asPlainText -Force; 
 $username = "name";
 $credential = New-Object System.Management.Automation.PSCredential($username,$password);
 Invoke-Command -VMName INSTANCE_ID -Credential $credential -ScriptBlock 
      {
        $gettime = (Get-Date).AddMinutes(2);
        $run = $gettime.ToString('HH:mm');
        $action = New-ScheduledTaskAction -Execute 'C:\logging.bat';
        $trigger = New-ScheduledTaskTrigger -Once -At $run;
        $setting = New-ScheduledTaskSettingsSet -Priority 4
        $principal = New-ScheduledTaskPrincipal -GroupID "BUILTIN\Administrators" -RunLevel Highest;
        Register-ScheduledTask -Action $action -Trigger $trigger -Setting $setting -Principal $principal -TaskName "ID_Logging_Task" -Description "my description"
       }

As per understanding I am running with the highest privilege possible plus I have logged onto the VM via sysinternal autlogon tools. I don't understand what is going wrong here. What setting needs to be changed so that it can find a proper log on session.

UPDATE:

I added

$principal = New-ScheduledTaskPrincipal -UserID "DOMAIN\USERNAME" -LogonType Interactive -RunLevel Highest 

with same username in Register-ScheduledTask without password as when I specify password my app does not launch in interactive mode but as a background process. I need to fix 1312 error while running my app in interactive mode and in the highest privilege.

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

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

发布评论

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

评论(1

油饼 2025-01-28 23:40:42

这似乎类似于 powerShell:设置一个计划的任务,以在用户未登录时运行

如果运行计划的任务作为一个groupID,然后在任务计划运行时,该组中的某人需要登录到机器中。

为了使该任务在没有任何人登录的情况下运行,则必须为主体指定用户ID,并在regission> regize-scheduledtask中提供相应的用户名和密码,以下例如:

$principal = New-ScheduledTaskPrincipal -UserID "NT AUTHORITY\SYSTEM" -LogonType ServiceAccount -RunLevel Highest

系统帐户下运行的任务将具有管理权,但只能访问专门授予计算机域帐户(Computername $)的网络资源。


更新:

关于以交互式模式运行任务,请参见 https://serverfault.com/q/q/458848

基于我可以找到的内容,作为特定用户进行交互操作,需要在任务运行时将用户登录到系统。如果未登录用户,则会导致错误1312。

另一方面,如果将任务配置为“运行用户是否登录”,并且提供了一个密码,则任务可以 与桌面交互。

在其中一个答案中,有人建议使用GroupID“用户”来设置任务。这可能会互动运行,但不会具有提高的权限。

该操作系统旨在不允许无私人用户直接运行特权操作。使用计划的任务不会绕过这一点,并且不允许非特权用户作为不同的特权用户运行交互式应用程序。

如果非特权用户有必要访问特权操作,则最好设计一个作为非特权流程运行的前端应用程序,然后与特权服务或任务进行通信。可以通过命名Pipes或通过特定事件ID和消息写入应用程序日志来完成此类通信。但是,需要格外谨慎,以避免意外的特权升级。

This appears to be similar to Powershell: Set a Scheduled Task to run when user isn't logged in

If running a scheduled task as a GroupID, then someone from that group would need to be logged into the machine at the time that the task is scheduled to run.

For the task to run without anyone logged in, then either a UserID must be specified for the Principal with a corresponding username and password provided in Register-ScheduledTask, -OR- the principal should be the SYSTEM account, e.g.:

$principal = New-ScheduledTaskPrincipal -UserID "NT AUTHORITY\SYSTEM" -LogonType ServiceAccount -RunLevel Highest

Tasks running under the SYSTEM account will have admin rights, but will only have access to network resources specifically granted to the computer's domain account (COMPUTERNAME$).


Update:

Regarding running the task in interactive mode, see https://serverfault.com/q/458848

Based on what I could find, running a schedule task interactively as a specific user requires that user to be logged on to the system at the time the task runs. If the user is not logged in, error 1312 will result.

On the other hand, if the task is configured as "run whether user is logged on or not", and a password is supplied, then the task can not interact with the desktop.

In one of the answers, someone suggests setting up the task with GroupID "Users". This could possibly run interactively, but it isn't going to have elevated permissions.

The operating system is designed to not allow unprivileged users to directly run privileged operations. Using a scheduled task is not going to bypass this, and isn't going to allow a non-privileged user to run an interactive application as a different, privileged user.

If it is necessary for non-privileged users to have access to privileged operations, then it is best to design a front-end application that runs as a non-privileged process, which then communicates with a privileged service or task. Such communication can be done via named-pipes or via writing to the application log with specific event ids and messages. However, extreme caution is needed to avoid unintended privilege escalation.

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