Проблемы с CreateProcessWithLogonW() - Необходимо запускать подпроцессы с одним и тем же пользователем

Question

У меня есть исполняемый файл Windows, который запускается из службы путем вызова CreateProcessWithLogonW() с набором определенных сведений о пользователе.

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

После прочтения статьи Microsoft о CreateProcess() - http://msdn.microsoft.com/en-us/library/ms682425 (ПРОТИВ 85).aspx

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

Как ни странно, когда я ранее использовал LogonUser() и CreateProcessAsUser() для запуска начального исполняемого файла в службе, это работало нормально.Но мне пришлось изменить это на CreateProcessWithLogonW() из-за проблем с отсутствием правильных привилегий.

Кто-нибудь знает о решении этой проблемы?Я видел разговоры об этом в другом месте в Интернете, но не с каким-либо определенным решением.Похоже, мне, возможно, нужен токен пользователя, с которым я вхожу в систему в CreateProcessWithLogonW(), чтобы я мог использовать его для запуска других процессов позже?Но у меня нет способа получить этот токен, можно ли каким-либо образом восстановить его для текущего пользователя?

Любая помощь была бы высоко оценена, спасибо :)

Answer 1

Являетесь ли вы владельцем кода, запущенного с помощью CreateProcessWithLogonW (и который, в свою очередь, вызывает CreateProcess)?Если вы этого не сделаете, то вам, возможно, потребуется выполнить Подключение IAT (или API) на нем (т.е.во время выполнения), чтобы заменить любые вызовы на CreateProcess с соответствующей процедурой, которая также использует CreateProcessWithLogonW или CreateProcessWithTokenW.Видишь АПИХиджак, Обходные пути.

После того, как это будет сделано, дочернему процессу может потребоваться доступ к HKCU.Если вы еще не делаете этого, вам следует загрузить профиль каждого олицетворяемого пользователя, по одному разу для каждого пользователя, перед вызовом CreateProcessWithLogonW.

По умолчанию CreateProcessWithLogonW не загружает указанного пользователя профиль в реестр HKEY_LOCALUSERS ключ.Это означает, что доступ к информации в HKEY_CURRENT_USER раздел реестра может не давать результатов которые соответствуют обычному интерактивному входу в систему.Вы несете ответственность за загрузку пользовательского раздела реестра в HKEY_LOCALUSERS перед вызовом CreateProcessWithLogonW, используя LOGON_WITH_PROFILE или вызов функции LoadUserProfile.

Answer 2

Мы решили проблему, используя какой-то код, который я нашел давным-давно.Раздел "Авторское право" одного из исходных модулей содержит следующее:

/////////////////////////////////////////////////////////////
// CreateProcessAsUser.cpp
// 
// Written by Valery Pryamikov (1999)
// 
// Command line utility that executes a command under specified user identity 
// by temporarily installing itself as a service.
//
// Based on Keith Brown's AsLocalSystem utility (http://www.develop.com/kbrown)
// Uses some code from Mike Nelson's dcomperm sample utility 
//   and from tlist sample (Microsoft Source Code Samples)
//
// Use:
//  CreateProcessAsUser.exe [-i[nteractive]]|[-s[ystem]]|
//       [-u"UserName" -d"DomainName" -p"Password"]|[-a"AppID"] command
//  Command must begin with the process (path to the exe file) to launch
//  -i        process will be launched under credentials of the 
//            "Interactive User" (retrieved from winlogon\shell process)
//  -a        process will be launched under credentials of the user 
//            specified in "RunAs" parameter of AppID.
//  -s        process will be launched as local system
//  -u -d -p  process will be launched on the result token of the 
//            LogonUser(userName,domainName,password,LOGON32_LOGON_BATCH...)
//
// either (-s) or (-i) or (-a) or (-u -d -p) parameters must supplied
// 
// Examples:
// CreateProcessAsUser -s cmd.exe
// CreateProcessAsUser -a"{731A63AF-2990-11D1-B12E-00C04FC2F56F}" winfile.exe
//
/////////////////////////////////////////////////////////////

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

Answer 3

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

Answer 4

Я предполагаю, что этот процесс является сервисом;это не указано в вопросе, но кажется логичным, учитывая, что он запущен от имени локальной системной учетной записи.

Где ты застреваешь, так это не в CreateProcess, Это в CreateService.Если вы хотите, чтобы ваш сервис мог взаимодействовать с рабочим столом, вам необходимо указать SERVICE_INTERACTIVE_PROCESS в качестве одного из флагов аргумента dwServiceType.Этот параметр наследуется дочерними процессами службы.

Вы также можете изменить настройки существующей службы с помощью инструмента "Службы", выбрать Свойства службы, перейти на вкладку "Войти" и установить флажок "Разрешить службе взаимодействовать с desktop".