(с) Вася Ложкин.
К сожалению, в работе сисадмина нет-нет да и приходится разрешать пользователям запускать всякий софт с админскими правами. Чаще всего это какие-нибудь странные китайские программы для работы с оборудованием. Но бывают и другие ситуации вроде небезызвестного bnk.exe.
Попробуем разобрать решения, которые позволят и программу запустить, и безопасника с финансистом не обозлить.
Ну, и зачем тебе права?
Программа может запрашивать права администратора условно в двух случаях:
- Когда хочет получить доступ туда, куда «простым смертным» нельзя: например, создавать файлы в системных каталогах.
- Когда программу скомпилировали со специальным флагом «Требовать права администратора».
С первым случаем все понятно: берем в руки замечательную программу Марка Руссиновича Process Monitor
, смотрим, что происходит, и куда программа пытается залезть:
Куда это лезет этот 7Zip?
И по результатам исследования выдаем права пользователю на нужный каталог или ветку реестра.
Сложнее, если случай клинический, и так просто выдать права не получится: например, программа требует сильного вмешательства в работу системы вроде установки драйверов. Тогда придется придумывать всякий колхоз, про который речь пойдет в последнем разделе статьи. Пока подробнее освещу второй случай — когда стоит флажок.
Если сильно упростить, то в специальном манифесте
программы (к слову, установщики — это тоже программы) могут быть три варианта запуска:
- asInvoker
. Программа запускается с теми же правами, что и породивший ее процесс (как правило, это explorer.exe c правами пользователя); - highestAvailable
. Программа попросит максимально доступные пользователю права (у администратора появится окно с запросом повышения UAC, у пользователя — нет); - requireAdministrator
. Программа будет требовать права администратора в любом случае.
Если разработчик твердо решил требовать права администратора, даже если они не нужны, то обойти это можно малой кровью.
Нет, не будет тебе прав
В системе Windows, начиная с Vista, появилась служба UAC, которая помимо прочего отвечает за запросы программ на повышение прав. Не все программы «переваривали» работу с этой службой. Поэтому в системе был доработан механизм совместимости приложений, позволяющий прямо задать программе ее поведение — запрашивать права или нет.
Простейшим вариантом работы с этим механизмом будет использование переменных среды.
Рассмотрим пример с редактором реестра. Действительно, запуская regedit.exe под администратором, мы получаем запрос на повышение прав:
Запрос повышение прав.
Если же мы запустим редактор реестра из консоли, предварительно поменяв значение переменной среды __COMPAT_LAYER
на:
set __COMPAT_LAYER=RUNASINVOKER То запроса UAC не будет, как и административных прав у приложения:
Бесправный редактор реестра.
С конкретным примером такой неприятной программы можно столкнуться при загрузке классификаторов банков из 1С с сайта РБК по ссылке http://cbrates.rbc.ru/bnk/bnk.exe
. Если обновление классификаторов отдается на откуп самим пользователям и нет возможности поменять загрузку на bnk.zip (а современные 1С это поддерживают), то приходится придумывать костыли. Ведь bnk.exe — самораспаковывающийся архив, в котором зачем-то прописано «Требовать права администратора».
Поскольку ярлычками тут обойтись не выйдет, ведь 1С сама скачивает файл и запускает его, то придется применять тяжелую артиллерию — Microsoft Application Compatibility Toolkit.
Документация к ПО, как обычно, доступна на официальном сайте
, загрузить можно как часть Windows Assessment and Deployment Kit
. Сам процесс решения проблемы несложен.
Создаем исправление приложения.
Имя и издатель значения не имеют. Имеет значение только расположение файла — тут нужно указать реальный проблемный bnk.exe (где он будет лежать на самом деле — не важно).
Далее необходимо в списке исправлений выбрать RunAsInvoker.
Выбираем нужный фикс.
Все остальное оставляем по умолчанию, сохраняем базу данных. Должно получиться примерно так:
Созданный фикс для bnk.exe.
После этого достаточно будет установить базу данных, щелкнув по ней правой кнопкой и выбрав Install. Теперь пользователи смогут сами грузить классификаторы банков.
Все становится хуже, если приложению действительно нужны права админа. Тогда добавление прав на системные объекты и исправления не помогают.
Ну ладно, держи права
Казалось бы, самым очевидным решением для запуска нашего странного ПО выглядит использование встроенной утилиты Runas. Документация доступна на сайте Microsoft
.
Ну, посмотрим, что из этого выйдет.
runas /savecred /user:Администратор "C:\Program Files\7-Zip\7zFM.exe" Действительно, RunAs запустит 7zip с правами учетной записи «Администратор», спросит пароль и запомнит его. Потом ярлык с такой строкой запуска будет запускать 7zip под Администратором без вопросов.
Есть один существенный недостаток: пароль запоминается на уровне системы, и теперь, используя команду Runas, можно будет запускать абсолютно любую программу. Это мало чем отличается от прямого предоставления админских прав сотрудникам, так что использовать это решение не стоит.
Зато runas может быть полезен, когда сотрудник знает пароль администратора, но работает под ограниченной учетной записью (по идее так должен делать каждый системный администратор).
Если мы начали с консольных команд, то перейдем к более высокоуровневым скриптам. Интересное решение было предложено в статье « Планктонная Windows
», где упомянутый выше Runas обвязывался js-скриптом и пропускался через обфускатор. У решения есть и очевидный минус — скрипт можно раскодировать.
Чуть более интересным методом в 2к20 являются возможности PowerShell и его работа с паролями. Подробнее можно почитать в материале « Защита и шифрование паролей в скриптах PowerShell
».
Если вкратце: в PS работа с паролями производится через специальный тип данных SecureString и объект PSCredential. Например, можно ввести пароль интерактивно:
$Cred = Get-Credential Затем сохранить пароль в зашифрованном виде в файл:
$Cred.Password | ConvertFrom-SecureString | Set-Content c:\pass.txt И теперь использовать этот файл для неинтерактивной работы:
$username = "Domain\Администратор"
$pass = Get-Content C:\pass.txt | ConvertTo-SecureString
$creds = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $username, $pass К сожалению, файл этот можно использовать только на том ПК, на котором его создали. Чтобы этого избежать, можно сделать отдельный ключ шифрования. Например так:
$AESKey = New-Object Byte[] 32
[Security.Cryptography.RNGCryptoServiceProvider]::Create().GetBytes($AESKey)
$AESKey | out-file C:\password_aes.key Теперь при помощи этого ключа пароль можно зашифровать:
$Cred.Password| ConvertFrom-SecureString -Key (get-content C:\password_aes.key
)| Set-Content C:\pass.txt $pass = Get-Content C:\pass.txt | ConvertTo-SecureString -Key (get-content C:\password_aes.key) К сожалению, с безопасностью дела обстоят так же печально: утащить пароль не составляет трудностей, если есть доступ к файлу с ключом шифрования и зашифрованным паролем. Да, можно добавить обфускации и скомпилировать скрипт в .exe вместе с нужными файлами. Но нужно понимать, что это — полумеры.
В свое время я использовал для решения подобных задач свой любимый AutoIt, где компилировал скрипт с командой RunAs
и радовался… До тех пор, пока не узнал, что AutoIt (особенно старых версий) декомпилируется на раз-два.
Другим интересным вариантом может быть применение назначенных заданий — если создать назначенное задание от админского аккаунта, пользователю для работы будет достаточно его запуска. К сожалению, для интерактивной работы с приложением это решение не подходит.
На свете существует несколько сторонних решений, призванных решить задачу. Остановлюсь на парочке из них.
Пожалуй, одна из самых известных утилит — это AdmiLink
, разработанная Алексеем Курякиным для нужд ядерной физики. Программа и принципы ее работы описаны на официальном сайте
. Я, как обычно, позволю себе более краткое описание.
Программа состоит из трех модулей. AdmiLink — это графическое окно, где можно создать ярлык на нужное приложение (в принципе, в ряде случаев достаточно только его).
Основное окно программы.
Помимо непосредственно создания ярлыка (и да, запрос UAC тоже можно подавлять), есть и дополнительные функции вроде калькулятора, терминала и удобных настроек политик безопасности. Со всеми возможностями программы читателю предлагается разобраться самостоятельно.
Второй модуль называется AdmiRun и представляет из себя консольную утилиту. Она умеет запускать приложения от имени администратора, получив в качестве одного из параметров строку, созданную через AdmiLink. В строке шифруется имя пользователя и пароль, при этом участвует и путь к программе.
На первый взгляд все выглядит безопасно, но, к сожалению, код программ закрыт, и насколько можно доверять разработчику — вопрос.
Третий модуль — AdmiLaunch — отвечает за запуск окон в разных режимах, и он используется для запуска AdmiRun, если создавать ярлык через AdmiLink.
В целом, решение проверено годами и поколениями отечественных системных администраторов. Но добавлю и альтернативу из-за рубежа.
RunAsRob
— довольно интересное ПО за авторством немецкого разработчика Оливера Хессинга (Oliver Hessing). В отличие от AdmiLink, ПО устанавливается как служба, запускаемая под привилегированной учетной записью (администратора или системы). Как следствие, подготовленный ярлык обращается к службе, которая уже в свою очередь запускает заданное ПО.
Особенность программы в том, что есть возможность авторизовать не только программы, но и папки (включая сетевые). А хранение настроек в реестре позволило добавить шаблоны групповых политик, примерно как мы писали в статье « Погружение в шаблоны и приручение GPO Windows
». Благодаря этому при необходимости настройки можно применять прямо из Active Directory.
Основное окно программы.
Программа богато документирована на официальном сайте
.
У этого автора есть еще и программа RunAsSpc
, позволяющая запускать исполняемые файлы под правами другого пользователя, передавая учетные данные через зашифрованный файл.
Мне остается только добавить, что это ПО бесплатно только для личного использования.
Но учтите, что из программы, запущенной под административными правами, можно натворить бед. Например, запустить привилегированную командную консоль через диалог Файл — Открыть.
Запускаем cmd.exe прямо из редактора реестра.
Немного защититься помогут политики запрета контекстного меню и прочих диспетчеров задач, часть из которых может настроить AdmiLink. Но в любом случае следует быть осторожным.
А вам приходилось городить странные костыли? Предлагаю делиться историями в комментариях.
В этой статье я подробно расскажу о проблемах, с которыми столкнётся каждый системный администратор, использующий в своей работе возможность запуска программ от имени другого пользователя, в большинстве случаев от имени администратора. Если вы — тот самый сисадмин, прочитайте её внимательно, скорее всего вам требуется срочная смена своего пароля.
Зачем это вообще нужно? Бывают ситуации, когда пользователю с ограниченными правами требуется выполнить программу, которой для выполнения специфической работы требуются повышенные права. Например, программисту нужно предоставить возможность завершать определённые процессы бухгалтерской программы, некоторым пользователям из бухгалтерии требуется возможность переключать ключи безопасности в интерактивном режиме и так далее. Часть этих задач можно выполнять неинтерактивно, при этом несколько страдает удобство, поскольку пользователь не видит интерфейс программы и может разве что получить системное сообщение о завершении работы программы, об этом способе подробно рассказал мой коллега Вадим Стеркин в своём блоге: Как выполнять задачи с полными правами обычным пользователем без ввода пароля администратора
. Способ отличный для своих задач, в моей же статье речь пойдёт о рисках и безопасности выполнения интерактивных программ от имени других пользователей, где полной автоматизации достичь нельзя и есть необходимость взаимодействия с интерфейсом.
Самое важное, что должен уяснить администратор — из запущенной программы с повышенными правами не должно быть возможности запустить другую произвольную программу, поскольку права автоматически наследуются. Прежде чем вообще планировать создавать ярлык для запуска, следует самостоятельно убедиться, что в программе нет окон открытия других файлов или запуска справки с собственной программой обработки, где дополнительно можно вызвать диалог открытия других файлов справки, и тому подобные в данном случае уязвимости, которые позволят пользователю запустить произвольную программу с правами администратора. Ещё пример — программа при определённых или редких обстоятельствах открывает логи в блокноте, а уже там есть диалог открытия других файлов, вот и готовая уязвимость. То есть целевая программа должна быть изучена администратором вдоль и поперёк (а ещё лучше — написана самостоятельно), чтобы пользоваться ей было действительно безопасно.
RunAs из коробки
В системе есть родная утилита runas, позволяющая выполнять задачу запуска от другого имени, однако пользоваться ей нужно осторожно и в целях безопасности её нельзя применять для запуска программ с повышенными привилегиями, но можно наоборот — администратору запускать программы с правами обычного пользователя, хотя технически возможны оба варианта. Почему так? Параметр /savecred позволяет сохранить пароль для пользователя, от имени которого запускается программа, в профиле пользователя, который запускает программу. Однако этот же сохранённый пароль RunAs использует и для запуска любых других программ, запуск которых может инициировать пользователь, у которого сохранён пароль.
Вывод — использовать родной runas в составе системы для повышения прав на постоянной основе (с сохранением пароля) категорически нельзя, эта уязвимость должна быть очевидна каждому сисадмину. Да и без сохранения пароля вводить пароль администратора под ограниченным пользовательским сеансом не рекомендуется, если там заранее не были предприняты меры предосторожности, которые не позволяют запускать произвольные программы (SRP, AppLocker), иначе пользователь может запросто перехватить пароль. А мы переходим к неочевидным уязвимостям.
AdmiLink и его армия
Попыток преодолеть небезопасность стандартного runas предпринято множество, тысячи их
. Самые известные — AdmiLink, CPAU, Encrypted RunAs и другие. Всех их объединяет конечный способ запуска, который мы разберём далее. В целом алгоритм работы этих программ такой: берём имя и пароль пользователя, от имени которого будет выполняться запуск целевой программы (как правило с правами администратора), добавляем к нему путь и контрольную сумму исполняемого файла (чтобы его нельзя было подменить на произвольный), и всю эту информацию дико шифруем
, чтобы расшифровать могла только авторская программа, и желательно только на том же компьютере. Проблема в том, что вся эта защита не имеет никакого смысла, поскольку имя и пароль администратора можно перехватить тогда, когда он уже будет расшифрован. Дополнительная проблема в том, что авторы этих программ об этом не подозревают и убеждают системных администраторов в безопасности своих разработок:
Так вот, AdmiLink — это очень неплохой «кирпич» в системе защиты, задачей которого является БЕЗОПАСНЫЙ ЗАПУСК программ. Безопасный запуск означает, что:
Пользователь не сможет узнать пароль Администратора через ярлык запуска.
Пользователь не сможет запустить не разрешенную Администратором программу, даже подменив исполняемый файл или командную строку в ярлыке.
Как работает RunAs и аналоги
Получение учётных данных администратора происходит по следующей цепочке:
Пользователь с ограниченными правами запускает ярлык, в котором хорошо зашифрованы данные для запуска программы.
RunAs или его аналоги проверяют корректность шифра и целостность программы, затем извлекают данные и в открытом виде передают их функции CreateProcessWithLogonW.
В это же время API-мониторинг перехватывает данные, переданные функции в качестве параметров, чем делает бессмысленным шифрование пароля и полностью компрометирует учётные данные администратора.
Всё пропало?
Какие меры нужно принять, если на вашем сервере использовался такой способ запуска программ для пользователей? В первую очередь нужно поменять пароли администраторов и провести аудит системы, не было ли взлома с использованием этой уязвимости. Если у вас был запрещён запуск всех посторонних программ, это слегка снижает градус проблемы, но только слегка — нужно убедиться, что пользователям не были доступны для записи те папки, из которых им был разрешён запуск программ, а добраться до них можно разными способами: кроме проводника, где доступ к ФС можно ограничить твиками, как минимум в систему встроены командная строка и PowerShell, запретить их запуск ограниченным пользователям тоже нужно было заранее. Имея же учётные данные администратора на руках, пользователь уже не ограничен ничем и все данные на таком сервере следует считать скомпрометированными. Помните, что безопасность сервера это комплексная мера, и она достигается суммой правильно настроенных параметров, многие из которых здесь не упомянуты.
Есть ли альтернативы?
Они как бы и есть, и их как бы нет. На данный момент мне известно об одной — RunAsRob
, которая использует другой метод: вместо запуска программы от имени другого пользователя она по заранее сформированному списку разрешённых программ временно выдаёт права администратора запускаемой программе посредством службы, работающей от имени системы. Благодаря такому подходу исключается утечка учётных данных, а разграничивать доступ к целевым программам нужно NTFS-правами. На данный момент я не могу её рекомендовать, так как она платная и глючная, однако за неимением других в крайнем случае можно использовать эту. Для неинтерактивных программ однозначно лучше использовать планировщик с вызовом по событию в журнале.
Предоставить пользователю права на запуск программы
Программа может запрашивать права администратора при запуске, если:
- Программе нужно получить доступ на системный каталог или файл, на отсутствуют NTFS разрешения для непривилегированных пользователей;
- Если программа собрана со специальным флагом, которые требует повышения прав при запуске (requireAdministrator).
В первом случае для решения проблемы администратору достаточно предоставить RW или Full Control разрешения на каталог программы или необходимый системных каталог. Например, программа хранит свои файлы (логи, файлы конфигурации и т.д.) в собственной папке в C:\Program Files (x86)\SomeApp) или каком-то системном каталоге. Для корректной работы программы пользователю нужны права записи в эти файлы. По умолчанию у пользователей нет прав на редактирование данного каталога, соответственно, для нормальной работы такой программы нужны права администратора.
Чтобы найти список файлов, папок и ключей реестра, к которым обращается программа, воспользуйтесь утилитой Process Monitor ( https://learn.microsoft.com/en-us/sysinternals/downloads/procmon
). Включите фильтр по имени процесса программы и найдите все ресурсы, при доступе к которым появляется Access Denied. Предоставьте необходимые права на папки/файлы/ветки реестра.
Примечание
. В рекомендациях Microsoft для разработчиков указано, что не рекомендуется хранить изменяющиеся данных приложения в каталоге C:\Program Files неверна. Правильнее хранить данные приложения в профиле пользователя. Но это уже вопрос о лени и некомпетентности разработчиков программ.
Запуск программы, требующей права администратора, от обычного пользователя
Ранее мы уже описывали, как можно с помощью параметра RunAsInvoker отключить запрос UAC для конкретной программы
. Однако этот метод недостаточно гибкий.
Рассмотрим более простой способ принудительного запуска любой программы без прав администратора (и без ввода пароля админа) при включенном UAC (4,3 или 2 уровень ползунка UAC
).
Для примера возьмем утилиту редактирования реестра — regedit.exe
(она находится в каталоге C:\windows\). Обратите внимание на щит UAC у иконки. Данный значок означает, что для запуска этой программы будет запрошено повышение привилегий через UAC.
cmd /min /C "set __COMPAT_LAYER=RUNASINVOKER && start "" %1"
Теперь для принудительного запуска приложения без прав администратора и подавлением запроса UAC, просто перетащите нужный exe файл на этот bat файл на рабочем столе.
Редактор реестра должен запуститься без появления запроса UAC и без ввода пароля администратора. Откройте диспетчер процессов, добавьте столбец Elevated
и убедитесь, что в Windows запушен непривилегированный процесс regedit (запущен с правами пользователя).
Аналогичным образом через bat файл можно запускать и конкретное приложение, достаточно указать путь к исполняемому файлу.
Set ApplicationPath="C:\Program Files\MyApp\testapp.exe"
cmd /min /C "set __COMPAT_LAYER=RUNASINVOKER && start "" %ApplicationPath%"
Windows Registry Editor Version 5.00 [HKEY_CLASSES_ROOT\*\shell\forcerunasinvoker] @="Run as user without UAC elevation" [HKEY_CLASSES_ROOT\*\shell\forcerunasinvoker\command] @="cmd /min /C \"set __COMPAT_LAYER=RUNASINVOKER && start \"\" \"%1\"\""
Еще раз напомню, что использование программы в режиме RUNASINVOKER не запускает приложение с правами администратора. Параметр AsInvoker подавляет запрос UAC и указывает программе, что она должна запуститься с правами текущего пользователя и не запрашивать повышение привилегий. Если программе действительно нужны повышенные права для редактирования системных параметров или файлов, она не будет работать или повторно запросит права администратора.
Запуск программы в режиме RunAsInvoker из командной строки
Переменная окружения __COMPAT_LAYER позволяет устанавливать различные уровни совместимости для приложений (вкладка Совместимость
в свойствах exe файла). С помощью этой переменной можно указать настройки совместимости, с которыми нужно запускать программу. Например, для запуска приложения в режиме совместимости с Windows 7 и разрешением 640×480, установите:
set __COMPAT_LAYER=Win7RTM 640x480
Из интересных нам опций переменной __COMPAT_LAYER можно выделить следующие параметры:
- RunAsInvoker
— запуск приложения с привилегиями родительского процесса без запроса UAC; - RunAsHighest
— запуск приложения с максимальными правами, доступными пользователю (запрос UAC появляется, если у пользователя есть права администратора); - RunAsAdmin
— запустить приложение с правами администратора (запрос AUC появляется всегда).
Следующие команды включат режим RUNASINVOKER для текущего процесса и запускает указанную программу:
start "" "C:\Program Files\MyApp\testapp.exe"
Включить режим RunAsInvoker в манифесте exe файла программы
Как мы уже говорили выше, Windows показывает значок щита UAC у программ, которые требуют повышенных привилегий для запуска. Это требование разработчики задают при разработке в специальной секции программы — манифесте.
Вы можете отредактировать манифест исполняемого exe файла программы и отключить требование запускать программу в привилегированном режиме.
Для редактирования манифеста программы можно использовать бесплатную утилиту Resource Hacker
. Откройте исполняемый файл программы в Resource Hacker.
В дереве слева перейдите в раздел Manifest
и откройте манифест программы. Обратите внимание на строки:
<requestedPrivileges> <requestedExecutionLevel level="requireAdministrator" uiAccess="false"/> </requestedPrivileges>
Обратите внимание, что теперь у иконки программы пропал щит UAC и вы можете запустить ее без запроса прав администратора с привилегиями текущего пользователя.
Если исполняемый файл программы подписан цифровой подпись ( сертификатом Code Signing
), то после модификации exe файла, он может перестать запускаться или выдавать предупреждение.
Чтобы Windows при запуске приложений всегда пробовала использовать внешний файл манифеста, включите специальный параметр реестра:
REG ADD "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\SideBySide" /v PreferExternalManifest /t REG_DWORD /d 1 /f
Перезагрузите Windows и убедитесь, что программа использует внешний файл манифеста, и запускается без прав администратора.
Запуск программы с сохраненным паролем администратора
Если способы запуска программы через режим RunAsInvoker
не работают для вашего устаревшего приложения, можно попробовать запускать такие программы в сессии пользователя с помощью сохраненного пароля администратора. Этот способ мы целенаправленно оставили последним, т.к. это наименее безопасный способ запуска программ без предоставления прав локального администратора пользователю.
Создайте на рабочем столе новый ярлык для запуска программы. Укажите имя компьютера, имя локального администратора и полный путь к исполняемому файлу программы.
Запустите ярлык под пользователем. При первом запуске откроется командная строка, в которой нужно будет указать пароль администратора.
Утилита RunAs
при запуске с параметром /SAVECRED
сохраняет имя пользователя и пароль в диспетчере паролей Windows
(Credentials Manager).
При следующем запуске ярлыка утилита runas автоматически получит сохраненный пароль из Credentials Manager и использует его для запуска программы от имени указанного локального администратора (пароль не запрашивается повторно при каждом запуске).
Вы можете вывести список пользователей с сохраненными паролями в Credential Manager с помощью команды:
В Windows 11 при запуске такого ярлыка появляется ошибка:
RUNAS ERROR: Unable to run - C:\CorpApp\myapp.exe 740: The requested operation requires elevation.
Чтобы исправить ошибку, отредактируйте команду в свойствах ярлыка. Замените ее на:
Как мы указывали выше, использование параметра
/savecred
не безопасно, т.к. пользователь, в чьем профиле сохранен чужой пароль может использовать его для запуска любой
программы или команды под данными привилегиями, или даже сменить пароль пользователя
с правами администратора. Кроме того, сохраненные пароли из Credential Manager можно получить в открытом виде с помощью утилит типа Mimikatz
, лучше <запретить использование сохраненных паролей.
В Windows можно заблокировать возможность сохранения паролей в Credential Manager с помощью параметра групповой политики Network access: Do not allow storage of passwords and credentials for network authentication
(Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options).
Преодолеть недостаток использования сохраненного пароля через runas позволяют несколько сторонних утилит. Например, AdmiLink
, RunAsRob
, RunAsSpc
. Эти программы позволяют сохранить пароль администратора в зашифрованном виде и безопасно запустить программу с правами администратора. Эти утилиты проверяют при запуске путь и контрольную сумму исполняемого файла и не позволят запустить произвольную программу.
Любой пользователь Windows может запустить в своей сессии программу от имени другого пользователя
с помощью Run As
. Благодаря этому вы можете выполнить скрипт (.bat, .cmd, .vbs, .ps1), запустить исполняемый .exe файл или установку приложения (.msi, .cab) с полномочиями другого пользователя.
Например, вы можете использовать RunAs для установки программ или запуска программ/скриптов/MMC оснасток с правами администратора непосредственно в сессии обычного непривилегированного пользователя. Также через RunAs вы можете запустить приложение, настроенное в профиле другого пользователя (приложение загрузится с настройки из профиля другого пользователя).
За возможность запуска программ от имени другого пользователя в Windows отвечает служба Вторичный вход в систему
(Secondary Log-on). Если эта служба остановлена, тогда все описанные методы runas работать не будут. Вы можете проверить, что служба запущена с помощью следующей команды PowerShell
:
В Windows есть несколько способов запустить программу или процесс от имени другого пользователя.
Запуск программы от имени другого пользователя из Проводника Windows (File Explorer)
Примечание
. Если пункт меню « Запуск от имени другого пользователя
» отсутствует, см. следующий раздел.
В появившемся окне Windows Security нужно указать имя и пароль пользователя, под чьей учетной записью нужно запустить программу и нажать кнопку ОК
.
- Если нужно запустить программу от имени пользователя Active Directory, нужно указать его имя в формате userPrincipalName
(
[email protected]) или samAccountName (
DomainName\UserName);
- Если ваш компьютер добавлен в домен AD, то для запуска программы от имени локальной учетной записи пользователя ее имя нужно указать в формате:
.\localusername.
Важно
. Вы можете запустить программу от имени другого пользователя только, если для него задан пароль. Использовать Runas для пользователя с пустым паролем не получится.
Откройте Диспетчер задач и убедитесь, что приложение запущенно под указанным пользователем.
Запуск программ от имени из командной строки
В Windows есть консольная утилита runas.exe
, которую можно использовать для запуска приложений от имени другого пользователя из командной строки. Также команда runas позволяет сохранить пароль пользователя в Windows Credential Manager, чтобы его не приходилось набирать каждый раз.
Совет
. Если имя пользователя содержит пробелы, его нужно взять в кавычки:
Можно, например, открыть панель управления под другим пользователем:
Введите пароль для corp\server_admin: Попытка запуска C:\Windows\notepad.exe C:\tmp\2871997x64.txt от имени пользователя "corp\server_admin" .
Если указали несуществующее имя пользователя или неверный пароль, появится ошибка:
RUNAS ERROR: Unable to run - yourcommand 1326: The user name or password is incorrect.
RUNAS ERROR: Unable to acquire user password
Иногда нужно запустить программу от имени доменного пользователя с компьютера, который не добавлен в домен AD
. В этом случае нужно использовать такую команду (при условии, что в сетевых настройках
вашего компьютера указан DNS сервер, который может отрезолвить этот домен):
Если для запуска программы от другого пользователя не нужно загружать его профиль, используйте параметр /noprofile
. При этом приложение запускается намного быстрее, но может вызвать некорректную работу программ, которые хранят данные в профиле пользователя.
Использование RunAs в PowerShell
Если вам нужно запускать программы/процессы от имени другого пользователя из PowerShell, вы можете использовать командлет Start-Process ( управление процессами с помощью PowerShell
). Сначала нужно запросить учетную запись и пароль пользователя:
$Cred = (Get-Credential)
Для запуска процесса от имени другого пользователя можно использовать:
Start-Process -FilePath "powershell.exe" -Credential $Cred
Либо можно запросить учетную запись и пароль интерактивно через Windows Security:
Если вам нужно запустить программу через runas от имени другого администратора в привилегированном режиме (по умолчанию UAC запускает программу в not-elevated пользовательском контексте), можно использовать такую команду PowerShell:
Или стороннюю утилиту ShelExec:
ShelExec /Verb:runas cmd.exe
Запуск программ от имени другого пользователя без ввода пароля
Вы можете сохранить пароль пользователя, который вы вводите. Для этого используется параметр /savecred
.
После указания пароля он сохранится в диспетчере паролей Windows
.
При следующем запуске команды runas под этим же пользователем с ключом
/savecred
Windows автоматически получит сохраненный пароль из Credential Manager
, и не будет запрашивать его повторно.
Чтобы вывести список всех пользователей, для которых сохранены пароли, используется команда:
Однако использование параметра /savecred не безопасно, т.к. пользователь, в чьем профиле сохранен чужой пароль может использовать его для запуска любой
команды под данными привилегиями, или даже сменить
чужой пароль. Кроме того, сохраненные пароли из Credential Manager можно легко украсть, поэтом лучше запретить использование сохраненных паролей
(а тем более нельзя сохранять пароль привилегированной административной учетной записи
).
Примечание
. Кроме того, ключ /savecred не работает в Home редакциях Windows.
Аналогичным образом можно запустить любую другую оснастку (главное знать ее имя).
Ярлык с запуском программы от имени другого пользователя
Вы можете создать на рабочем столе ярлык для запуска программы от имени другого пользователя. Просто создайте новый ярлык, в окне с адресом объекта которого укажите команду
с нужными параметрами:
При запуске такого ярлыка будет запрашиваться пароль пользователя.
Если в ярлыке runas добавить параметр
, то пароль будет запрошен только один раз. После этого пароль будет сохранен в Credential Manager и автоматически подставляться при запуске ярлыка от имени другого пользователя без запроса пароля.
Такие ярлыки довольно часто используются для запуска программ, которые требуют прав администратора для запуска. Однако есть более безопасные способы запуска программы без прав администратора
, или отключения запроса UAC для определенного приложения
.
В проводнике Windows отсутствует пункт “Запуск от имени другого пользователя”
В Windows вы можете скрыть или показать в проводнике пункт меню RunAs с помощью двух параметров реестра:
- Параметр HideRunAsVerb
(тип REG_DWORD) в ветке реестра HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\Explorer (1 – скрыть пункт runas, 0 – показать) - Параметр EnableSecureCredentialPrompting
(REG_DWORD) в HKLM\ Software\Microsoft\Windows\CurrentVersion\Policies\CredUI (1 – скрыть, 0 – показать)
Второму параметру реестра соответствует отдельная опция GPO.
Как добавить пункт “Запуск от имени” для программ в меню Пуск?
Осталось обновить групповые политики
(gpupdate /force) и убедиться, что у программ в меню Пуск появится новое контекстное меню Дополнительно
-> Запуск от имени другого пользователя
.
Пункт “запуск от имени” отсутствует у Universal Windows Platform (UWP) приложения из Microsoft Store. Вы можете запустить UWP приложение от другого пользователя из командной строки с помощью runas.exe.
Выведите список приложений Microsoft Store на компьютере с помощью PowerShell:
Можно найти конкретное приложение
Найдите имя нужного приложения в списке. Например, для запуска встроенного клиента Microsoft Teams Chat
от другого пользователя, выполните:
