Не работает команда runas

Ошибка при использовании команды runas, параметра Run as Administrator или run в качестве другого пользовательского параметра после обновления Windows Server: доступ отказано

В этой статье приводится ряд обходных способов решения проблемы, в которой после обновления Windows Server нельзя использовать команду, параметр Run as Administrator или Run в качестве другого runas пользовательского параметра.

Применяется к: Windows Server 2012 R2
Исходный номер КБ: 977513

Симптомы

Рассмотрим следующий сценарий.

• Вы обновляете компьютер с Windows Server.
• Вход в качестве стандартного пользователя.
• Вы пытаетесь использовать одну из следующих функций:
  • runas команда
  • Запуск в качестве параметра Администратор
  • Запуск в качестве другого пользовательского параметра

В этом сценарии вы получите следующее сообщение об ошибке:

Причина

Список управления дискреционным доступом (DACL) для службы Secondary Logon неправильно задаваем при обновлении Windows Server. Эта проблема не позволяет обычному пользователю запускать эту службу и запускать приложение в качестве другого пользователя.

Обход 1. Использование Sc.exe командной подсказок

Вы можете использовать командную Sc.exe для настройки безопасности по умолчанию после обновления сервера.

Прежде чем запускать эти команды, необходимо войти в систему в качестве администратора.

Для этого выполните указанные ниже действия.

Откройте окно командной строки.

В командной строке введите следующую команду, а затем нажмите клавишу ВВОД:

В командной строке введите следующую команду, а затем нажмите клавишу ВВОД:

Эта команда завернута для читаемости.

Закройте окно командной строки.

Попробуйте использовать одну из следующих функций:

• runas команда
• Запуск в качестве параметра Администратор
• Запуск в качестве другого пользовательского параметра

Кроме того, убедитесь, что вы можете переключить пользователей и что служба Secondary Logon запускается правильно.

Обходное решение 2. Использование групповой политики

Консоль управления групповой политикой можно настроить политику на основе домена, которая задает безопасность конфигурации по умолчанию после обновления сервера. Для этого обхода необходимо создать новый объект групповой политики (GPO). И его следует связывать так, чтобы новый GPO применялся только к затронутым компьютерам.

Для этого выполните указанные ниже действия.

Изменение групповой политики в консоли управления групповой политикой.

Найдите политику: Конфигурация компьютера\Политики\Windows Параметры\Security Параметры\System Services.

Откройте службу Secondary Logon.

Выберите поле Определение этого параметра политики, а затем выберите Включено.

Установите режим запуска службы в ручном режиме.

Расширйте узел безопасности, чтобы убедиться, что задаются следующие свойства и объекты.

Свойство	Объекты
Пользователи, прошедшие проверку	Шаблон запроса, состояние запроса, иждивенцы, начните, приостановите и продолжите, допрашивайте, считывайте разрешения, User-Defined управление
Builtin\Administrators	Полный доступ
Интерактивны	Шаблон запроса, состояние запроса, иждивенцы, начните, приостановите и продолжите, допрашивайте, считывайте разрешения, User-Defined управление
Служба	Шаблон запроса, состояние запроса, иждивенцы, пауза и продолжение, опрос, User-Defined управление
Системные	Шаблон запроса, состояние запроса, иждивенцы, запуск, пауза и продолжение, допрос, остановка

Выберите ОК, чтобы применить изменения безопасности.

Выберите ОК для применения изменений групповой политики.

Применить GPO к затронутым компьютерам, ожидая обновления групповой политики или запуска обновления вручную.

Попробуйте использовать одну из следующих функций:

• runas команда
• Запуск в качестве параметра Администратор
• Запуск в качестве другого пользовательского параметра

Кроме того, убедитесь, что вы можете переключить пользователей и что служба Secondary Logon запускается правильно.

Мы не рекомендуем это обходное решение, так как разрешения повторно в процессе обновления групповой политики. Однако исправить неправильную безопасность необходимо только один раз после обновления.

Дополнительная информация

Дополнительные сведения о команде runas можно получить на следующем веб-сайте Microsoft TechNet:

Дополнительные сведения об использовании консоли управления групповой политикой можно найти на следующем веб-сайте Microsoft TechNet:

Источник

Рунас не работает на Windows 10

Итак, у меня есть клиент, которому нужно запускать программное обеспечение с более высокими привилегиями, но пользователь работает с ограниченной учетной записью, и я не желаю давать ему пароль по нескольким причинам.

