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

VD>>Это глупость. AppID не связан c CLSID! AppID — это гуид exe-шника! Т.е. CLSID может быть асоцеирован с AppID только если CoClass реализован внутри exe-шника.

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

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

KS>в DCOMCNFG. Мы сделали это, добавив AppID.

Судя по всему, у вас используется вовсе не inproc, а его суррогат. Вот для него права уже реальны.

VD>>А откуда берется этот "имперсонированный пользователь". Клиент, что, является промежуточным сервером?

KS>Да.

Мда, с таких вещей и нужно начинать.

VD>>Ясно что вы там что-то недопонимаете. Но вот ваша схема не очень понята. Можно еще раз... Но подробно и без пропусков обрисовать задачу и то как вы ее пытаетесь решить.

KS>Итак.
KS>Имеется два компьютера. На обоих WinNT 4.0
KS>На Comp1 работает некий Service, запущенный под системным эккаунтом.
KS>На Comp2 есть dll, в задачу которой входит чтение локальных файлов и их компиляция.

KS>Требуется вызвать из под Service на Comp1 метод dll на Comp2 в котором и происходит чтение и компиляция файлов.

KS>По запросу пользователя происходит следующее:

KS>1. Service на Comp1 производит имперсонацию с помощью LogonUser. Используется доменное имя, которое, в целях простоты, будем считать доменным администратором (domain\admin)

KS>2. Service вызывает CoCreateInstance удаленной dll на Comp2. Identity — The launching user. Права на запуск — Everyone. Default impersonation level — Identity.

KS>3. dll на Comp2 пытается получить доступ к локальным файлам (расположенным на компьютере Comp2), на которые domain\admin имеет все необходимые права.

KS>У нас пункт 3 не проходит с ошибкой access denied.

Вполне логично, т.к. запрос на запуск приходит от имени того пользователя, под которым работает сервис на Comp1.
Для того, чтобы это работало так, как хочется, нужна возможность делегирования полномочий, которой под NT4 не бывает как класса. Делегирование возможно только в домене Win2k, причем все клиенты и машины должны принадлежать этому или trusted домену, и в качестве протокола аутентификации должен использоваться Kerberos (причем, делегирование еще и отдельно разрешать нужно).

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

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

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

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

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

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

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

См. выше.