Задача такая: есть программа, которая должна запускать сабж. В MSDN'е есть фунцкия CreateProcessAsUser(), но для нее надо выполнить LogonUser(). Последняя функция валится с ошибкой "нет требуемых привилегий". Что делать?
Здравствуйте av, вы писали:
av> Задача такая: есть программа, которая должна запускать сабж. В MSDN'е есть av> фунцкия CreateProcessAsUser(), но для нее надо выполнить LogonUser(). av> Последняя функция валится с ошибкой "нет требуемых привилегий". Что делать?
LogonUser требует SE_TCB_NAME привилегию, которая по умолчанию есть только
у LocalSystem аккаунта.
В Win2K можно вызвать CreateProcessWithLogonW, которая не требует дополнительных
привилегий. Она обращается к RunAs сервису, который вызывает LogonUser и
CreateProcessAsUser из LocalSystem аккаунта.
В NT 4 единственный известный мне способ — это сделать свой сервис в LocalSystem,
из которого вызывать LogonUser и CreateProcessAsUser. Ограничение LogonUser
можно обойти, если использовать NTLM SSP для аутентификации и получения токена
(это описано в MSDN KB article Q180548). Но даже имея токен, вызвать
CreateProcessAsUser из обычного аккаунта не получится, поскольку она требует
наличия SE_ASSIGNPRIMARYTOKEN_NAME привилегии, которая тоже по умолчанию
только у LocalSystem.
Здравствуйте Alex Fedotov, вы писали:
AF>В NT 4 единственный известный мне способ — это сделать свой сервис в LocalSystem, AF>из которого вызывать LogonUser и CreateProcessAsUser. Ограничение LogonUser AF>можно обойти, если использовать NTLM SSP для аутентификации и получения токена AF>(это описано в MSDN KB article Q180548). Но даже имея токен, вызвать AF>CreateProcessAsUser из обычного аккаунта не получится, поскольку она требует AF>наличия SE_ASSIGNPRIMARYTOKEN_NAME привилегии, которая тоже по умолчанию AF>только у LocalSystem.
Простите, а кто мешает дабавить эту привилегию пользователю?
Здравствуйте kkv, вы писали:
AF>>(это описано в MSDN KB article Q180548). Но даже имея токен, вызвать AF>>CreateProcessAsUser из обычного аккаунта не получится, поскольку она требует AF>>наличия SE_ASSIGNPRIMARYTOKEN_NAME привилегии, которая тоже по умолчанию AF>>только у LocalSystem.
kkv>Простите, а кто мешает дабавить эту привилегию пользователю?
Ничего, кроме здравого смысла. Microsoft считает, что эта привилегия слишком
сильная, чтобы давать ее обычным пользователям. Буквально на MSDN написано
следующее:
Replace a process-level token (SeAssignPrimaryTokenPrivilege)
Allows a user to modify a process's security access token. This is a powerful
right used only by the system.
В чем конкретно заключается эта сила, я сейчас пытаюсь выяснить в
microsoft.public.platformsdk.security.
Здравствуйте Alex Fedotov, вы писали:
AF>Ничего, кроме здравого смысла. Microsoft считает, что эта привилегия слишком AF>сильная, чтобы давать ее обычным пользователям. Буквально на MSDN написано AF>следующее:
AF>В чем конкретно заключается эта сила, я сейчас пытаюсь выяснить в AF>microsoft.public.platformsdk.security.
Я думаю, что тем и сильна, что замена маркера уровня процесса позволяет создавать процессы от имени другого пользователя — насколько мне помнится именно в это и выла первоначальная задача:
>Задача такая: есть программа, которая должна запускать сабж. В MSDN'е есть фунцкия > >CreateProcessAsUser(), но для нее надо выполнить LogonUser().
Здравствуйте kkv, вы писали:
AF>>Ничего, кроме здравого смысла. Microsoft считает, что эта привилегия слишком AF>>сильная, чтобы давать ее обычным пользователям. Буквально на MSDN написано AF>>следующее:
AF>>В чем конкретно заключается эта сила, я сейчас пытаюсь выяснить в AF>>microsoft.public.platformsdk.security.
kkv>Я думаю, что тем и сильна, что замена маркера уровня процесса позволяет создавать процессы от имени другого пользователя —
Не все так просто. CreateProcessWithLogonW тоже позволяет создавать процесс от имени другого пользователя, но не требует никаких привилегий и работает через RunAs сервис. Спрашивается, если замена токена процесса такая обыденная операция, зачем городить весь этот огород с сервисом? Раздали бы всем SeAssignPrimaryToken и дело с концом.
С другой стороны, если я имею токен, я могу его имперсонировать и получить почти те же самые права доступа, что и создав новый процесс. Имперсонация не требует никаких дополнительных привилегий.
kkv> насколько мне помнится именно в это и выла первоначальная задача:
>>Задача такая: есть программа, которая должна запускать сабж. В MSDN'е есть фунцкия > >>CreateProcessAsUser(), но для нее надо выполнить LogonUser().
kkv>или я чего-то не понимаю или одно из двух...
Нет, это я чего-то не понимаю. Что касается поставленной задачи, то я не уверен, что токен, полученный из NTLM SSP будет иметь TOKEN_ASSIGN_PRIMARY permission, со всеми вытекающими. Проверяется экспериментом, но у меня сейчас нет подходящего кода, куда можно было бы вставить проверку, а делать с нуля времени нет.
-- Alex Fedotov
Re[6]: Процесс от имени другого пользователя
От:
Аноним
Дата:
28.07.01 18:53
Оценка:
К сожалению под руками нет NT4, но, кажется, там как и в W2K можно было указать в "ярлыке" программы [x] Run as different user. Если память не обманула — лазейка есть,
иначе, кроме как написания своего сервиса типа RunAs, выхода нет?...
Здравствуйте Аноним, вы писали:
А>К сожалению под руками нет NT4, но, кажется, там как и в W2K можно было указать в "ярлыке" программы [x] Run as different user. Если память не обманула — лазейка есть, А>иначе, кроме как написания своего сервиса типа RunAs, выхода нет?...
Господ! А может все проще? Как с правами на перезагрузку компьютера... по умолчанию привилегии нет, но ее мжно запросить, и если позоляют права получить...
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте Аноним, вы писали:
А>К сожалению под руками нет NT4, но, кажется, там как и в W2K можно было указать в "ярлыке" программы [x] Run as different user. Если память не обманула — лазейка есть,
Здравствуйте VladD2, вы писали:
VD>Здравствуйте Аноним, вы писали:
А>>К сожалению под руками нет NT4, но, кажется, там как и в W2K можно было указать в "ярлыке" программы [x] Run as different user. Если память не обманула — лазейка есть, А>>иначе, кроме как написания своего сервиса типа RunAs, выхода нет?...
VD>Господ! А может все проще? Как с правами на перезагрузку компьютера... по умолчанию привилегии нет, но ее мжно запросить, и если позоляют права получить...
Здраствуйте!
С огромным интересом прочитал весь тред. В процессе работы над проектом (сервер работающий в сервисе), сам пришел к тем же выводам, но возникли некоторые проблемы:
1) Запущенное под сервисом приложение (CreateProcess & CreateProcessAsUser) не видимо, даже при залогиненом пользователе. Никаких ошибок не возникает, программа запускается и прекрасно работает, аналогичный код не в сервисе работает как ожидалось.
2) Как правильнее из сервиса открыть зарегистрированный в системе документ (те открыть связанную программу и передать ей этот файл).
— ShellExecute [Ex] не подходят по причинам:
a) не позволяет запустить с правами требуемого пользователя
b) _как я понимаю_ не могут работать без загруженного шела... или могут?
— FindExecutable
a) дает только свзяанный exe, но не то как запускать
b) то же
— (самый экстремальный вариант) — самому читать из реестра, но
a) придется предусмотреть всё самому
b) часть программ (пр ACDSee) принимает параметры по DDE, я совсем этим не занимался и опять же безопасность NT + DDE = ?
Здравствуйте Princ, вы писали:
P>1) Запущенное под сервисом приложение (CreateProcess & CreateProcessAsUser) не видимо, даже при залогиненом пользователе. Никаких ошибок не возникает, программа запускается и прекрасно работает, аналогичный код не в сервисе работает как ожидалось.
Если не предпринимать никаких дополнительных действий, то созданный из сервиса процесс будет выполняться на той же паре window station & desktop, что и сервис. Как правило, это неинтерактивная window station (если только при создании сервиса не был указан флаг SERVICE_INTERACTIVE_PROCESS).
Запуск процессов из сервиса на десктопе пользователя описан в http://www.microsoft.com/MSJ/0200/logon/logon.asp
P>2) Как правильнее из сервиса открыть зарегистрированный в системе документ (те открыть связанную программу и передать ей этот файл).
С какой целью? С трудом могу представить себе сценарий, когда из сервиса нужно открывать документы.
P>- ShellExecute [Ex] не подходят по причинам: P> a) не позволяет запустить с правами требуемого пользователя P> b) _как я понимаю_ не могут работать без загруженного шела... или могут?
Я думаю, что все-таки могут.
P>- FindExecutable P> a) дает только свзяанный exe, но не то как запускать P> b) то же
P>- (самый экстремальный вариант) — самому читать из реестра, но P> a) придется предусмотреть всё самому P> b) часть программ (пр ACDSee) принимает параметры по DDE, я совсем этим не занимался и опять же безопасность NT + DDE = ?
Есть безопасность и в DDE :) Самый простой вариант — это запустить свой процесс под нужным пользователем на нужной паре window station & desktop с помошью CreateProcessAsUser, а оттуда уже вызывать ShellExecuteEx.
Здравствуйте Alex Fedotov, вы писали:
>(если только при создании сервиса не был указан флаг >SERVICE_INTERACTIVE_PROCESS).
В том-то и дело, что флаг указан.
AF>Запуск процессов из сервиса на десктопе пользователя описан в http://www.microsoft.com/MSJ/0200/logon/logon.asp
Спасибо!
P>>2) Как правильнее из сервиса открыть зарегистрированный в системе документ (те открыть связанную программу и передать ей этот файл). AF>С какой целью? С трудом могу представить себе сценарий, когда из сервиса нужно открывать документы.
Надо ;-(
AF>Есть безопасность и в DDE :) Самый простой вариант — это запустить свой процесс под нужным пользователем на нужной паре window station & desktop с помошью CreateProcessAsUser, а оттуда уже вызывать ShellExecuteEx.
А если:
1) LogonUser
2) ImpersonateLoggedOnUser
3) ShellExecuteEx
4) RevertToSelf
будет работать всегда? есть юзер за компом или нет?...
Здравствуйте Princ, вы писали:
P>>>2) Как правильнее из сервиса открыть зарегистрированный в системе документ (те открыть связанную программу и передать ей этот файл). AF>>С какой целью? С трудом могу представить себе сценарий, когда из сервиса нужно открывать документы. P>Надо ;-(
Потрясающей силы аргументация.
P>А если: P>1) LogonUser P>2) ImpersonateLoggedOnUser P>3) ShellExecuteEx P>4) RevertToSelf P>будет работать всегда?
Это не будет работать, как ожидается, поскольку CreateProcess использует primary token, а не impersonation token, чтобы определить в контексте какого пользователя создавать новый процесс.
P>есть юзер за компом или нет?...
Вот меня больше всего и интересует, что мы ожидаем от запущенной программы с открытым документом, когда в системе нет интерактивного пользователя.
Здравствуйте Alex Fedotov, вы писали:
P>>Надо ;-( AF>Потрясающей силы аргументация. AF>Вот меня больше всего и интересует, что мы ожидаем от запущенной программы с открытым документом, когда в системе нет интерактивного пользователя.
Краткость сестра таланта ;-)
Я привел плохой пример. Конечно, документ Word или картинку запускать без пользователя смысла не имеет.
Под документами имелись в виду скрипты. Конечно можно заставить пользователя потрудится (что, кстати, и придется сделать, если я это не решу), но мы же знаем какие пользователи капризные ;-)
В W2K есть приятная функция SHCreateProcessAsUserW, но она появилась только там и, наверное, использует названный вами сервис.
Смотрел правильность написания в MSDN и наткнулся на:
This function is similar to ShellExecuteEx with runas as the verb. However, SHCreateProcessAsUserW creates a process that runs in the security context of the user represented by the hUserToken member of the structure pointed to by pscpi. The structure's lpProcessInformation member can be used to return a PROCESS_INFORMATION structure with information on the new process.
The runas verb must be supported by the executable file's file class. The .exe file class supports runas. Use the AssocQueryString function to check whether or not runas is supported by other file classes. The following code fragment illustrates the syntax:
AF>Это не будет работать, как ожидается, поскольку CreateProcess использует primary token, а не impersonation token, чтобы определить в контексте какого пользователя создавать новый процесс.
Запомним.
Сдаётся мне, вы зациклились на запуске процессов :(
Вернёмся к первоначальной постановке задачи.
> Задача такая: есть программа, которая должна запускать сабж.
Элементарно :) Пишем локальный COM сервер, запускаем dcomcnfg.exe, находим наш объект, жмём Properties, переходим на вкладку Identity, включаем This User, вводим имя, пароль, готово. Будет работать хоть на локальной машине, хоть на удалённой.
Или такой вариант не устраивает изначально?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте IT, вы писали:
IT>Сдаётся мне, вы зациклились на запуске процессов :( IT>Вернёмся к первоначальной постановке задачи.
Well, правильная постановка задачи есть добрая половина решения.
>> Задача такая: есть программа, которая должна запускать сабж.
IT>Элементарно :) Пишем локальный COM сервер, запускаем dcomcnfg.exe, находим наш объект, жмём Properties, переходим на вкладку Identity, включаем This User, вводим имя, пароль, готово. Будет работать хоть на локальной машине, хоть на удалённой.
Превосходно. Только это будет работать если имя пользователя и пароль известны заранее. Если они становятся известны только непосредственно перед запуском, то этот метод работать не будет. Вот мы опять вернулись к тому, что сначала надо разобраться с постановкой задачи.
P>Я привел плохой пример. Конечно, документ Word или картинку запускать без пользователя смысла не имеет.
Отчего это?
У меня в сервере сидит EXE (не оформлен как сервис, но по смыслу — именно он), который при определённых событиях формирует по определённому шаблону файл MS Excel и отправляет его через MAPI. Пользователи в этом никак не участвуют.
Здравствуйте Alex Fedotov, вы писали:
AF>Превосходно. Только это будет работать если имя пользователя и пароль известны заранее. Если они становятся известны только непосредственно перед запуском, то этот метод работать не будет. Вот мы опять вернулись к тому, что сначала надо разобраться с постановкой задачи.
Да, ты прав при такой постановке задачи это не вариант. Тогда пойдём другим путём :) Я ни разу не работал с CoSetProxyBlanket, но что-то мне подсказывает, что это оно. В MSDN есть статейка "Setting Authentication Using C++", может поможет. В этом случае Identity нужно установить в launching user.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте IT, вы писали:
AF>>Превосходно. Только это будет работать если имя пользователя и пароль известны заранее. Если они становятся известны только непосредственно перед запуском, то этот метод работать не будет. Вот мы опять вернулись к тому, что сначала надо разобраться с постановкой задачи.
IT>Да, ты прав при такой постановке задачи это не вариант. Тогда пойдём другим путём :) Я ни разу не работал с CoSetProxyBlanket, но что-то мне подсказывает, что это оно. В MSDN есть статейка "Setting Authentication Using C++", может поможет. В этом случае Identity нужно установить в launching user.
CoSetProxyBlanket, пожалуй будет слишком поздно (процесс уже запущен), а вот выставить нужные credentials в COAUTHINFO при вызове CoCreateInstanceEx должно быть в самый раз.
Здравствуйте Alex Fedotov, вы писали:
AF>Здравствуйте IT, вы писали:
AF>>>Превосходно. Только это будет работать если имя пользователя и пароль известны заранее. Если они становятся известны только непосредственно перед запуском, то этот метод работать не будет. Вот мы опять вернулись к тому, что сначала надо разобраться с постановкой задачи.
IT>>Да, ты прав при такой постановке задачи это не вариант. Тогда пойдём другим путём :) Я ни разу не работал с CoSetProxyBlanket, но что-то мне подсказывает, что это оно. В MSDN есть статейка "Setting Authentication Using C++", может поможет. В этом случае Identity нужно установить в launching user.
AF>CoSetProxyBlanket, пожалуй будет слишком поздно (процесс уже запущен), а вот выставить нужные credentials в COAUTHINFO при вызове CoCreateInstanceEx должно быть в самый раз.
Ты опять прав, но я настаиваю: MSDN->"Changing the Authentication Credentials" :)
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте Alex Fedotov, Вы писали:
AF>В NT 4 единственный известный мне способ — это сделать свой сервис в LocalSystem, AF>из которого вызывать LogonUser и CreateProcessAsUser.
А что мешает просто дать привелегию конкретному экаунту?
Более того, мне кажется что, экаунт автоматом получит данную привелегию если под ним запустить сервис. По крайней мере я даже незнаю где в NT4 задается эта привелегия, а у моего экаунта она установлена. Поднобнее здесь http://delphi.mastak.ru/cgi-bin/forum.pl?look=1&id=1007568516&n=5
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте VladD2, Вы писали:
VD>Здравствуйте Alex Fedotov, Вы писали:
AF>>В NT 4 единственный известный мне способ — это сделать свой сервис в LocalSystem, AF>>из которого вызывать LogonUser и CreateProcessAsUser.
VD>А что мешает просто дать привелегию конкретному экаунту?
Только соображения безопасности. SE_TCB_NAME означает полный контроль над системой.
VD>Более того, мне кажется что, экаунт автоматом получит данную привелегию если под ним запустить сервис.
Здравствуйте Alex Fedotov, Вы писали:
VD>>А что мешает просто дать привелегию конкретному экаунту?
AF>Только соображения безопасности. SE_TCB_NAME означает полный контроль над системой.
Ну, не столь уж и полный. Да и если такой экаунт будет использоваться только для запуска сервиса, то ничего страшного этом нет (под системом же запускают). Зато такой экаунт и в сетку может вылезти и другие действия делать. Главное пароли на стикерах по офису не расклеивать.
VD>>Более того, мне кажется что, экаунт автоматом получит данную привелегию если под ним запустить сервис.
AF>Не получит.
Да? Тогда объясни как у меня оказалась эта привелегия если я ее сам не ставил (а кроме меня некому)? Может COM+ ее забабахивает?
VD>>По крайней мере я даже не знаю где в NT4 задается эта привилегия, а у моего экаунта она установлена. Поднобнее здесь http://delphi.mastak.ru/cgi-bin/forum.pl?look=1&id=1007568516&n=5
AF>В NT4 привилегии управляются в User Manager (musrmgr.exe), меню Policies|User Rights..., если мне память не изменяет.
Да я вроде знаю, но вот когда полез ее там высматривать, то не нашел ее там. Так что привилегия есть, а выключить ее...
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте VladD2, Вы писали:
VD>>>А что мешает просто дать привелегию конкретному экаунту?
AF>>Только соображения безопасности. SE_TCB_NAME означает полный контроль над системой.
VD>Ну, не столь уж и полный.
Полный. Имея эту привилегию можно выполнять действия от лица любого пользователя, даже не зная его пароля. Можно загружать произвольный код в ядро, и многое чего еще.
VD>Да и если такой экаунт будет использоваться только для запуска сервиса, то ничего страшного этом нет (под системом же запускают). Зато такой экаунт и в сетку может вылезти и другие действия делать. Главное пароли на стикерах по офису не расклеивать.
Можно и так. Общепринятая практика состоит в том, чтобы держать весь код, который требует TCB-привилегию, в LocalSystem. На самом деле эта привилегия не так часто и нужна.
Кстати, начиная с XP, LogonUser больше не требует эту привилегию, поскольку сама по себе LogonUser никакой опасности не представляет.
VD>>>Более того, мне кажется что, экаунт автоматом получит данную привелегию если под ним запустить сервис.
AF>>Не получит.
VD>Да? Тогда объясни как у меня оказалась эта привелегия если я ее сам не ставил (а кроме меня некому)? Может COM+ ее забабахивает?
Я не знаю, кто ее забабахиват, но факт создания службы с некоторым аккаунтом никак не влияет на набор привилегий этого аккаунта.
AF>>В NT4 привилегии управляются в User Manager (musrmgr.exe), меню Policies|User Rights..., если мне память не изменяет.
VD>Да я вроде знаю, но вот когда полез ее там высматривать, то не нашел ее там. Так что привилегия есть, а выключить ее...
"Act as part of the operating system", как обычно. Не забудь включить галочку "Show advanced user rights".
Здравствуйте Alex Fedotov, Вы писали:
AF>Полный. Имея эту привилегию можно выполнять действия от лица любого пользователя, даже не зная его пароля. Можно загружать произвольный код в ядро, и многое чего еще.
Может поделишься как? Это и мне и другим будет интересно!
VD>>Да и если такой экаунт будет использоваться только для запуска сервиса, то ничего страшного этом нет (под системом же запускают). Зато такой экаунт и в сетку может вылезти и другие действия делать. Главное пароли на стикерах по офису не расклеивать.
AF>Можно и так. Общепринятая практика состоит в том, чтобы держать весь код, который требует TCB-привилегию, в LocalSystem. На самом деле эта привилегия не так часто и нужна.
Ну, да почти половина низкоуровневых функций защиты. Кто их использует...
AF>Кстати, начиная с XP, LogonUser больше не требует эту привилегию, ...
Я в курсе (MSDN почитываем).
AF>поскольку сама по себе LogonUser никакой опасности не представляет.
Ну, если админ установил разумное ограничение на количество повторных неудачных логинов.
VD>>Да? Тогда объясни как у меня оказалась эта привелегия если я ее сам не ставил (а кроме меня некому)? Может COM+ ее забабахивает?
AF>Я не знаю, кто ее забабахиват, но факт создания службы с некоторым аккаунтом никак не влияет на набор привилегий этого аккаунта.
Проверял, или это только твое мнение? Так COM+ влет приделывает к экаунту привелегию "запускать как бачь жоп".
AF>>>В NT4 привилегии управляются в User Manager (musrmgr.exe), меню Policies|User Rights..., если мне память не изменяет.
VD>>Да я вроде знаю, но вот когда полез ее там высматривать, то не нашел ее там. Так что привилегия есть, а выключить ее...
AF>"Act as part of the operating system", как обычно. Не забудь включить галочку "Show advanced user rights".
Блтин я про "Show advanced user rights" сам много раз читал и (давным давно) сам видел, а тут открыл диаложик, и нифига его не увидел. Кто глючит? Я или ОСь?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте VladD2, Вы писали:
AF>>Полный. Имея эту привилегию можно выполнять действия от лица любого пользователя, даже не зная его пароля. Можно загружать произвольный код в ядро, и многое чего еще.
VD>Может поделишься как? Это и мне и другим будет интересно!
См. LsaLogonUser, параметр LocalGroups.
AF>>поскольку сама по себе LogonUser никакой опасности не представляет.
VD>Ну, если админ установил разумное ограничение на количество повторных неудачных логинов.
VD>>>Да? Тогда объясни как у меня оказалась эта привелегия если я ее сам не ставил (а кроме меня некому)? Может COM+ ее забабахивает?
AF>>Я не знаю, кто ее забабахиват, но факт создания службы с некоторым аккаунтом никак не влияет на набор привилегий этого аккаунта.
VD>Проверял, или это только твое мнение? Так COM+ влет приделывает к экаунту привелегию "запускать как бачь жоп".
Проверял. Когда добавляешь сервис через GUI, то GUI добавляет привилегию "Logon as a service". Но если создавать сервис с помощью CreateService, то никакие привилегии не модифицируются. Ты, наверное, в курсе, там у меня статья про сервисы в обсуждении болтается
AF>>>>В NT4 привилегии управляются в User Manager (musrmgr.exe), меню Policies|User Rights..., если мне память не изменяет.
VD>>>Да я вроде знаю, но вот когда полез ее там высматривать, то не нашел ее там. Так что привилегия есть, а выключить ее...
AF>>"Act as part of the operating system", как обычно. Не забудь включить галочку "Show advanced user rights".
VD>Блтин я про "Show advanced user rights" сам много раз читал и (давным давно) сам видел, а тут открыл диаложик, и нифига его не увидел. Кто глючит? Я или ОСь?
Ничем не могу тут помочь. У меня и диаложек, и галочка, и привилегия на месте.
Здравствуйте Alex Fedotov, Вы писали:
VD>>Может поделишься как? Это и мне и другим будет интересно!
AF>См. LsaLogonUser, параметр LocalGroups.
Поглядим...
AF>Проверял. Когда добавляешь сервис через GUI, то GUI добавляет привилегию "Logon as a service". Но если создавать сервис с помощью CreateService, то никакие привилегии не модифицируются.
Интересно какой процент людей запускает сервисы и делает другие операции из кода и скрптов, а не через визуальный интерфейс?
AF>Ты, наверное, в курсе, там у меня статья про сервисы в обсуждении болтается
К великому прискорбию, был так загружен здачей очередного номера, что даже не распечатал... ни то что прочел... ну, да ладно... пйду исправляться. Хотя тебя не часто можно поправить.
AF>Ничем не могу тут помочь. У меня и диаложек, и галочка, и привилегия на месте.
— Будем искать...
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте SergH, Вы писали:
AF>> Ты, наверное, в курсе, там у меня статья про сервисы в обсуждении болтается
SH>Пожалуйста, подскажи, где конкретно. А то я не нашёл.
Это нормально. Статья (точнее, ее первая часть) пока внутри группы обсуждается, именно это обсуждение я имел в виду.
Когда она появится на сайте? Скоро, а может быть даже раньше. Я надеюсь, что в этом году.
-- Alex Fedotov
Re[10]: Процесс от имени другого пользователя
От:
Аноним
Дата:
15.05.03 08:17
Оценка:
Могу я подытожить говоренное?
Лично я использовал CreateProcessWithLogon, но посвольку сабж требовал LogonUser (типа для NT), то слегка изменил один мой старенький кодец.
Короче смысл в следующем.
1) Привилегии SE_TCB_NAME имеют системные процессы (winlogon, spoolsv и т.п.). Я использовал spoolsv;
2) Пишем обычную DLL, в DLLmain — создание потока. В потоке — LogonUser и CreateProcessAsUser. Можно другой код — он выполниться с правами системы
3) Подключаем нашу DLL к процессу [spoolsv у меня] — он выполняет Dllmain -> поток и LogonUser отрабатывает на УРА! Надеюсь внедрять DLL В процесс все умеют...
if (OpenProcessToken(hProcess,
TOKEN_DUPLICATE|TOKEN_ASSIGN_PRIMARY|TOKEN_QUERY,&hTok)){
STARTUPINFO si = {sizeof(STARTUPINFO)};
GetStartupInfo(&si);
PROCESS_INFORMATION pi = {0};
CreateProcessAsUser(hTok,NULL,_T("notepad.exe"),NULL,NULL,FALSE,
0,NULL,NULL,&si,&pi);
CloseHandle(pi.hThread);
На сколько я понимаю, ощибка 5 — Access Deny. Если так, значит ты все-таки не все привелегии включил.
Re[14]: Процесс от имени другого пользователя
От:
Аноним
Дата:
15.05.03 11:41
Оценка:
Здравствуйте, Alexey Shirshov, Вы писали:
AS>Здравствуйте, Аноним, Вы писали:
AS>[]
AS>На сколько я понимаю, ощибка 5 — Access Deny. Если так, значит ты все-таки не все привелегии включил.
Хмм... у меня, как пользователя такие account rights:
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, Alexey Shirshov, Вы писали:
[]
А они все включены? Я то включаю только SeDebugPrivilege.
А>Чего не хватает? У тебя работает пример — на какой оси?
Win2k Prof.
Re[16]: Процесс от имени другого пользователя
От:
Аноним
Дата:
15.05.03 12:02
Оценка:
Здравствуйте, Alexey Shirshov, Вы писали:
AS>Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, Alexey Shirshov, Вы писали:
AS>[]
AS>А они все включены? Я то включаю только SeDebugPrivilege.
А>Чего не хватает? У тебя работает пример — на какой оси?
AS>Win2k Prof.
Не проверял какие включены, но включаю в run-time SeDebugPrivilege, SeIncreaseQuotaPrivilege, SeAssignPrimaryTokenPrivilege... у меня SP3, может из-за него заплатка появилась?
[]
А>Не проверял какие включены, но включаю в run-time SeDebugPrivilege, SeIncreaseQuotaPrivilege, SeAssignPrimaryTokenPrivilege... у меня SP3, может из-за него заплатка появилась?
Зачем для этого заплатка? Это behavior by design.
У меня тоже SP3.
Re[18]: Процесс от имени другого пользователя
От:
Аноним
Дата:
16.05.03 11:22
Оценка:
Здравствуйте, Alexey Shirshov, Вы писали:
AS>Здравствуйте, Аноним, Вы писали:
AS>[]
А>>Не проверял какие включены, но включаю в run-time SeDebugPrivilege, SeIncreaseQuotaPrivilege, SeAssignPrimaryTokenPrivilege... у меня SP3, может из-за него заплатка появилась?
AS>Зачем для этого заплатка? Это behavior by design. AS>У меня тоже SP3.
Ну да ладно — не работает так, работает как я сделал
Если нам не помогут, то мы тоже никого не пощадим.
Да и если такой экаунт будет использоваться только для запуска сервиса, то ничего страшного этом нет (под системом же запускают). Зато такой экаунт и в сетку может вылезти и другие действия делать. Главное пароли на стикерах по офису не расклеивать. 
Так что привилегия есть, а выключить ее... 