Я искал способ запустить программу без запроса пароля администратора, и я столкнулся с runas .

Это команда, которую я использую:

runas /user:Administrator /savecred «Путь \ К \ Software.exe»

Что происходит, так это то, что он запрашивает пароль в первый раз, но ничего не происходит после ввода пароля. Программа просто не запустится, независимо от того, сколько раз я запускаю команду.

Путь правильный и учетная запись администратора в порядке, по-прежнему безрезультатно.

Я также проверил, что запущены 2 службы (не помню их имен, но они связаны с запущенными приложениями с разными привилегиями).

У вас, ребята, есть решение, чтобы это работало?

4 ответа 4

Если на вашем компьютере включен контроль учетных записей (UAC) (я надеюсь, что ответ «да»), команда «runas» не повышает ваши привилегии. т.е. он запускает приложение, но не с правами администратора.

Однако попробуйте эту команду Windows PowerShell:

Естественно, вы должны вводить эту команду в Windows PowerShell вместо командной строки.

Тем не менее, это определенно не решение вашей проблемы. Политика Microsoft состоит в том, чтобы либо не предоставлять, либо полностью отказывать в любых средствах, поощряющих использование административных привилегий. (Эта политика вступила в силу после фиаско в области безопасности в 2003 году.) Ближайшая вещь, которую Microsoft предоставляет, — набор средств для обеспечения совместимости приложений, который позволяет игнорировать манифест приложения и запускаться с ограниченными привилегиями. Это делает трюк для приложений, которые достаточно глупы, чтобы не проверять, получили ли они то, что просили в своих манифестах.

Конечно, время от времени я замечаю сторонние решения по обеспечению безопасности, которые включают то, что вы хотите. За исключением непопулярности, они быстро исчезают.

Мы обнаружили, что если профиль runas не был полностью загружен (т. Е. UID runas не был полностью зарегистрирован на компьютере ранее), он не будет работать правильно .

Использование программы для хранения учетных данных будет плохим, независимо от того, как вы на это смотрите. Если пользователь способен получить какую-либо часть сохраненных учетных данных, он может расшифровать пароль (СОВЕТ: он сможет получить к ним доступ, иначе программа не будет работать), если только программа не использует некоторый токенизацию. , Даже в том случае, если он выполняет токенизацию, можно выполнять другие команды от имени администратора, если они «передают хэш», как они говорят в поле безопасности (токены не шифруются / дешифруются, насколько я могу судить, поэтому они были специально разделены, и даже если они есть / были, пользователь может их расшифровать).

Лучше всего, поскольку вы не хотите предоставлять этому пользователю права администратора, — предоставить ему определенный доступ к файлам и папкам, которые пытается использовать программа. Требуется больше информации о программе или файлах / папках, к которым осуществляется доступ, прежде чем можно будет дать хорошую рекомендацию. Если вы предоставите им доступ с помощью вкладки « Security » в окне свойств папки, они смогут запустить программу без прав администратора. Если нет, то программа была сделана не очень хорошо. В качестве альтернативы вы можете использовать виртуальную машину или другой рабочий стол, к которому пользователь может подключиться, чтобы иметь доступ только к этому, а не к системе, над которой он работает.

Если вы хотите увидеть, какие файлы и папки использует пользователь в Windows, вы можете использовать инструмент Process Monitor . Этот инструмент перечислит безумное количество информации, которую все процессы делают на машине (вы можете фильтровать данные). Файлы, папки, потоки, сетевые события, реестр и события профилирования отслеживаются инструментом. Это от SysInternals и части Sysinternals Suite, расположенного здесь, на TechNet . Я не имею к ним никакого отношения, но я использовал их инструменты в течение многих лет.

Единственное, что я обнаружил, что, по-видимому, является причиной того, что вы описываете, — это если учетная запись администратора не имеет установленного пароля, тогда он не будет запускаться таким образом, учетная запись должна иметь пароль, и вы должны ввести его, Вы не можете просто оставить его без пароля и нажать Enter, когда он попросит.

Когда я вижу, что такое поведение выдает ошибку об ограничениях учетной записи, оно не будет отображать ошибку достаточно долго, чтобы человек мог ее прочитать, если вы работаете с ярлыка, но сохранит ошибку, если она запускается из командной строки или powershell. окно.

