Re[5]: Как воспользоваться Cloaking? - COM/DCOM/ActiveX

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

KS>Имеется два компьютера, работающих п/у WinNT 4.0.
KS>На одном работает сервис, он запускает через DCOM на
KS>другом компьютере in-proc сервер, который компилирует файл.

Ну, и какое отношение они могут иметь друг к другу?

KS>В DCOMCNFG на этот in-proc launch и access — everyone.

Чего? Ты случаем не о суррогатах говоришь? DCOMCNFG задает права на доступ к DCOM-приложениям (exe-шникам), а in-proc-сервер по определению является библиотекой и не имеет отношение к конкретному приложению. Сурогат же не является in-proc-сервером. Есть еще один вариант – in-proc может быть установлен в COM+/MTS-приложение. Тогда DCOMCNFG вообще не поможет, так как настройки надо делать в специальных средствах администрирования.

KS>На файл установлено ограничение — доступ к нему имеет определенный пользователь.

На какой файл? Ничего непонятно! Если на исполнимый файл DCOM-сервера, то доступ к серверу сможет получить только этот пользователь. Если речь идет о файле который нужно компилировать, то просто нужно запускать DCOM-сервер под учетной записью которой дано право доступа к этому файлу (и не в коем случае из под дефолтного "ланчинг узерь"). А имперсонация здесь вообще не нужна. Если нужно обеспечить проверку прав доступа к файлу применительно к вызывающему клиенту, то клиент должен делать вызов с уровнем имперсонации имперсонэйт, а сервер (а не клиент) делать эту самую имперсонацию. При этом проверки к локальным ресурсам (файлам на локальном диске, веткам реестра) будут производиться применительно к клиенту.

KS> Мы на клиенте делаем имперсонацию, но они до сервера не доходят, поэтому компиляция файла не проходит — access denied.

Кто они? Зачем на клиенте делать имперсонацию (это бессмысленно)? Причем тут вообще in-proc-сервер?

KS>Пытались использовать cloaking, используя на клиенте Win2000 — ничего не получилось.

Для клоакинга нужно иметь и на клиенте и на сервере W2k. Клоакинга же тебе без надобности, нужно просто сделать имперсонацию на сервере.

KS>Что нужно предпринять, чтобы сервер получил доступ к файлу.

Для начала нужно определиться с тем, что конкретно нужно? Почему клиент не может просто вызывать метод сервера, а тот просто компилировать нужный файл?

PS

В нулевом номере RSDN Mag будет статья о защите в DCOM/COM+. Очень советую ее почитать. Журнал должен выйти на следующей неделе.

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

VD>На какой файл? Ничего непонятно! Если на исполнимый файл DCOM-сервера, то доступ к серверу сможет получить только этот пользователь. Если речь идет о файле который нужно компилировать, то просто нужно запускать DCOM-сервер под учетной записью которой дано право доступа к этому файлу (и не в коем случае из под дефолтного "ланчинг узерь").

Вот за этот совет спасибо

Будем пробовать

VD>В нулевом номере RSDN Mag будет статья о защите в DCOM/COM+. Очень советую ее почитать. Журнал должен выйти на следующей неделе.

Прочитаем

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

KS>>Имеется два компьютера, работающих п/у WinNT 4.0.
KS>>На одном работает сервис, он запускает через DCOM на
KS>>другом компьютере in-proc сервер, который компилирует файл.

VD>Ну, и какое отношение они могут иметь друг к другу?

Сервису нужны результаты компиляции этого файла

KS>>В DCOMCNFG на этот in-proc launch и access — everyone.

VD>Чего? Ты случаем не о суррогатах говоришь? DCOMCNFG задает права на доступ к DCOM-приложениям (exe-шникам), а in-proc-сервер по определению является библиотекой и не имеет отношение к конкретному приложению. Сурогат же не является in-proc-сервером. Есть еще один вариант – in-proc может быть установлен в COM+/MTS-приложение. Тогда DCOMCNFG вообще не поможет, так как настройки надо делать в специальных средствах администрирования.

