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

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

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

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

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

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

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

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

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

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

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

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

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

Где выше?
Именно это нам непонятно.

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

L>См. выше.

Можно подробнее немного?