Конечно, также убедитесь, что учетная запись администратора включена (это не по умолчанию) и что вы (или ваш ИТ-отдел, если это компьютер компании, а не ваш компьютер) не добавили какие-либо ограничения на основе GPO или другие ограничения для администратора учетная запись в состоянии запускать вещи. (Поскольку вы сказали, что учетная запись в порядке, я сомневаюсь, что причина в вашем случае, но в том числе и в случае, если другие люди должны знать это)

Источник

Runas: программа запускается, но не работает в учетной записи с ограниченными правами

Народ,нужна ваша помощь, уверен проблема решается за пару минут, но я уже три дня не могу справиться, т.к. совсем не программист (

Такая ситуация:
Есть программа (exe-шник), которая во время работы использует два файла, находящиеся в той же папке,при этом во время работы она записывает в эту папку txt файлы. На компе есть две учетные записи: Admin и user с ограниченными правами, папка с прогой у user’а заблокирована — задача запускать от user’а эту прогу через бат файл. (пароль есть)

почитав немного инфы про батники попробовал такую команду:

— прога не запускается

потом наткнулся в инете на похожую проблему написанную на этом форуме ( однако до конца решить проблему не смог, поэтому и написал именно тут)

при таком батнике работает полноценно в админской учетке, НО на юзере прога запускается но не работает ((
мне кажется дело именно в том что она файлы из папки использует при работе, а через юзера при таком коде что то не срабатывает.

Помощь в написании контрольных, курсовых и дипломных работ здесь.

Запуск батника с правами админа из под учетки с ограниченными правами
Здравствуйте. Есть батник. Так же есть учетка с ограниченными правами. Нужно что бы батник.

Какой командой можно перезапустить CMD c правами текущей учетной записи на удаленном ПК?
Здравствуйте. При использовании программы удаленного доступа, бат файлы запускаются в CMD с правами.

При запуске с помощью runas программа запускается, но не видит файлов которые должна использовать
Нужно добавить програмку в автозагрузку, но есть проблема сделать это нужно под учётной записью.

Создание учетной записи с ограниченными правами
Доброго времени суток. Необходимо создать вторую учетную запись для брата младшего. 1) Она была.

— прога не запускается

Решение

1) Создать ярлык к программе — Свойства — Вкладка «Ярлык», Дополнительно — Запускать от имени администратора;
Вкладка «Совместимость» — Запускать от имени администратора.

2) Планировщик
Советы от Microsoft (см. способ № 4)
или скачайте себе CCleaner, и сами посмотрите как он создает в «Планировщике задач» обход режима повышения привилегий.

4) Сторонней утилитой:
Рекомендую отечественную: AdmiLink
(не путать с платной).

Добавлено через 10 часов 55 минут
5) Вот еще проверил способ через PowerShell:

//взято с хабрахабр

P.S. Чтобы проверить сохраняем под именем Runas.ps1,
запускаем CMD от имени админа, печатаем (чтобы разрешить политику запуска неподписанных скриптов через Powershell):

6) Еще есть такая вещь как Native Shell
Это командная оболочка, запускаемая до входа в систему (там например любит сканировать винт на ошибки Chkdsk).
Так вот, там вообще нет такого понятия как права.
Если кому интересно, можете почитать здесь и здесь.

а) Если программа имеет установщик, переустановите ее из под обычного юзера (от имени администратора) с опцией установки «Для всех пользователей» (если такая имеется).
б) Попробуйте убрать ключ /env из команды Runas.

В крайнем случае попробуйте c помощью PsExec (позволяет запустить программу из-под учетной записи SYSTEM).

Вот еще тема (сохранение пароля runas через программу CPAU).

Bear74, кстати синтаксис CMD кавычку пропускает и не считает за ошибку.

7) Запуск через команду Runas ссылка

8) Запуск с отображением диалога элевации прав UAC посредством скомбинированного BAT-VBS скрипта ссылка

Источник

Проблема использования RunAs на серверах

В этой статье я подробно расскажу о проблемах, с которыми столкнётся каждый системный администратор, использующий в своей работе возможность запуска программ от имени другого пользователя, в большинстве случаев от имени администратора. Если вы — тот самый сисадмин, прочитайте её внимательно, скорее всего вам требуется срочная смена своего пароля.

