Windows 8 запуск программы от другого пользователя

[---Zak---]

Добрый день всем.

В данной статейке хотел бы Вам немного рассказать о небольших хитростях и "новшествах" в новой Windows 8.

Тема топика будет о запуске программы от другого пользователя, которая по-умолчанию в ОС заблокирована. Хотя возможно у кого-то имеется другая версия ОС, где как раз есть возможность запуска от другого пользователя - пожалуйста не путайте с "Run as administrator". Но у меня имеется Windows 8 скачанная еще на стадии тестирования - без всякого рода патчей, активаций и т.п.

Немного об истории:
Началось все с того, что появилась идея создания программы, которая создает службу и автоматически запускается при запуске компьютера/ноутбука. В последующем эта служба должна запускать еще одну программу, но уже от имени текущего пользователя.
Суть в том, чтобы сэкономить финансовую сторону в фирме и любыми средствами подружить Windows XP/7/8 Home с доменом, при условии - в домене запрещено заходить в "расшаренные" папки на компьютерах/серверах домена от имени "гость"/"все".

Идея заключалась в недокументированном ключе /separate при запуске explorer.exe - иначе это можно рассудить как:

; Fill in the username and password appropriate for your system.
Local $sUserName = "Administrator"
Local $sDomainName = "DOMAIN.RU"
Local $sPassword = "Password"

; Run a command prompt as the other user.
$Run = RunAs($sUserName, $sDomainName, $sPassword, 0, "explorer /separate")

MsgBox(0, "RunAs", "Return RunAs = "&$Run)

В данном примере при условии, что мы указали домен и данные о пользователе домена (логин и пароль) у нас запускается еще один "проводник" от имени пользователя домена и в последующем мы сможем использовать этот проводник для входа в "расшаренные" папки на компьютеры/сервера домена.

Чтобы было немного удобнее на завершение скрипта мы получаем PID запущенного процесса или ошибку.

Return Value
Success: The PID of the process that was launched.
Failure: Returns 0 and sets @error to non-zero.

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

Я не буду рассказывать какими средствами создавать GUI, чтобы пользователь сам вводил необходимые данные для домена, а так же не буду рассказывать где и насколько желательно зашифровать (хотя бы по минимуму) пароль от домена. Еще все это дело удобно будет поместить в трэй и запускать от туда.

Возможно у кого-то из Вас возникнет вопрос:
" - А зачем тебе именно служба, которая будет еще запускать дополнительный файл ? Не проще ли будет поместить файл в автозагрузку ?"
" - Служба по сути готовилась для других целей: автозагрузка - это хорошо, но есть одно НО (!!!) - файл помещенный в автозагрузку пользователь через диспетчер задач может легко завершить. Блокировать диспетчер задач - это не для нас. Лично я против каких-либо блокировок и некультурного вмешательства в работу ОС. Однако и службу можно будет завершить... На помощь придет групповая политика, которая запретит остановку служб - это для доменных пользователей. А для других - это их личное право."
PS: да и по сути интересно как все это работает и познание в данном вопросе + служба запускается от имени SYSTEM, которая имеет больше прав на систему.

Способ неплохо работает на Windows XP/7, но ничто не стоит на месте добираемся и до Windows 8.

И так на данном этапе мы имеем:

• Непосредственно домен с пользователями в AD
• Компьютер Windows 8 x86 (я развернул да виртуальной машине)

Данные:
О ДОМЕНЕ (непосредственно домен с пользователями в AD):

• Имя домена - "DOMAIN.RU"
• Имя пользователя в домене - "Administrator"
• Пароль от пользователя в домене - "Password"
• Сеть из компьютеров в домене с "расшареными" папками с выключенными правами такими как "гость/все"

О WINDOWS 8 (я развернул да виртуальной машине):

• Локальный пользователь
• Состоит в рабочей группе, которая не имеет доступ к домену "DOMAIN.RU"

PS: Опустим момент выдачи IP адресов и остальное.

About Windows 8:


"Расшаренная" папка на компьютере домена с необходимыми правами:


Ошибка Windows 8 из рабочей группы:
P7cZQyE.jpg" width="" />​

Предлагаю скомпилировать выше указанный пример и запустить его же на компьютере Windows 8. Если мы получим новый экземпляр explorer.exe, то дальнейший разговор думаю вообще не будет иметь смысла...
Не буду загадывать что получили Вы, а предоставлю свой скрин:

​

Хотя, если запустить "explorer /separate" из командной строки мы все же получим очередной экземпляр explorer:

​

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

И так приступим к действиям:
* На помощь нам придет Process Explorer (скачать).

Закрываем второй экземпляр explorer и запускаем Process Explorer. Как видим запушен один экземпляр explorer - отлично. Запускаем "explorer /separate" из командной строки и смотрим что с ним не так.
Как видим через свойства новый explorer запустился с ключом - {75dff2b7-6936-4c06-a8bb-676a7b00b24b}

​

Первое, что приходи в голову - это найти его в реестре, с надежностью, что куда-то это нас должно привести. Запускаем regedit и через поиск ищем ключ:

​

Первое что нашлось: HKEY_CLASSES_ROOT\CLSID с названием: "Separate Multiple Process Explorer Host" - есть какие-то незамысловатые слова по смыслу видимо отвечают за запуск explorer.

Так же передается параметр AppID - {CDCBCFCA-3CDC-436f-A4E2-0E02075250C2} - ищем его:

