Здравствуйте Konstantin Sokolovskiy, Вы писали:

KS>Здравствуйте Lexey, Вы писали:

L>>Здравствуйте Konstantin Sokolovskiy, Вы писали:

KS>>>А каким тогда образом можно управлять правами на запуск инпроца? Его же не видно

L>>Никак. In-proc — это не более чем dll, загружаемая в адресное пространство вызывающего процесса. У нее в принципе не может быть никаких прав на запуск (разве что, права на сам модуль в файловой системе).

KS>Вот ровно для того, чтобы им можно было управлять, мы и добавляли AppID. Могу тут поставить вопрос следующим образом: кто может запускать и иметь доступ к in-proc серверу? Everyone? Нас это не устраивает, к сожалению...

Хм, Inproc-server удаленно вообще никак нельзя запустить, т.ч. проблема его защиты вообще лишена смысла.

KS>>>При другом варианте мы пытались сделать LogonUser внутри dll непосредственно на Comp2. Это тоже не срабатывает. Выдается ошибка по поводу The required priveledge not held by client.

L>>Скорее всего, это из-за того, что LocalSystem Comp1 не имеет привилегии сетевого доступа к Comp2, что вполне логично.

KS>В этом я не уверен. Ошибка выдается при попытке сделать LogonUser на Comp2. Причем тут привелегия сетевого доступа?

Замечательно, вы пытаетесь сделать LogonUser для юзера Comp1\LocalSystem. Какой тут вообще может быть logon, если это вообще не пользователь, а predefined SID?

KS>>>Пришлось попробовать еще третий вариант. При нем Service на Comp1 запускается не под системным эккаунтом, а под эккаунтом domain\admin. В этом случае все работает.

L>>Тоже логично.

KS>Это и нам понятно

KS>>>Еще один вариант. Service запускается под именем domain\admin. На Comp2 делаем расшаренный каталог \\Comp2\sharedDir\, в котором расположен file.txt, на который имеет права _только_ domain\admin. Перед открытием файла \\Comp2\sharedDir\file.txt Service имперсонируется под именем domain\user, прав на этот файл не имеющий. И все равно открытие файла происходит нормально!

L>>Объяснение уже было дано выше.

KS>Где выше?

Ты его благополучно вырезал. Здесь ровно та же самая ситуация, что и с запуском удаленного сервера. Обращение к сетевому диску происходит под тем юзером, под которым запущен сервис, а не под имперсонированным, со всеми вытекающими последствиями. Почему это происходит именно так — я уже написал ранее.

KS>Именно это нам непонятно.

KS>>>В связи с этим у меня возникает чайниковский вопрос: чем толком отличаются два варианта — вариант когда сервис работает под системным эккаунтом, но мы имперсонируемся под именем domain\admin и вариант при котором сервис сразу запускается от имени domain\admin.

L>>См. выше.
KS>Можно подробнее немного?

Что именно?