Зачем это вообще нужно? Бывают ситуации, когда пользователю с ограниченными правами требуется выполнить программу, которой для выполнения специфической работы требуются повышенные права. Например, программисту нужно предоставить возможность завершать определённые процессы бухгалтерской программы, некоторым пользователям из бухгалтерии требуется возможность переключать ключи безопасности в интерактивном режиме и так далее. Часть этих задач можно выполнять неинтерактивно, при этом несколько страдает удобство, поскольку пользователь не видит интерфейс программы и может разве что получить системное сообщение о завершении работы программы, об этом способе подробно рассказал мой коллега Вадим Стеркин в своём блоге: Как выполнять задачи с полными правами обычным пользователем без ввода пароля администратора. Способ отличный для своих задач, в моей же статье речь пойдёт о рисках и безопасности выполнения интерактивных программ от имени других пользователей, где полной автоматизации достичь нельзя и есть необходимость взаимодействия с интерфейсом.

Самое важное, что должен уяснить администратор — из запущенной программы с повышенными правами не должно быть возможности запустить другую произвольную программу, поскольку права автоматически наследуются. Прежде чем вообще планировать создавать ярлык для запуска, следует самостоятельно убедиться, что в программе нет окон открытия других файлов или запуска справки с собственной программой обработки, где дополнительно можно вызвать диалог открытия других файлов справки, и тому подобные в данном случае уязвимости, которые позволят пользователю запустить произвольную программу с правами администратора. Ещё пример — программа при определённых или редких обстоятельствах открывает логи в блокноте, а уже там есть диалог открытия других файлов, вот и готовая уязвимость. То есть целевая программа должна быть изучена администратором вдоль и поперёк (а ещё лучше — написана самостоятельно), чтобы пользоваться ей было действительно безопасно.

RunAs из коробки

В системе есть родная утилита runas, позволяющая выполнять задачу запуска от другого имени, однако пользоваться ей нужно осторожно и в целях безопасности её нельзя применять для запуска программ с повышенными привилегиями, но можно наоборот — администратору запускать программы с правами обычного пользователя, хотя технически возможны оба варианта. Почему так? Параметр /savecred позволяет сохранить пароль для пользователя, от имени которого запускается программа, в профиле пользователя, который запускает программу. Однако этот же сохранённый пароль RunAs использует и для запуска любых других программ, запуск которых может инициировать пользователь, у которого сохранён пароль.

Рассмотрим это на примере: у нас есть Admin с правами администратора, User1 с необходимостью запуска программы от имени администратора, и все остальные пользователи, которые эту программу запускать не должны, назовём их условно User2, а тестовая программа — калькулятор (calc). Когда администратор хочет запустить программу от имени пользователя для проверки или из планировщика, он может сохранить пароль User1 в своём профиле, выполнив команду «runas /savecred /user:User1 calc», ввести пароль User1 и в дальнейшем для этой команды пароль запрашиваться не будет, но также он не будет запрашиваться и для других программ, помимо калькулятора. При этом User2, который выполнит у себя эту же команду, столкнётся с необходимостью ввода пароля для User1, поскольку в его профиле этот пароль заранее не сохранён. Такой сценарий допустим и безопасен, ведь администратор и так имеет полные права. Однако если мы выполним команду «runas /savecred /user:Admin calc» от имени User1 и введём пароль администратора, User1 сможет запускать любые программы от имени администратора, что полностью разрушает модель безопасности.

Вывод — использовать родной runas в составе системы для повышения прав на постоянной основе (с сохранением пароля) категорически нельзя, эта уязвимость должна быть очевидна каждому сисадмину. Да и без сохранения пароля вводить пароль администратора под ограниченным пользовательским сеансом не рекомендуется, если там заранее не были предприняты меры предосторожности, которые не позволяют запускать произвольные программы (SRP, AppLocker), иначе пользователь может запросто перехватить пароль. А мы переходим к неочевидным уязвимостям.

AdmiLink и его армия

Попыток преодолеть небезопасность стандартного runas предпринято множество, тысячи их. Самые известные — AdmiLink, CPAU, Encrypted RunAs и другие. Всех их объединяет конечный способ запуска, который мы разберём далее. В целом алгоритм работы этих программ такой: берём имя и пароль пользователя, от имени которого будет выполняться запуск целевой программы (как правило с правами администратора), добавляем к нему путь и контрольную сумму исполняемого файла (чтобы его нельзя было подменить на произвольный), и всю эту информацию дико шифруем, чтобы расшифровать могла только авторская программа, и желательно только на том же компьютере. Проблема в том, что вся эта защита не имеет никакого смысла, поскольку имя и пароль администратора можно перехватить тогда, когда он уже будет расшифрован. Дополнительная проблема в том, что авторы этих программ об этом не подозревают и убеждают системных администраторов в безопасности своих разработок:

