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

Question

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

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

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

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

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

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

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

Answer 1

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

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

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

Answer 2

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

Answer 3

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

///////////////////////////////////////////////////////////// 
// 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 4

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

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

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