
Я хотел бы использовать «psexec» по локальной сети для запуска команды от имени другого пользователя, который в это же время вошел в систему.
Другими словами: я хочу использовать 'psexec' со встроенными учетными данными учетной записи администратора, чтобы запустить программу на рабочем столе Боба. Эта программа должна верить, что она была запущена Бобом с использованием его учетных данных. Поскольку я использую учетную запись администратора, я хотел бы обойти необходимость пароля Боба, чтобы сделать это (с помощью 'runas', возможно).
Редактировать 1
Разъяснения:
У меня уже есть доступ к системе, так как я являюсь владельцем учетной записи администратора.
Мне не хочется, чтобы агент/служба/exe-файл постоянно работал в фоновом режиме.
Это домашняя установка.
Я думал о чем-то вроде этого:http://reboot.pro/files/file/237-runassystem-and-runfromtoken/но применяется к любому другому пользователю.
Я хочу иметь возможность запускать программу, например, игру или почтовый клиент, которая сохраняет файлы в путях, определенных для каждого пользователя.** Поэтому запуск от имени администратора будет неэффективным, поскольку программа загрузит профиль данных администратора, а не Боба (который вошел в систему).
Моя конечная цель — иметь возможность запустить команду «whoami» и получить сообщение о том, что я являюсь зарегистрированным пользователем.
Обновлять
Мне удалось получить 'cmd.exe' как СИСТЕМУ, а затем получить один экземпляр как мою учетную запись (защищенную паролем) с помощью RunFromToken. Я собираюсь проверить это дальше.
решение1
Нет. Это полностью обошло бы стороной вопрос индивидуальной безопасности.
Я добавлю, что если у вас есть доступ к системе развертывания, такой как SCCM, вы можете запустить пакет только тогда, когда пользователь вошел в систему, и тогда он будет запущен в контексте пользователя. Вы также можете запустить пакет как часть сценария входа, который также будет запущен в контексте пользователя.
решение2
Все эти ответы верны, если речь идет о выдаче себя за пользователя в сети. Однако вы можете выдать себя за локального пользователя без необходимости ввода пароля при определенных условиях:
- Вы должны быть членом группы локальных администраторов.
- Вы можете выдавать себя только за другого пользователя, который в данный момент находится в системе.
- Олицетворение пользователя ограничено локальной системой. Вы не можете олицетворять пользователя в удаленной системе, не войдя сначала в удаленную систему как член локальной группы администраторов.
Это разрешено из-за того, как Windows делегирует PRIVILEGE для олицетворения локально вошедших в систему пользователей СИСТЕМНЫМ и локальным администраторам. Информацию об этой PRIVILEGE можно найти в разделе локальная групповая политика > Локальные политики > Назначение прав пользователя > Олицетворять клиента после аутентификации.
Один из известных мне инструментов, который позволяет это сделать, — Process Hacker 2. Запустите инструмент как администратор и найдите процесс, запущенный от имени пользователя, которого вы хотите выдать. Щелкните его правой кнопкой мыши, выберите Разное > Запустить от имени этого пользователя..., затем введите двоичный путь, который вы хотите запустить от имени этого пользователя, например cmd. Затем CMD откроется от имени этого пользователя, не запрашивая его пароль.
решение3
Этого делать нельзя, и на то есть чертовски веские причины.
Это был бы Святой Грааль для любого вируса, если бы это было возможно.
На компьютере Windows всегда есть несколько процессов, запущенных под несколькими учетными записями администратора (например, учетные записи LocalSystem и NetworkSystem, если назвать только две.)
Если бы ваш запрос был возможен, любой произвольный процесс мог бы вставить новые процессы в эти учетные записи: Нет никакого способа, которым вы когда-либо сможете защитить свою систему от вирусов. (Любой произвольный процесс буквально означает то, что он говорит: это также включает вирусы!)
Другие проблемы — это конфиденциальность и подотчетность.
Если вы можете подделать операцию, как будто ее выполнил другой пользователь, вы можете получить доступ к данным этого другого пользователя. Конфиденциальность уходит в прошлое.
И больше нет способа узнать, было ли что-то действительно сделано этим пользователем или кем-то, выдающим себя за него/нее. Это означает, что вы больше не можете надежно отследить, кто что сделал. Вы теряете подотчетность, что является большой вещью в системах, которые должны соответствовать правилам соответствия, например, в медицинских системах.
Итак, это очень веские причины изолировать среды учетных записей друг от друга. (Их гораздо больше, но это выходит за рамки данного вопроса.)
решение4
Как отмечено в других ответах, вы, вероятно, действительно не хотите этого делать. Если бы это было так просто, я мог бы, например, заставить пользователя загрузить какой-нибудь нелегальный веб-сайт, где его уволят и арестуют. Даже у администраторов не должно быть такой божественной власти.
Если все, что вам действительно нужно, это узнать, кто в данный момент вошел в систему на компьютере (локальном или удаленном), рассмотрите утилиту «psloggedon» от MS TechNet (ранее SysInternals):https://technet.microsoft.com/en-us/sysinternals/bb897545.aspx
Если вам все еще действительно нужно запустить задачу от имени пользователя, рассмотрите возможность запуска задач при входе в систему.. что, конечно, все равно приведет к вам из соображений безопасности, но Windows все равно будетбегатьзадачу так, как если бы вы были этим пользователем.