Мы добавили AppID для этого инпроса в .rgs-файле, чтобы управлять им в DCOMCNFG

KS>>На файл установлено ограничение — доступ к нему имеет определенный пользователь.

VD>На какой файл? Ничего непонятно! Если на исполнимый файл DCOM-сервера, то доступ к серверу сможет получить только этот пользователь. Если речь идет о файле который нужно компилировать, то просто нужно запускать DCOM-сервер под учетной записью которой дано право доступа к этому файлу (и не в коем случае из под дефолтного "ланчинг узерь"). А имперсонация здесь вообще не нужна. Если нужно обеспечить проверку прав доступа к файлу применительно к вызывающему клиенту, то клиент должен делать вызов с уровнем имперсонации имперсонэйт, а сервер (а не клиент) делать эту самую имперсонацию. При этом проверки к локальным ресурсам (файлам на локальном диске, веткам реестра) будут производиться применительно к клиенту.

На файл, который нужно скомпилировать

KS>> Мы на клиенте делаем имперсонацию, но они до сервера не доходят, поэтому компиляция файла не проходит — access denied.

VD>Кто они? Зачем на клиенте делать имперсонацию (это бессмысленно)? Причем тут вообще in-proc-сервер?

Права доступа имперсонируемого пользователя

KS>>Пытались использовать cloaking, используя на клиенте Win2000 — ничего не получилось.

VD>Для клоакинга нужно иметь и на клиенте и на сервере W2k. Клоакинга же тебе без надобности, нужно просто сделать имперсонацию на сервере.

Как? Мы пыталисью, но инпрос на сервере запускается с правами анонимного пользователя и не имеет права на имперсонацию

KS>>Что нужно предпринять, чтобы сервер получил доступ к файлу.

VD>Для начала нужно определиться с тем, что конкретно нужно? Почему клиент не может просто вызывать метод сервера, а тот просто компилировать нужный файл?

Наш сервис работает под системным аккаунтом, поэтому некоторые операции, которые требуют некоторых дополнительных привелегий, мы выполняем под специальным аккаунтом (имперсонируемся)

VD>PS

VD>В нулевом номере RSDN Mag будет статья о защите в DCOM/COM+. Очень советую ее почитать. Журнал должен выйти на следующей неделе.

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

KS>Сервису нужны результаты компиляции этого файла

Стало ясней...

KS>Мы добавили AppID для этого инпроса в .rgs-файле, чтобы управлять им в DCOMCNFG

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

KS>На файл, который нужно скомпилировать

По умолчанию (без имперсонации) права будут проверяться от имени сервера (т.е. от System).

KS>>> Мы на клиенте делаем имперсонацию, но они до сервера не доходят, поэтому компиляция файла не проходит — access denied.

Совершенно верно. Так как COM делает вызов под экаунтом exe-шника (клиентского).

KS>Права доступа имперсонируемого пользователя

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

VD>>Для клоакинга нужно иметь и на клиенте и на сервере W2k. Клоакинга же тебе без надобности, нужно просто сделать имперсонацию на сервере.

KS>Как? Мы пыталисью, но инпрос на сервере запускается с правами анонимного пользователя и не имеет права на имперсонацию

Что?! В COM-е не бывает анонимного пользователя. Впрочем как и в NT. В COM можно установить уровень имперсонации анонимус. Может ты об этом?

KS>>>Что нужно предпринять, чтобы сервер получил доступ к файлу.

VD>>Для начала нужно определиться с тем, что конкретно нужно? Почему клиент не может просто вызывать метод сервера, а тот просто компилировать нужный файл?

KS>Наш сервис работает под системным аккаунтом, поэтому некоторые операции, которые требуют некоторых дополнительных привилегий, мы выполняем под специальным аккаунтом (имперсонируемся).

Как он получается? С помощью LogonUser?
Компиляция проходит под имперсонацией?

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

