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

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

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

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

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

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

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

Любая помощь будет принята с благодарностью, спасибо :)


person Adam Cobb    schedule 27.02.2009    source источник


Ответы (4)


У вас есть код, запущенный с использованием CreateProcessWithLogonW (и который, в свою очередь, вызывает CreateProcess)? Если вы этого не сделаете, вам может потребоваться выполнить перехват IAT (или API)< /strong> на нем (т.е. во время выполнения), чтобы заменить любые вызовы CreateProcess соответствующей процедурой, которая также использует CreateProcessWithLogonW или CreateProcessWithTokenW. См. APIHijack., обходы.

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

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

person vladr    schedule 27.02.2009

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

/////////////////////////////////////////////////////////////
// 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, которые дали нужные нам результаты.

person SAMills    schedule 02.03.2009

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

person Eric Petroelje    schedule 27.02.2009
comment
Эта опция уже установлена, проблема не в самой службе, она запускает исполняемый файл под правильным пользователем, а дальнейшие процессы, которые этот исполняемый файл пытается запустить, вызывают проблемы... - person Adam Cobb; 27.02.2009
comment
Интересный. Я бы подумал, что разрешение будет унаследовано дочерними процессами. - person Eric Petroelje; 27.02.2009

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

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

Вы также можете изменить параметр существующей службы, используя инструмент «Службы», выберите «Свойства» для службы, щелкните вкладку «Вход в систему» ​​и установите флажок «Разрешить службе взаимодействовать с рабочим столом».

person Jared Oberhaus    schedule 06.03.2009
comment
Упс, я вижу из приведенных выше комментариев к другому вопросу, что это уже исключено. - person Jared Oberhaus; 06.03.2009