​

И так нашли, но уже с другим параметром: Elevated-Unelevated Explorer Factory, а так же если заметим есть еще один параметр RunAs со значением Interactive User указывающий на тип запуска программ.

Если долго мучиться, чтонибудь получится:
После долгих изучений Elevated-Unelevated Explorer Factory нашелся в "Службы компонентов" ("dcomcnfg.exe"), а именно в "Настройка DСOM"

​

Заходим в свойства компонента на вкладку "Удостоверение" - видим, что запуск программ происходит от "Текущий пользователь", который в добавок еще и заблокирован.

​

ВНИМАНИЕ (!!!) Все изменения вносимые в реестр или настройки ОС могут повлиять на работоспособность ОС. Использовать на свой страх и риск !!!

Мысль: ключ в реестре равен этим значениям - лезем в реестр и пробуем сделать что-либо с данным параметром. Но суть в том, что его не изменить - у нас нет необходимых прав. Даже, если зайти в свойства ключа {CDCBCFCA-3CDC-436f-A4E2-0E02075250C2} и предоставить доступ будет ошибка прав.
Но все мы знаем, что если сменить владельца на ресурс - выставить права появится возможность:

​

Рядом с владельцем меняем права на группу "Администраторы" нажимаем кнопку ОК и далее добавляем себе права в реестре на этот ключ.
ЗЫ: по секрету - данный параметр может изменить пользователь SYSTEM.

Перезапускаем "Службы компонентов" ("dcomcnfg.exe") и возвращаемся к компоненту Elevated-Unelevated Explorer Factory. Смотрим на вкладку "Удостоверение" - теперь нам разрешено менять параметры вкладки.

​

Меняем параметр с "Текущий пользователь" на "Запускающий пользователь"...
PS: для наблюдения перезапускаем regedit.exe и возвращаемся к {CDCBCFCA-3CDC-436f-A4E2-0E02075250C2}. Здесь мы видим, что параметр RunAs со значением Interactive User удалился. Как итог можно рассуждать, что данный параметр в реестре как раз отвечает за запуск от другого пользователя.

Т.к. это изменения в реестре, то для вступления их в силу - необходимо перезагрузить компьютер.

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

​

К сожалению я еще не добрался до момента, когда можно из Windows * Home запускать чего-либо от пользователей в домене, но мы не стоим на месте, а пробуем и верим в чудеса.
По каким причинам не подхватывается пользователь из домена - пока еще не знаю, но видимо где-то стоит блокировка, что запуск программ может быть только от "имени компьютера".

Но успехов мы все же добились даже на текущий момент, а именно: все же можно запускать программы от других пользователей.
Это пригодится в том случаи:

• если у Вас имеется Windows 8 Pro в домене, на которой есть учетная запись домена с правами обычного пользователя (не администратора)
• если у Вас компьютер не в домене и в нем есть два пользователя - один обычный, а другой администратор

Я в системе создал двух пользователей:

• USER - обычный пользователь с паролем "test"
• TEST - администратор компьютера с паролем "1Q2w3e4r"

; Fill in the username and password appropriate for your system.
Local $sUserName = "test"
Local $sPassword = "1Q2w3e4r"

; Run a command prompt as the other user.
$Run = RunAs($sUserName,  @ComputerName, $sPassword, 0, "explorer.exe /separate")
MsgBox(0, "RunAs", "Return RunAs = "&$Run)

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

Скрин диспетчера задач:

​

Комментарии:

• Зеленым цветом подчеркнул все, что связанно с текущим пользователем
• Красным цветом подчеркнул все, что связанно с другим пользователем - от которого и был произведен запуск
• Синим цветом - результат PID, который вернул AutoIt и который стоит по факту в диспетчере задач - они различаются.

 

[InnI]

Где-то я это читал... только для Win7
Ну, точно. Здесь http://www.outsidethebox.ms/12317/

 

[---Zak---]

2 InnI
На Windows 7 у меня как-то не возникло проблем запуска программ от другого пользователя. У меня служба в XP и 7 без проблем запускает программу от текущего пользователя.

Знал бы прикуп - жил бы в Гаграх)))))

Я на это все потратил 3 суток и искал такие статьи в интернете - но увы и ах, а уже после столкнулся с этой статьей. Сейчас тоже не теряю надежду найти статью, каким способом запустить от доменного имени на компьютере не в домене.

ЗЫ: вспоминай - может есть такая статья в инете ?
ЗЫЫ: на этом сайте я такого не нашел, но я думаю все равно способ должен быть. Сетевые диски можно подключать таким способом - по идеи значит и запускать можно - надо только знать как.

На счет запуска программ - раньше была возможность: берешь пользователя с его паролем из рабочей группы и в домене создаешь точно такого же пользователя с тем же паролем в AD (может еще какие манипуляции). Но суть в том, что этому пользователю предоставлялся доступ.

 

[vovsla]

Я тоже столкнулся с проблемой RunAs в Win8, решил все вот таким способом.

RunAsWait('oem', @ComputerName, 'pass', 0, @ComSpec&' cmd /c start %Systemroot%\System32\sysprep\sysprep.exe /quiet /oobe /generalize /shutdown /unattend:%Systemdrive%\Sysprep\Sysprep\XML\Presale2.xml', '',  @SW_HIDE)

т.е. с помощью RunAs запускаю консоль которая в свою очередь запускает приложение