На сервере Windows, который находится в домене, у меня есть сценарий, который я запускаю из запланированных задач.
Я хочу, чтобы этот скрипт запускался под mydomain\peter учетная запись пользователя. Сделать это с запланированными задачами несложно, если вы знаете пароль Питера. И после этого сценарий останавливается, когда Питер решает (или должен) изменить свой пароль.
В Linux cron задание может быть запущено с любой учетной записью пользователя без необходимости знать соответствующий пароль. И root может запускать что угодно от имени другого пользователя (с su и sudo).
Как это сделать в Windows?
Мне нужен старый сервер Windows 2003, но я могу запустить его с другого компьютера.
Это не поддерживается в Windows. По причинам подотчетности вы не должны выдавать себя за других пользователей, даже как администратор.
Тем не менее, это как раз тот вариант использования для учетных записей служб. Почему бы не настроить учетную запись службы пользователя домена для этой запланированной задачи?
Вероятно, это то, что вам все равно следует делать, а не запускать запланированные задачи или сценарии от имени реального пользователя. Вы можете отключить истечение срока действия пароля для учетной записи, чтобы задание не прерывалось всякий раз, когда Питу приходится менять свой пароль, для другого преимущества.
Хорошо, поскольку вы хотите только уменьшить свои права доступа (а не работать как Питер как таковой), у вас могут быть некоторые варианты.
В Windows 7 (и Windows Server 2008 R2) планировщик задач поддерживает это напрямую (с помощью параметра «Не сохранять пароль»), но я не думаю, что есть какой-либо встроенный эквивалент для Windows Server 2003. Выполнение задачи таким образом на другом компьютере, вероятно, не поможет, потому что у вас нет доступа к сети.
Однако это можно сделать программно, даже в Windows 2003, через CreateRestrictedToken Функция Win32. Поиск в Google обнаружил программу под названием неограниченный который, похоже, может делать то, что вы хотите (через -RSid вариант). Обратите внимание, я никогда не использовал эту программу, поэтому не могу поручиться за ее надежность.
Используя этот подход, скрипт имеет доступ только к файлам, которые предоставляют доступ к обе локальная система и Питеру. (Обратите внимание, что локальная системная учетная запись неявно принадлежит к группе администраторов, поэтому, если у администраторов есть доступ, этого будет достаточно.)