Так вот, AdmiLink — это очень неплохой «кирпич» в системе защиты, задачей которого является БЕЗОПАСНЫЙ ЗАПУСК программ. Безопасный запуск означает, что:

Пользователь сможет запускать нужную программу с нужными правами.

Пользователь не сможет узнать пароль Администратора через ярлык запуска.

Пользователь не сможет запустить не разрешенную Администратором программу, даже подменив исполняемый файл или командную строку в ярлыке.

Как работает RunAs и аналоги

Этот момент хорошо разобрал Mick Grove в своей статье Capturing credentials from ‘Encrypted RunAs’ software ещё в 2013 году. Он заметил, что любой подобный софт не изобретает велосипед, а использует для запуска программ от имени другого пользователя стандартную функцию CreateProcessWithLogonW, которой в качестве параметров нужно передавать логин и пароль в открытом виде. А это в свою очередь означает, что запросы к функциям можно перехватить и просто прочитать их параметры, получив на руки логин и пароль администратора. Для мониторинга здесь использовалась бесплатная программа API Monitor, и что самое важное, для её запуска не нужны права администратора, она отлично работает в пользовательском пространстве, поскольку обращение к функции CreateProcessWithLogonW происходит именно в контексте пользователя, а уже сама функция осуществляет запуск процесса с заданными учётными данными, что и следует из её названия.

Получение учётных данных администратора происходит по следующей цепочке:

Пользователь с ограниченными правами запускает ярлык, в котором хорошо зашифрованы данные для запуска программы.

RunAs или его аналоги проверяют корректность шифра и целостность программы, затем извлекают данные и в открытом виде передают их функции CreateProcessWithLogonW.

В это же время API-мониторинг перехватывает данные, переданные функции в качестве параметров, чем делает бессмысленным шифрование пароля и полностью компрометирует учётные данные администратора.

Всё пропало?

Какие меры нужно принять, если на вашем сервере использовался такой способ запуска программ для пользователей? В первую очередь нужно поменять пароли администраторов и провести аудит системы, не было ли взлома с использованием этой уязвимости. Если у вас был запрещён запуск всех посторонних программ, это слегка снижает градус проблемы, но только слегка — нужно убедиться, что пользователям не были доступны для записи те папки, из которых им был разрешён запуск программ, а добраться до них можно разными способами: кроме проводника, где доступ к ФС можно ограничить твиками, как минимум в систему встроены командная строка и PowerShell, запретить их запуск ограниченным пользователям тоже нужно было заранее. Имея же учётные данные администратора на руках, пользователь уже не ограничен ничем и все данные на таком сервере следует считать скомпрометированными. Помните, что безопасность сервера это комплексная мера, и она достигается суммой правильно настроенных параметров, многие из которых здесь не упомянуты.

Есть ли альтернативы?

Они как бы и есть, и их как бы нет. На данный момент мне известно об одной — RunAsRob, которая использует другой метод: вместо запуска программы от имени другого пользователя она по заранее сформированному списку разрешённых программ временно выдаёт права администратора запускаемой программе посредством службы, работающей от имени системы. Благодаря такому подходу исключается утечка учётных данных, а разграничивать доступ к целевым программам нужно NTFS-правами. На данный момент я не могу её рекомендовать, так как она платная и глючная, однако за неимением других в крайнем случае можно использовать эту. Для неинтерактивных программ однозначно лучше использовать планировщик с вызовом по событию в журнале.

В вышеупомянутой статье дополнительно указывается Just Enough Administration (JEA), однако моё исследование этого инструмента показало, что им не получится пользоваться полноценно для интерактивного запуска приложений с окнами — так как процессы запускаются от имени другого виртуального администратора, то окна программ не будут видны для текущего пользователя. JEA может помочь в организации запуска автоматических скриптов и просмотра вывода результатов консольных программ, это определённо информативнее планировщика, но для работы с оконными приложениями не годится.

Можно ли запретить в системе мониторинг API для ограниченных пользователей и этим решить проблему перехвата системных функций — на данный момент мне не известно. Если вам есть что добавить к этой статье, оставьте свой комментарий.

P. S. RestAdmin — концепция безопасного Run As Admin (решение было разработано после этой статьи).

Источник