Здравствуйте VladD2, Вы писали:
VD>Здравствуйте Konstantin Sokolovskiy, Вы писали:
KS>>Здравствуйте Lexey, Вы писали:
L>>>Мда, зря я вначале не обратил внимания на LogonUser в строчке про имперсонацию. Просто он у меня с имперсонацией клиента сервером никак не ассоциируется, да и по сути это не имперсонация, а почти полноценный logon. В этом случае, сетевые подключения действительно будут работать, а ошибка с привилегиями скорее всего связана с отсутсвием привилегии на сетевой логон (тут, думаю, нужно с флагами LogonUser играться).
С привилегией сетевого логона я похоже глупость сморозил. Похоже, что тут удаленный процесс пытается создаваться с правами владельца процесса, а не имперсонированного юзера. Возможно, тут может помочь замена primary token процесса, но это уже не будет имперсонацией.
KS>>Прошу прощения за двусмысленность того моего вопроса.
KS>>Итак, вопрос остается. Почему работают _оба_ варианта:
KS>>1. Service на Comp1 запущен под именем Comp1\LocalUser. Делаем LogonUser под именем domain\admin.
KS>>2. Service на Comp1 запущен под именем domain\admin. Делаем LogonUser под именем Comp1\LocalUser.
Реальная картина видимо устроена так:
1) сначала проверяется принципиальная возможность доступа к сетевому ресурсу от имени имперсонированного юзера, и если такой доступ возможен, то работает этот вариант. Облом тут может наступить по нескольким причинам — юзер вообще не имеет доступа ко второй машине (локальный), либо требуется делегация, которая невозможна без Kerberos и дополнительных условий.
2) если в 1) облом, то используется identity владельца процесса.
Проще всего наверное это проверить, запустив network monitor и посмотрев, что идет в аутентификационных пакетах между Comp1 и Comp2.
Можно еще позвать AF, может он расставит точки над Ё.
VD>Тут много составляющих...
VD>Думаю все это можно разгрести если прочесть http://www.rsdn.ru/forum/message.asp?mid=32450&onlyАвтор: VladD2
Дата: 01.03.02
KS>>Comp1\LocalUser, само собой, получить доступа к удаленным файлам не может.
VD>Это почему? Если его сид будет в дакле, то вроде должен.
Не Vlad, тут ты не прав. Это же локальный юзер, его сида в принципе не может быть на другой машине (точнее, теоретически он там может быть, да только смысл у него будет совсем другой).
Тут возможет вариант, когда на Comp2 есть юзер с таким же точно именем и таким же паролем.
Здравствуйте VladD2, Вы писали:
VD>Итак что вам действительно нудно:
VD>1. Перестать назвать сурогаты инпроцессами. 
VD>2. Запустить сервер на втором сервере (тот шо dll) под domain\admin.
VD>3. Забыть про имперсонацию как про старшный сон.
VD>4. Запустить первый сервер под нким сетевым экаунтом. Не обязательно domain\admin. Достаточно domain\VasiaPupkin.
VD>5. Дать экаунту под которым запущен первый сервер права на доступ к второму серверу.
VD>6. Настроить подходящие права доступа для клиенов к первому серву.
VD>После этого все должно заработать.
VD>Работать это будет так:
VD>1. Клиент вызывает сервис.
VD>2. COM проверяет можно ли запустить сервер и вызвать его методы (п.6).
VD>3. Сервис который запущен под сетевым экаунтом вызвает клиента (если запустить сервис под System, под NT4 он низачто не сможет вызвать удаленный метод, так как этот экаунт ноль на сети).
VD>4. Сервер два осуществляет доступ к локальным и сетевым ресурсам под учетной записью domain\admin. Это дает ему афигенные права, но и предявляет жествкие требования к администратору по защите этого сервиса.
VD>В моей стаье все это дело подробно разобрано. Если хочешь избавиться от каши, прочитай читай ее. Там же будет пример (правда COM+-ный, и попробывать его можно только если сервером будет W2k) на котором все это можно легко попробывать "в живую".
Большое спасибо, VladD2. Мы с Костей от этого геморроя избавились именно так как ты предложил. Т.е. мы забыли про имперсонацию и про запуск сервиса под System экаунтом. Просто мы думали, что может быть есть еще какой-нибудь выход.
А статью мы обязательно прочитаем.
Здравствуйте sap2, Вы писали:
S>Большое спасибо, VladD2. Мы с Костей от этого геморроя избавились именно так как ты предложил. Т.е. мы забыли про имперсонацию и про запуск сервиса под System экаунтом. Просто мы думали, что может быть есть еще какой-нибудь выход.
Выходов есть действительно много. И тут кроме вас никто не сможет сказать какой лучший... Из изложенного вроде это самый простой и эффективный, но может ты просто забыл какую-нибудь деталь.
S>А статью мы обязательно прочитаем.
Надеюсь не разочаруетесь.
Здравствуйте Lexey, Вы писали:
L>Не Vlad, тут ты не прав. Это же локальный юзер, его сида в принципе не может быть на другой машине (точнее, теоретически он там может быть, да только смысл у него будет совсем другой).
Не, ну теоритически вроде сиды не пересекутся, но ты прав, что взять его неоткуда.
L>Тут возможет вариант, когда на Comp2 есть юзер с таким же точно именем и таким же паролем.
Да. Но там начинаются проблемы с домменными именами... Я бы вообще не пользовался локальным юзером если компьютеры подключены к домену.
