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

KS>А каким тогда образом можно управлять правами на запуск инпроца? Его же не видно
KS>в DCOMCNFG. Мы сделали это, добавив AppID.

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

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

KS>Да.

Да... плохи ваши дела. Без W2k вам тут не обойтись...

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

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

Так это уже ерунда. dll можно вызвать только через сурогат, а это, как я уже говорил, не инпроц!

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

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

KS>2. Service вызывает CoCreateInstance удаленной dll на Comp2. Identity — The launching user.

А вот это зря. При этом имперсонация невозможна даже на W2k.

KS>Права на запуск — Everyone. Default impersonation level — Identity.

Это все пофику если запуск идет под "launching user". Этис юзером будет вообще System с сервера 1, а под NT4 эта запись вообще не будет иметь прав на вторй машине.

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

Так и нстройте запуск сервера из под этого самого domain\admin (ну, или локал.админа). При этом сервер получит доступ ко всем файлам к которым разрешон доступ для domain\admin.

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

Дык! :)

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

Здесь нужно по подробнее. Хотя понятно, что System-у с другой машины ничего не светит. :)

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

Дык! Было бы странно, что у админа домена нет прав на машинах к нему подключенных. :)

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


Я уже говорл, что имперсонация и launching user вещи не совместимые? :)

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

Ну, имперсонация без делегации (доступной только под W2k и дико геморойной) вообще применима только к локальным ресурсам (локальным файлам, веткам реестра...). А в случае запуска сервера под domain\admin и запуска второго как launching user вы получаете уразанный вариант того что вам нужно.


PS


Итак что вам действительно нудно:

1. Перестать назвать сурогаты инпроцессами. ;)
2. Запустить сервер на втором сервере (тот шо dll) под domain\admin.
3. Забыть про имперсонацию как про старшный сон.
4. Запустить первый сервер под нким сетевым экаунтом. Не обязательно domain\admin. Достаточно domain\VasiaPupkin.
5. Дать экаунту под которым запущен первый сервер права на доступ к второму серверу.
6. Настроить подходящие права доступа для клиенов к первому серву.

После этого все должно заработать.

Работать это будет так:
1. Клиент вызывает сервис.
2. COM проверяет можно ли запустить сервер и вызвать его методы (п.6).
3. Сервис который запущен под сетевым экаунтом вызвает клиента (если запустить сервис под System, под NT4 он низачто не сможет вызвать удаленный метод, так как этот экаунт ноль на сети).
4. Сервер два осуществляет доступ к локальным и сетевым ресурсам под учетной записью domain\admin. Это дает ему афигенные права, но и предявляет жествкие требования к администратору по защите этого сервиса.

В моей стаье все это дело подробно разобрано. Если хочешь избавиться от каши, прочитай читай ее. Там же будет пример (правда COM+-ный, и попробывать его можно только если сервером будет W2k) на котором все это можно легко попробывать "в живую".