У нас есть удаленный компилятор. Он получает запрос от пользователя такго-то (экаунт, его домен/компьютер, права). Сервер (экаунт, его домен/компьютер, права, тип запуска, и д.р. настройки из dcomcnfg.exe) открывает файл...

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

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

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

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

Да.

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

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

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

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

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

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

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

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

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

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

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

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

Здравствуйте 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.

См. выше.

Здравствуйте 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>См. выше.

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

Здравствуйте 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>Можно подробнее немного?

Что именно?

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

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

Inproc сервер реально запускается именно DLLHOST'ом. Это понятно. Почему же защита лишена смысла? Ведь, если не устанавливать ограничений, любой может вызвать CoCreateInstanceEx?

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

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

Уважаемый Lexey, что-то здесь не то. Если бы то, что вы написали, было верно, не работала бы следующая ситуация:
Service на Comp1 работает под системным эккаунтом.
Service имперсонируется под именем domain\admin и пытается получить доуступ к файлам а расшаренном каталоге на Comp2.
Это проходит! Если бы "Обращение к сетевому диску происходило под тем юзером, под которым запущен сервис", то это не работало бы, а это работает.

Что я тут не понимаю еще?

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

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

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

KS>Inproc сервер реально запускается именно DLLHOST'ом. Это понятно. Почему же защита лишена смысла? Ведь, если не устанавливать ограничений, любой может вызвать CoCreateInstanceEx?

Если это понятно, то зачем говорить про In-proc server? Так бы и говорил, что есть Outproc-server, на который и ставится защита через Dcomcnfg.

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

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

KS>Уважаемый Lexey, что-то здесь не то. Если бы то, что вы написали, было верно, не работала бы следующая ситуация:
KS>Service на Comp1 работает под системным эккаунтом.
KS>Service имперсонируется под именем domain\admin и пытается получить доуступ к файлам а расшаренном каталоге на Comp2.
KS>Это проходит! Если бы "Обращение к сетевому диску происходило под тем юзером, под которым запущен сервис", то это не работало бы, а это работает.

Вот тут я уже ничего не понимаю. В описанной конструкции это никак не может работать (разве что у domain\admin уже есть установленное соединение с Comp2\ipc$, т.е. его аутентификация на Comp2 уже ранее состоялась — в таком варианте это возможно будет работать).

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

L>Вот тут я уже ничего не понимаю. В описанной конструкции это никак не может работать (разве что у domain\admin уже есть установленное соединение с Comp2\ipc$, т.е. его аутентификация на Comp2 уже ранее состоялась — в таком варианте это возможно будет работать).

Установленного соединения нет, так что и для нас все это пока остается загадкой...
Будем, видимо, продолжать эксперименты, потому как надо же на практике выяснить, какой эккаунт имеет приоритет: под которым сервис работает, или под которым имперсонируется.

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

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

L>>Вот тут я уже ничего не понимаю. В описанной конструкции это никак не может работать (разве что у domain\admin уже есть установленное соединение с Comp2\ipc$, т.е. его аутентификация на Comp2 уже ранее состоялась — в таком варианте это возможно будет работать).

KS>Установленного соединения нет, так что и для нас все это пока остается загадкой...

А как это проверялось?

KS>Будем, видимо, продолжать эксперименты, потому как надо же на практике выяснить, какой эккаунт имеет приоритет: под которым сервис работает, или под которым имперсонируется.

Да причем тут какой аккаунт имеет приоритет. Фишка в том, что проверка прав имперсонированного аккаунта на другой машине в такой ситуации в принципе невозможна. NTLM работает следующим образом:
1) клиент шлет серверу свое имя
2) сервер шлет ему Challenge
3) клиент шлет серверу hash от Challenge и хеша пароля
4) сервер отсылает имя, Challenge и полученный от клиента hash доменному контроллеру
5) DC проверяет валидность полученных данных.

В твоем случае клиентом является Comp1, он на 3-м шаге не может отправить серверу (Comp2) хеш от хеша пароля и challenge, т.к. он попросту не знает хеша пароля. Единственный вариант, когда может работать описанная ситуация — юзер уже аутентифицирован на Comp2 ранее.

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

