Аннотация :
COM+ в W2k радикально упростил работу с защитой, но, как ни крути, она базируется на защите DCOM, а та, в свою очередь, основывается на защите Windows. Для полного понимания некой предметной области нужно начинать с основ. Поэтому стоит последовательно разобрать систему защиты на этих трёх уровнях. Начнем с защиты Windows.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Владислав Чистяков, Вы писали:
ВЧ>Статья :
ВЧ>Авторы : ВЧ>Владислав Чистяков
ВЧ>Аннотация : ВЧ>COM+ в W2k радикально упростил работу с защитой, но, как ни крути, она базируется на защите DCOM, а та, в свою очередь, основывается на защите Windows. Для полного понимания некой предметной области нужно начинать с основ. Поэтому стоит последовательно разобрать систему защиты на этих трёх уровнях. Начнем с защиты Windows.
В статье сказано:
...через интерфейс IAccessControl. Данный способ инициализации может пригодиться, если в качестве сервера выступает Windows 9x или Unix-машина. Последнее хотя и маловероятно, но возможно – CA перенесла COM на большое количество Unix-совместимых платформ. Для серверов, запускаемых под управлением NT, применение данного способа инициализации списка защиты нежелательно.
В связи с чем вопрос — а чем вызвана эта нежелательность???
Спешу заметить, что в приводимых примерах для DCOM (ComSrvEvents) есть неточность. Если на клиенте не выключить защиту (т.е., например, просто не вызывать CoInitializeSecurity), то обратные вызовы с сервера на клиент не проходят даже при использовании CoSetProxyBlanket. Возможно, это связано с тем, что клиент (точнее, сервер, т.к. идет обратный вызов, но это не важно) не может в одностороннем порядке установить параметры безопасности ниже, чем заданы на сервере. Действительно, это было бы странно: сервер установил, что для доступа к нему необходима аутентификация, а клиент взял да и переопределил через CoSetProxyBlanket, что аутентификацию (для него лично) проводить не надо
Тем не менее, при этом CoSetProxyBlanket упорно возвращает S_OK, что совсем запутывает эту и без того темную историю...
Возможно, уважаемый автор может как-либо прокомментировать эту ситуацию? Может я ошибаюсь в своих предположениях
"Reostat" <5730@news.rsdn.ru> wrote in message news:852307@news.rsdn.ru... > Здравствуйте, Владислав Чистяков. > > Спешу заметить, что в приводимых примерах для DCOM (ComSrvEvents) есть неточность. Если на клиенте не выключить защиту (т.е., например, просто не вызывать CoInitializeSecurity), то обратные вызовы с сервера на клиент не проходят даже при использовании CoSetProxyBlanket.
Для выполнения обратных вызовов от учётной записи клиента нужна делегация.
RPC_C_IMP_LEVEL_DELEGATE
Supported for Windows 2000 and later versions. The server process can impersonate the client's security context while acting on behalf of the client. The server process can also make outgoing calls to other servers while acting on behalf of the client, using Cloaking. The server may use the client's security context on other machines to access local and remote resources as the client. When impersonating at this level, the impersonation token can be passed across any number of machine boundaries.
Возможно, это связано с тем, что клиент (точнее, сервер, т.к. идет обратный вызов, но это не важно) не может в одностороннем порядке установить параметры безопасности ниже, чем заданы на сервере. Действительно, это было бы странно: сервер установил, что для доступа к нему необходима аутентификация, а клиент взял да и переопределил через CoSetProxyBlanket, что аутентификацию (для него лично) проводить не надо > Тем не менее, при этом CoSetProxyBlanket упорно возвращает S_OK, что совсем запутывает эту и без того темную историю... > Возможно, уважаемый автор может как-либо прокомментировать эту ситуацию? Может я ошибаюсь в своих предположениях
CoSetProxyBlanket — просто "говорит" какаие параметры безопасности следует использовать при вызове через определённую прокси. Никакие вызовы на серве при этом не осуществляются, соответственно нет возможности проверить параметры безопасности.
Здравствуйте, Tom, Вы писали:
Tom>Для выполнения обратных вызовов от учётной записи клиента нужна делегация.
Спрошу прямо: Вы пробовали это сделать?
Tom>CoSetProxyBlanket — просто "говорит" какаие параметры безопасности следует использовать при вызове через определённую прокси. Никакие вызовы на серве при этом не осуществляются, соответственно нет возможности проверить параметры безопасности.
Спасибо автору за статью
Целый провозился с аутентификацией
и хоть проблема оказалась в одной русской букве в пароле,
но механизм стал намного понятнее
На всякий случай (а то вдруг кто не в курсе):с выходом SP2 в настройку безопасности DCOM были внесены некоторые существенные изменения. Обзор данных изменений приведен здесь. Обзор всех изменений в SP2 можно найти тут. Указанные материалы также доступны для скачивания (формат MS Word).
Владиславу: если будет время, неплохо бы статью обновить... уж больно хорошая статья