L>А как это проверялось?

Проверить это, на самом деле, достаточно просто:
Перезагружаем Comp1 да и Comp2 с ним заодно

Запускаем Service на Comp1 под системным эккаунтом, имперсонируемся, читаем файлы с Comp2, все работет.
Пользователь, под которым имперсонируемся, _гарантированно_ нигде больше не используется, т.е. больше соединение с Comp2 установить некому.
Более того, убрав имерсонацию, или имерсонируясь от пользователя, не имеющего прав на доступ к удаленным файлам, мы получаем стандартный access denied, что, вполне естесственно.

Предупреждая возможный вопрос: оба компьютера в домене, обычные NT4WKS. Проверялся вариант, при котором Comp2 был stand-alone NT4SRV, но не думаю, что это имеет значение...

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

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

L>>А как это проверялось?

KS>Проверить это, на самом деле, достаточно просто:
KS>Перезагружаем Comp1 да и Comp2 с ним заодно

KS>Запускаем Service на Comp1 под системным эккаунтом, имперсонируемся, читаем файлы с Comp2, все работет.
KS>Пользователь, под которым имперсонируемся, _гарантированно_ нигде больше не используется, т.е. больше соединение с Comp2 установить некому.
KS>Более того, убрав имерсонацию, или имерсонируясь от пользователя, не имеющего прав на доступ к удаленным файлам, мы получаем стандартный access denied, что, вполне естесственно.

Не, это все из разряда чудес.

KS>Предупреждая возможный вопрос: оба компьютера в домене, обычные NT4WKS. Проверялся вариант, при котором Comp2 был stand-alone NT4SRV, но не думаю, что это имеет значение...

У меня тут другой вопрос возник, а как имперсонация делается?

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

L>У меня тут другой вопрос возник, а как имперсонация делается?

Вот код класса, отвечающего за это дело:

class CPwdacImpersonator
{
public:
    CPwdacImpersonator( void )
        : m_loggedUser( GetUserName(), GetDomain(), GetPassword() )
    {
        m_impersonated = !m_loggedUser ? false : ::ImpersonateLoggedOnUser( m_loggedUser ) != FALSE;
    }
    ~CPwdacImpersonator( void )
    {
        if( m_impersonated )
        {
            ::RevertToSelf();
        }
    }
    operator bool() const
    {
        return( m_impersonated );
    }
protected:
    class LoggedUser
    {
    public:
        LoggedUser( LPCTSTR lpszUserName, LPCTSTR lpszDomain, LPCTSTR lpszPassword )
        {
            if( !::LogonUser(
                const_cast< LPTSTR >( lpszUserName ),
                const_cast< LPTSTR >( lpszDomain ),
                const_cast< LPTSTR >( lpszPassword ),
                LOGON32_LOGON_BATCH,
                LOGON32_PROVIDER_DEFAULT,
                &m_hToken ) )
            {
                m_hToken = NULL;
            }
        }
        ~LoggedUser( void )
        {
            if( m_hToken != NULL )
            {
                ::CloseHandle( m_hToken );
            }
        }
        operator HANDLE() const
        {
            return( m_hToken );
        }
        operator !() const
        {
            return( m_hToken == NULL );
        }
    protected:
        HANDLE m_hToken;
    };
protected:
    bool m_impersonated;
    TString m_userName;
    TString m_domain;
    TString m_password;
    LoggedUser m_loggedUser;
protected:
    LPCTSTR GetUserName( void )
    {
        _ASSERTE( _Module.m_pRegData != NULL );
        return( m_userName = _Module.m_pRegData->m_service.m_impersonation.m_userName );
    }
    LPCTSTR GetDomain( void )
    {
        _ASSERTE( _Module.m_pRegData != NULL );
        return( m_domain = _Module.m_pRegData->m_service.m_impersonation.m_domain );
    }
    LPCTSTR GetPassword( void )
    {
        _ASSERTE( _Module.m_pRegData != NULL );
        return( m_password = _Module.m_pRegData->m_service.m_impersonation.m_password );
    }
};

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

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

L>>У меня тут другой вопрос возник, а как имперсонация делается?

KS>Вот код класса, отвечающего за это дело:

KS>

KS>            if( !::LogonUser(
KS>                const_cast< LPTSTR >( lpszUserName ),
KS>                const_cast< LPTSTR >( lpszDomain ),
KS>                const_cast< LPTSTR >( lpszPassword ),
KS>                LOGON32_LOGON_BATCH,
KS>                LOGON32_PROVIDER_DEFAULT,
KS>                &m_hToken ) )
KS>

Мда, зря я вначале не обратил внимания на LogonUser в строчке про имперсонацию. Просто он у меня с имперсонацией клиента сервером никак не ассоциируется, да и по сути это не имперсонация, а почти полноценный logon. В этом случае, сетевые подключения действительно будут работать, а ошибка с привилегиями скорее всего связана с отсутсвием привилегии на сетевой логон (тут, думаю, нужно с флагами LogonUser играться).

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

L>Мда, зря я вначале не обратил внимания на LogonUser в строчке про имперсонацию. Просто он у меня с имперсонацией клиента сервером никак не ассоциируется, да и по сути это не имперсонация, а почти полноценный logon. В этом случае, сетевые подключения действительно будут работать, а ошибка с привилегиями скорее всего связана с отсутсвием привилегии на сетевой логон (тут, думаю, нужно с флагами LogonUser играться).

Прошу прощения за двусмысленность того моего вопроса.

Итак, вопрос остается. Почему работают _оба_ варианта:
1. Service на Comp1 запущен под именем Comp1\LocalUser. Делаем LogonUser под именем domain\admin.
2. Service на Comp1 запущен под именем domain\admin. Делаем LogonUser под именем Comp1\LocalUser.

Comp1\LocalUser, само собой, получить доступа к удаленным файлам не может.

Здравствуйте 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) на котором все это можно легко попробывать "в живую".

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

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

L>>Мда, зря я вначале не обратил внимания на LogonUser в строчке про имперсонацию. Просто он у меня с имперсонацией клиента сервером никак не ассоциируется, да и по сути это не имперсонация, а почти полноценный logon. В этом случае, сетевые подключения действительно будут работать, а ошибка с привилегиями скорее всего связана с отсутсвием привилегии на сетевой логон (тут, думаю, нужно с флагами LogonUser играться).

KS>Прошу прощения за двусмысленность того моего вопроса.

KS>Итак, вопрос остается. Почему работают _оба_ варианта:
KS>1. Service на Comp1 запущен под именем Comp1\LocalUser. Делаем LogonUser под именем domain\admin.
KS>2. Service на Comp1 запущен под именем domain\admin. Делаем LogonUser под именем Comp1\LocalUser.

Тут много составляющих...
Думаю все это можно разгрести если прочесть http://www.rsdn.ru/forum/message.asp?mid=32450&only

KS>Comp1\LocalUser, само собой, получить доступа к удаленным файлам не может.

Это почему? Если его сид будет в дакле, то вроде должен.

	От:	Konstantin Sokolovskiy
	Дата:	22.02.02 14:59
	Оценка:

От:	VladD2	www.nemerle.org
Дата:	23.02.02 23:06
Оценка:

	От:	Konstantin Sokolovskiy
	Дата:	26.02.02 13:51
	Оценка:

	От:	Konstantin Sokolovskiy
	Дата:	26.02.02 14:33
	Оценка:

От:	VladD2	www.nemerle.org
Дата:	26.02.02 22:04
Оценка:

	От:	Lexey
	Дата:	27.02.02 13:58
	Оценка:

	От:	Lexey
	Дата:	28.02.02 10:53
	Оценка:

	От:	Lexey
	Дата:	28.02.02 11:45
	Оценка:

	От:	Lexey
	Дата:	28.02.02 13:45
	Оценка: